avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <ifedore...@thinkdynamics.com>
Subject Re: three improvements to avalon/phoenix
Date Wed, 21 Aug 2002 15:18:54 GMT
During implementation of the block factories I've got a few issues I 
would like to discuss.

First, it is not clear to me if block factories belong to applications 
or to the kernel. Here are my pros and cons
Factories are part of applications
Pro: factories provide application specific logic to initialize blocks 
thus they belong to applications
Con: factories provide application metadata (specifically, BlockInfo) 
this means they must be up-and-running before an application is started. 
Initialization of factories as part of application startup has following 
problems - factories' lifecycle needs to be managed separately from 
other application blocks; it is difficult to verify application 
consistency due to the fact that factories must be started before rest 
of the application is even assembled.
Factories are part of the kernel
Pro: factories can be managed in the same way other part of the kernel 
are, they can depend on other services deployed into the kernel and so 
on. No additional code is required.
Con: there is no way to a factory to have application specific 
configuration, like ip address of remote server; assemble.xml references 
entities not declared inside the application.
Personally, I tend to deploy factories into the kernel but would like to 
know your opinion.

Second, implementation of objects returned from 
BlockFactory#createObject gets pretty ugly.
To describe the problem better let me introduce usage scenario we can 
talk about. My test system consists of two JVM (JVM-A and JVM-B). JVM-A 
runs MX4J MBeanServer and has "mydomain:name=mybean" mbean of type 
test.MyMBean and JRMP adaptor for remote access. JVM-B run phoenix 
application which has block "jmx-client" that needs services provided by 
"mydomain:name=mybean". Both JVM-A and JVM-B have same lifetime, i.e. 
they both started and stopped simultaneously. Lets also assume that 
JVM-B has "remote-jmx-server" block that provides service 
"mx4j.connector.RemoteMBeanServer" and knows how to connect to JVM-A. 
Problem: write and deploy "remote-mbean" block that provides service 
"test.MyMBean" to JVM-B.
The issue is that "remote-mbean" block needs to implement service 
interface which is not known at block's compile time as well as a number 
of avalon's interfaces (Serviceable in particular). My original proposal 
had new phoenix interface "org.apache.avalon.phoenix.Invokeable" which 
extends "java.lang.reflect.InvocationHandler". Implementation of this 
interface informs phoenix that it should call block.invoke(..) when 
somebody wants to use block's services. Now I also want to introduce yet 
another interface "org.apache.avalon.phoenix.ProxyProvider" that'll have 
single method "Object getProxy()" and will serve same purpose as 
Invokeable but use proxy object provided by the block.


PS: I only wonder why do my messages are getting so long?

Peter Donald wrote:
 > On Tue, 20 Aug 2002 23:13, Igor Fedorenko wrote:
 >>Peter Donald wrote:
 >>>On Tue, 20 Aug 2002 00:59, Igor Fedorenko wrote:
 >>>>Not exactly. Soap does not have to be java, so getting "all remote
 >>>>interfaces" of none-java service would be tricky. Of course, one could
 >>>>write a factory that is smart enough to map soap urls into java
 >>>>interfaces, but this sounds like hiding problems instead of solving 
 >>>If that is the case you could still use the same interface with a slight
 >>><block name="my-block-remote"
 >>>  impl="resource:/my/soap/descriptor.xml"
 >>>  factory="org.apache.avalon.factorys.SoapFactory">
 >>In fact, I cheat here -- encode service definition into "impl".
 >>So, lets say you've almost ;-) convinced me. I am going to implement
 >>this as well as invocation interceptors and will post a patch sometime
 >>later this week.
 > kool!

Igor Fedorenko
Think smart. Think automated. Think Dynamics.

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message