avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: three improvements to avalon/phoenix
Date Tue, 20 Aug 2002 12:17:03 GMT
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 them.

If that is the case you could still use the same interface with a slight 

<block name="my-block-remote"

And then /my/soap/descriptor.xml would contain all the information you needed 
to assemble a particular soap service. ie it could contain something like

  <wsdl location="..."/>

Or whatever is most apporpriate for soap. I expect there is some standard 
format in which you define a service offering in soap? You could use that or 
decorate it as appropriate.

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

The thought process goes something like the following. 

The assembler only maps existing services from blocks. It is up to block 
author to define and expose the services (and it does not make sense to allow 
an assembler to add a new service to block as the block will not support it). 
Given that there is no real need to "restrict" the number of services a block 
defines because if an assembler does not want to use particular service of a 
block they just don't.


Peter Donald
Murphy's law - "Anything that can go wrong, will." 
(Actually, this is Finagle's law, which in itself 
shows that Finagle was right.)

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