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 Mon, 19 Aug 2002 14:59:25 GMT
Peter Donald wrote:
 > On Wed, 14 Aug 2002 06:58, Igor Fedorenko wrote:
 >
 >> 2. Assemble-time configuration of services provided by a block An
 >> example of a block that needs assemble-time service configuration
 >> would be generic soap proxy block that implements whatever service
 >> is provided by a soap service the block is connected to. Here is an
 >> example configuration for such block <block name="my-block-remote"
 >> class="com.thinkdynamics.proxy.GlueProxy"> <services> <service
 >> name="com.thinkdynamics.blocks.MyBlock"/> </services> </block> To
 >> support this I needed to change two things. First I needed to allow
 >>  service definition in assemble.xml file. This change has a value
 >> of its own, for example, application assembler might want limit
 >> services provided by a block. Second change was to allow definition
 >> of blocks that support any service, to do that I defined
 >> org.apache.avalon.phoenix.Invocable interface which extends
 >> java.lang.reflect.InvocationHandler. If a block implements
 >> Invocable BlockInvocationHandler calls block.invoke method instead
 >> of method.invoke(block).
 >
 >
 > One thing I have been playing with recently is the following.
 >
 > <block name="my-block-remote" impl="soap://www.biz.com/MyWebService">
 >  </block>
 >
 > Ignoring for the moment that I don't know anything about soap so the
 > above is probably wrong way to designate a service. Alternatively you
 > could look at it as remote blocks via
 >
 > <block name="my-block-remote"
 > impl="rmi://brainstem.dyndns.org/kane/ScoreDatabase"
 > factory="org.apache.avalon.factorys.RMIFactory"> </block>
 >
 > The above would tell the container to load a component via the
 > RMIFactory using the key
 > "rmi://brainstem.dyndns.org/kane/ScoreDatabase". The RMIFactory would
 > implement an interface like
 >
 > public interface BlockFactory {
 >     BlockInfo createBlockInfo( String implKey );
 >     Object createBlock( String implKey );
 > }
 >
 > The RMIFactory would know that it has to look up the component in the
 > RMI registry and that the component exposed certain interfaces
 > (basically all its remote ones). The BlockInfo would be created to
 > depends on the RMIRegistry block and expose the remote services etc.
 >
 > I have implemented this in another container and it was relatively
 > successful if a little bit more complex for the assembler.
 >
 > Thoughts? Would this suit your needs?

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 them.

Btw, I still do not understand what is wrong with defining services at 
assemble time. It is the assembler who knows what he wants from remote 
objects (in fact, I believe that the same applies to local objects as 
well). If we can determine list of services implemented by a block, 
great, we can provide that list as a "default" value and safe the 
assembler from some redundant work. But it should be possible to 
overwrite that default, should the assembler want to do so.

-- 
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com


--
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>


Mime
View raw message