You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Igor Fedorenko <if...@thinkdynamics.com> on 2002/08/13 22:58:10 UTC
three improvements to avalon/phoenix
Hi Phoenix developers,
During last few days I was investigating avalon/phoenix to see if it can
be used in our project. I really liked what phoenix does but there were
few areas where I needed to extented phoenix a little bit. I would like
to hear your opinion about those extentions - do they make sense or
there are other ways to solve the problem or suggested solution has
problems of its own. So, here is what I did and why I did it.
1. Block invocation interceptors.
Consider following <block> element of modified assemble.xml file
<block name="my-block" class="com.thinkdynamics.blocks.MyBlockImpl">
<invocation-interceptors>
<interceptor
class="com.thinkdynamics.interceptors.JAASInterceptor"/>
<interceptor
class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
</invocation-interceptors>
</block>
Basically I want all calls to MyBlockImpl be routed through
JAASInterceptor, which verified caller's permissions, and then through
LoggingInterceptor, which loggs calls to MyBlockImpl.
To achieve this I've replaced BlockInvocationHandler with a chain of
interceptors, first interceptor (dynamic proxy, created by
BlockInvocationHandler) calls second interceptor, second calls third and
so on until last interceptor in the chain which calls the block. Of
course, if <block> does not have any interceptors configured the block
is called directly from the dynamic proxy.
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).
3. Installation of application from file structures other then packaged
sar-file.
I defined new interface org.apache.avalon.phoenix.interfaces.Installer,
renamed
org.apache.avalon.phoenix.components.deployer.installer.Installer to
DefaultInstaller and change DefaultDeployer to locate Installer through
serviceManager.lookup call.
This way I can, for example, provide an installer that installs
applications directly from file structures maintained by Eclipse IDE
thus eliminating need for application packaging during development.
Thank you for reading such long e-mail and I appreciate all your comments.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
Peter Royal wrote:
> On Wednesday 14 August 2002 10:04 am, Igor Fedorenko wrote:
>
[skiped]
>>>>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).
>>>
>>>I'm a little unsure if this is the best way to implement this, namely if
>>>introducing service declarations into assembly.xml is a good idea.
>>
>>Yes, I agree with your concerns. What if I add another method to
>>Invocable interface to check if a block implements an interface?
>>Something like "boolean provides(Class interface)". However, I do not
>>know if this method can be plugged into block lifecicle easily.
>
>
> What's the core need of this? To have a generic "remoting" block that can
> implement any service, defined by its configuration?
>
> If so, the problem is that you can't have multiple xinfo declarations per
> block since the xinfo is coded to be com.thinkdynamics.proxy.GlueProxy.xinfo
>
> So what you really need is the ability to declare where the xinfo document is,
> vs the automagic discovery? Something like:
>
> <block name="my-block-remote"
> class="com.thinkdynamics.proxy.GlueProxy"
> xinfo="resource://com/thinkdynamics/blocks/MyBlock.xinfo"/>
No, this won't do. What if GlueProxy depends on GlueRegistry (as it does
in my prototype)? The only part of xinfo that could change is
<services>. Other parts (<block>, <management-access-points> and
<dependencies>) should always be the same as specified by block
developer. Imagine, when a new version of a block comes out you need to
verify all derived xinfos to make sure that they are still consistent
with the block. If you do not like service declaration inside
assemble.xml we could define another file format for that, to be used like:
<block name="my-block-remote"
class="com.thinkdynamics.proxy.GlueProxy"
service="resource://com/thinkdynamics/blocks/MyBlock.sinfo"/>
but I do not see big advantage of doing this.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 14 August 2002 10:04 am, Igor Fedorenko wrote:
> I agree that per-application interceptors would simplify assembly,
> however such interceptors raise few questions:
> - let say we have interceptors defined both at application and at block
> level. What would be an invocation order of interceptors in this case?
> We can add priority to interceptor configuration and sort them.
I'd make the interceptor hierarchy be:
System -> App Level -> Block Level
So any per-app interceptors get called before per-block ones.
> - it would be nice to be able to define per-application interceptors
> even if they do not apply to all blocks in the app. For example,
> JAASInterceptor applies only to blocks with security configuration. To
> accommodate this we need to extend interceptor interface to add
> something like "boolean accepts(BlockInfo)".
yuk, i'd be -1 on that, smells of flexibility syndrome..
> - application assembler might want to "overwrite" an application
> interceptor at a block level. For example, define per-application log
> interceptor and another log interceptor for one of the blocks.
that sounds like two log interceptors vs an override... but again.. seems too
broad up front without any forseeable use (in my eyes)
> Personally, I would start with per-block interceptors and add
> per-application later.
a very sensible way to go. Always best to start small :)
> >>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).
> >
> > I'm a little unsure if this is the best way to implement this, namely if
> > introducing service declarations into assembly.xml is a good idea.
>
> Yes, I agree with your concerns. What if I add another method to
> Invocable interface to check if a block implements an interface?
> Something like "boolean provides(Class interface)". However, I do not
> know if this method can be plugged into block lifecicle easily.
What's the core need of this? To have a generic "remoting" block that can
implement any service, defined by its configuration?
If so, the problem is that you can't have multiple xinfo declarations per
block since the xinfo is coded to be com.thinkdynamics.proxy.GlueProxy.xinfo
So what you really need is the ability to declare where the xinfo document is,
vs the automagic discovery? Something like:
<block name="my-block-remote"
class="com.thinkdynamics.proxy.GlueProxy"
xinfo="resource://com/thinkdynamics/blocks/MyBlock.xinfo"/>
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
On Mon, 9 Sep 2002 00:09, Igor Fedorenko wrote:
> I can resubmit interceptors/factories as a series of small
> patches for FACTORIES-branch if it'll make your job easier. Plus I have
> added interceptor context, so you do not have the latest version of the
> patch anyways.
BTW you may want to download the excalibur CVS and have a look at
info/src/java/org/apache/excalibur/containerkit/factory/*
That has the kind of interface that I want to eventually move towards and I
have documented the interfaces relatively well. See what yuou think
--
Cheers,
Peter Donald
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
On Mon, 9 Sep 2002 00:09, Igor Fedorenko wrote:
> > One thing I noticed is that you added the Interceptors to the BlockInfo
> > but I though that was kinda strange as they are associated with a block
> > instance. Hence I moved the interceptors to BlockMetaData instead. That
> > seem reasonable?
>
> Of course, it does. Now I see the reason for both metainfo and metadata
> packages! :-)
:)
> > BTW when sending patches it is usually better to send lots of small
> > patches so we can check and apply them faster - Documentation would also
> > speed up the process ;)
>
> I can resubmit interceptors/factories as a series of small
> patches for FACTORIES-branch if it'll make your job easier. Plus I have
> added interceptor context, so you do not have the latest version of the
> patch anyways.
That would be great. I will probably have a chance to look at stuff again on
Wend afternoon if you can get it to us by then. Otherwise I will just
continue with application of your old patch.
--
Cheers,
Peter Donald
A right is not what someone gives you; it's what no one can take from you.
-- Ramsey Clark
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
Peter Donald wrote:
> Okay - I have started applying your patch to the "FACTORY-branch" branch in
> Phoenix CVS. You can grab it via
>
> cvs up -r FACTORY-branch
>
> And this will convert your existing tree to the new branch. (cvs up -A to
> return to main branch).
Thank you, Peter.
>
> One thing I noticed is that you added the Interceptors to the BlockInfo but I
> though that was kinda strange as they are associated with a block instance.
> Hence I moved the interceptors to BlockMetaData instead. That seem
> reasonable?
Of course, it does. Now I see the reason for both metainfo and metadata
packages! :-)
> BTW when sending patches it is usually better to send lots of small patches so
> we can check and apply them faster - Documentation would also speed up the
> process ;)
I can resubmit interceptors/factories as a series of small
patches for FACTORIES-branch if it'll make your job easier. Plus I have
added interceptor context, so you do not have the latest version of the
patch anyways.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
Okay - I have started applying your patch to the "FACTORY-branch" branch in
Phoenix CVS. You can grab it via
cvs up -r FACTORY-branch
And this will convert your existing tree to the new branch. (cvs up -A to
return to main branch).
One thing I noticed is that you added the Interceptors to the BlockInfo but I
though that was kinda strange as they are associated with a block instance.
Hence I moved the interceptors to BlockMetaData instead. That seem
reasonable?
BTW when sending patches it is usually better to send lots of small patches so
we can check and apply them faster - Documentation would also speed up the
process ;)
--
Cheers,
Peter Donald
The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten. --Jules Feiffer (cartoonist)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
Peter Royal wrote:
> On Tuesday 13 August 2002 04:58 pm, Igor Fedorenko wrote:
>
>>During last few days I was investigating avalon/phoenix to see if it can
>>be used in our project. I really liked what phoenix does but there were
>
>
> excellent!
>
>
>>1. Block invocation interceptors.
>>Consider following <block> element of modified assemble.xml file
>> <block name="my-block" class="com.thinkdynamics.blocks.MyBlockImpl">
>> <invocation-interceptors>
>> <interceptor
>> class="com.thinkdynamics.interceptors.JAASInterceptor"/>
>> <interceptor
>> class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
>> </invocation-interceptors>
>> </block>
>
> <snip/>
>
>>To achieve this I've replaced BlockInvocationHandler with a chain of
>>interceptors, first interceptor (dynamic proxy, created by
>>BlockInvocationHandler) calls second interceptor, second calls third and
>>so on until last interceptor in the chain which calls the block. Of
>>course, if <block> does not have any interceptors configured the block
>>is called directly from the dynamic proxy.
>
>
> very cool. the only suggestion i would have on this is perhaps sometimes it
> might be useful to have an interceptor per-application (such as the logging
> interceptor, define in once place to log all calls for all blocks).
I agree that per-application interceptors would simplify assembly,
however such interceptors raise few questions:
- let say we have interceptors defined both at application and at block
level. What would be an invocation order of interceptors in this case?
We can add priority to interceptor configuration and sort them.
- it would be nice to be able to define per-application interceptors
even if they do not apply to all blocks in the app. For example,
JAASInterceptor applies only to blocks with security configuration. To
accommodate this we need to extend interceptor interface to add
something like "boolean accepts(BlockInfo)".
- application assembler might want to "overwrite" an application
interceptor at a block level. For example, define per-application log
interceptor and another log interceptor for one of the blocks.
Personally, I would start with per-block interceptors and add
per-application later.
>>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).
>
>
> I'm a little unsure if this is the best way to implement this, namely if
> introducing service declarations into assembly.xml is a good idea.
Yes, I agree with your concerns. What if I add another method to
Invocable interface to check if a block implements an interface?
Something like "boolean provides(Class interface)". However, I do not
know if this method can be plugged into block lifecicle easily.
>
> I do see the value in it though, as it would be a very easy way to pull in
> remote interfaces (be it SOAP, XML-RPC, RMI, AltRMI, IIOP..)
>
>>3. Installation of application from file structures other then packaged
>>sar-file.
>>I defined new interface org.apache.avalon.phoenix.interfaces.Installer,
>>renamed
>>org.apache.avalon.phoenix.components.deployer.installer.Installer to
>>DefaultInstaller and change DefaultDeployer to locate Installer through
>>serviceManager.lookup call.
>>This way I can, for example, provide an installer that installs
>>applications directly from file structures maintained by Eclipse IDE
>>thus eliminating need for application packaging during development.
>
>
> Ooh! Send a patch for this :)
Ok, I'll send a patch later today or tomorrow -- I need to clean up the
code a little bit ;-)
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 13 August 2002 04:58 pm, Igor Fedorenko wrote:
> During last few days I was investigating avalon/phoenix to see if it can
> be used in our project. I really liked what phoenix does but there were
excellent!
> 1. Block invocation interceptors.
> Consider following <block> element of modified assemble.xml file
> <block name="my-block" class="com.thinkdynamics.blocks.MyBlockImpl">
> <invocation-interceptors>
> <interceptor
> class="com.thinkdynamics.interceptors.JAASInterceptor"/>
> <interceptor
> class="com.thinkdynamics.interceptors.LoggingInterceptor"/>
> </invocation-interceptors>
> </block>
<snip/>
> To achieve this I've replaced BlockInvocationHandler with a chain of
> interceptors, first interceptor (dynamic proxy, created by
> BlockInvocationHandler) calls second interceptor, second calls third and
> so on until last interceptor in the chain which calls the block. Of
> course, if <block> does not have any interceptors configured the block
> is called directly from the dynamic proxy.
very cool. the only suggestion i would have on this is perhaps sometimes it
might be useful to have an interceptor per-application (such as the logging
interceptor, define in once place to log all calls for all blocks).
> 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).
I'm a little unsure if this is the best way to implement this, namely if
introducing service declarations into assembly.xml is a good idea.
I do see the value in it though, as it would be a very easy way to pull in
remote interfaces (be it SOAP, XML-RPC, RMI, AltRMI, IIOP..)
> 3. Installation of application from file structures other then packaged
> sar-file.
> I defined new interface org.apache.avalon.phoenix.interfaces.Installer,
> renamed
> org.apache.avalon.phoenix.components.deployer.installer.Installer to
> DefaultInstaller and change DefaultDeployer to locate Installer through
> serviceManager.lookup call.
> This way I can, for example, provide an installer that installs
> applications directly from file structures maintained by Eclipse IDE
> thus eliminating need for application packaging during development.
Ooh! Send a patch for this :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
Looks good. Theres a few reservations I have which I will go through on
Sunday. Hopefully after they are resolve I will apply your changes.
Thanks!
On Fri, 23 Aug 2002 05:06, Igor Fedorenko wrote:
> I have a patch that I am reasonably happy with. It adds support for
> block invocation interceptors in a form
>
> <block name="block-name" class="tes.TestBlock">
> <proxy>
> <interceptor class="test.TestInterceptor"/>
> </proxy>
> </block>
>
> It also adds support for block factories. In assemble.xml
>
> <factory name="test-factory" class="test.Factory"/>
> <block name="block-name"
> factory="test-factory" impl="factory-specific-impl"/>
>
> Old block definition is supported as well.
>
> There is a number of outstanding @todo items but most of them are of
> cosmetic nature (proper package names, proper exception classes and
> missing javadoc). One real issue is configuration of loggers for block
> factories -- now logs go into assembler's logger.
>
> Could somebody who is in charge review the patch and comment on whether
> it will or will not be incorporated into the source code? Thank you.
>
> 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
> >>>> them.
> >>>
> >>>If that is the case you could still use the same interface with a slight
> >>>modification
> >>>
> >>><block name="my-block-remote"
> >>> impl="resource:/my/soap/descriptor.xml"
> >>> factory="org.apache.avalon.factorys.SoapFactory">
> >>></block>
> >>
> >>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!
--
Cheers,
Peter Donald
-------------------------------------------------------------
| Egoism is the drug that soothes the pain of stupidity. |
-------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
On Wed, 28 Aug 2002 00:00, Igor Fedorenko wrote:
> The issue here is that
> factories must be started before application is assembled what makes it
> difficult to verify application and initialize factories with
> application context.
ah, right. Not sure how I missed that ... hmm that is ugly ...
--
Cheers,
Peter Donald
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
Peter Donald wrote:
> Hi,
>
> Okay - after playing with your code for a while, heres my current thoughts.
>
> On Thu, 22 Aug 2002 01:18, Igor Fedorenko wrote:
>
>>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.
>
>
> My impression is that Factories are generally something that a user may want
> to use and thus they should really be in "userland". However while we are
> "evolving" them I think it is best we keep them in "kernel" land. That way we
> can change them with little regard to backwards compatability - at least
> until we move them back into userland. Thoughts?
Well, here is the reason I did not implement it this way. Consider my
remote jmx use case. Proxy block remote-mbean depends on "userland"
object remote-jmx-server. For me it is a strong indication that
remote-mbean belongs to "userland". Proxy block and its factory are
tightly coupled that makes it desirable to deploy factory into userland
as well. Think for example about classloading issues we would have to
solve if the factory was deployed into kernel.
>
> Then again it may only be "power" users who use factorys so we may be able to
> get away with a set of them in kernel and just having the implementation keys
> point to sufficently detailed descriptors.
>
>
>>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.
>
>
> We already handle listeners differently and the next rev of the kernel will
> likely handle lots of different styles of components. So we can build it with
> this in mind. We could easily make it so that
>
> * all factorys get started, then
> * all listeners get started, then
> * all blocks get started
This is exactly what the patch does ;-). The issue here is that
factories must be started before application is assembled what makes it
difficult to verify application and initialize factories with
application context.
>
>
>>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.
>
>
> I am not sure I entirely follow this. But let me just get this straight. We
> have a local block that is dynamically defined to implement some interface
> "MyRemoteService" - which it does not know at compile time?
>
> I think I would like to see that solved in the followin manner. Each factory
> is responsible for defining the object in whatever way they see fit. The end
> result is just that the object coming out of the factory must implement the
> service interfaces and any avalon interfaces it needs to implement.
>
> This way, both proxy and Invokable become implementation details of the
> factory rather than part of the phoenix API layer. So your factory would end
> up having a method like
>
>
> public Object createBlock( ... )
> {
> MyBlockDelegator delegator = ...;
> //delegator is serviceable
>
>
> Class remoteInterface = determineRemoteInterface();
> myInvocationHandler = new ...;
>
> Class[] api = new Class[] { Serviceable.class, remoteInterface };
>
> return Proxy.newProxyInstance( classloader, api, myInvocationHandler );
> }
>
> By doing it this way, we only have to get the factory API right and we can
> experiment to our hearts content whether to use proxys, or Invocable or
> whatever really. Like?
I agree that Invocable/ProxyProvider interfaces are irrelevant to
factories (consider them as another separate improvement), however
without them it would be more difficult/tedious/error-prone to solve
original problem of "importing" remote service into phoenix apps.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
Hi,
Okay - after playing with your code for a while, heres my current thoughts.
On Thu, 22 Aug 2002 01:18, Igor Fedorenko wrote:
> 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.
My impression is that Factories are generally something that a user may want
to use and thus they should really be in "userland". However while we are
"evolving" them I think it is best we keep them in "kernel" land. That way we
can change them with little regard to backwards compatability - at least
until we move them back into userland. Thoughts?
Then again it may only be "power" users who use factorys so we may be able to
get away with a set of them in kernel and just having the implementation keys
point to sufficently detailed descriptors.
>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.
We already handle listeners differently and the next rev of the kernel will
likely handle lots of different styles of components. So we can build it with
this in mind. We could easily make it so that
* all factorys get started, then
* all listeners get started, then
* all blocks get started
> 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.
I am not sure I entirely follow this. But let me just get this straight. We
have a local block that is dynamically defined to implement some interface
"MyRemoteService" - which it does not know at compile time?
I think I would like to see that solved in the followin manner. Each factory
is responsible for defining the object in whatever way they see fit. The end
result is just that the object coming out of the factory must implement the
service interfaces and any avalon interfaces it needs to implement.
This way, both proxy and Invokable become implementation details of the
factory rather than part of the phoenix API layer. So your factory would end
up having a method like
public Object createBlock( ... )
{
MyBlockDelegator delegator = ...;
//delegator is serviceable
Class remoteInterface = determineRemoteInterface();
myInvocationHandler = new ...;
Class[] api = new Class[] { Serviceable.class, remoteInterface };
return Proxy.newProxyInstance( classloader, api, myInvocationHandler );
}
By doing it this way, we only have to get the factory API right and we can
experiment to our hearts content whether to use proxys, or Invocable or
whatever really. Like?
> PS: I only wonder why do my messages are getting so long?
keep em coming ;)
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
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.
Thoughts?
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
them.
>>>
>>>If that is the case you could still use the same interface with a slight
>>>modification
>>>
>>><block name="my-block-remote"
>>> impl="resource:/my/soap/descriptor.xml"
>>> factory="org.apache.avalon.factorys.SoapFactory">
>>></block>
>>
>>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.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
I have a patch that I am reasonably happy with. It adds support for
block invocation interceptors in a form
<block name="block-name" class="tes.TestBlock">
<proxy>
<interceptor class="test.TestInterceptor"/>
</proxy>
</block>
It also adds support for block factories. In assemble.xml
<factory name="test-factory" class="test.Factory"/>
<block name="block-name"
factory="test-factory" impl="factory-specific-impl"/>
Old block definition is supported as well.
There is a number of outstanding @todo items but most of them are of
cosmetic nature (proper package names, proper exception classes and
missing javadoc). One real issue is configuration of loggers for block
factories -- now logs go into assembler's logger.
Could somebody who is in charge review the patch and comment on whether
it will or will not be incorporated into the source code? Thank you.
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 them.
>>>
>>>If that is the case you could still use the same interface with a slight
>>>modification
>>>
>>><block name="my-block-remote"
>>> impl="resource:/my/soap/descriptor.xml"
>>> factory="org.apache.avalon.factorys.SoapFactory">
>>></block>
>>
>>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.
www.thinkdynamics.com
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
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 them.
> >
> > If that is the case you could still use the same interface with a slight
> > modification
> >
> > <block name="my-block-remote"
> > impl="resource:/my/soap/descriptor.xml"
> > factory="org.apache.avalon.factorys.SoapFactory">
> > </block>
>
> 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!
--
Cheers,
Peter Donald
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Alexis Agahi <al...@users.sourceforge.net>.
Peter Donald wrote:
> Hi,
>
> On Wed, 21 Aug 2002 07:46, Alexis Agahi wrote:
>
>>Why not using Web Services Description Language?
>>http://www.w3.org/TR/wsdl
>>with
>>WSDL4J http://www-124.ibm.com/developerworks/projects/wsdl4j/
>>provided by http://xml.apache.org/axis/index.html
>>
>>And FYI
>>Web Services Invocation Framework
>>http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsif/java/readme.htm?
>>rev=HEAD&content-type=text/html Web Services Inspection Language
>>http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsil/java/README.htm
>
>
> I acturally read through some of this and it looks neat. I was not aware that
> a "web service" could actually be a CORBA/DCOM/RMI call and not SOAP. From my
> reading of things you could "theoretically" define any distributed service
> using WSDL. Is this correct?
"Theoretically" yes ;)
see http://www.javaworld.com/javaworld/jw-05-2002/jw-0524-wsdl_p.html
> Essentially there is messages (either requests or responses) and ports
> (methods/procedures/access points). These calls are made via an underlying
> framework, in Axises case it is via a call router?
Currently I did not checkout Axis project, I'm just using Apache
SOAP. I'll certainly take look at Axis soon (when WSIF will be
integrated), probably next stable release.
> The one restriction being that it does not allow any "context" information if
> understand it correctly ? (ie security/transaction attributes that are common
> in other remoting frameworks).
Transaction can not be declared via Web services.
http://www.webservices.org/index.php/article/articleprint/108/-1/30/
BTP, XLANG, are trying to fill the gap.
> Anyways that would definetly be a good way to represent a webservice service
> however the one thing it does not define is how to bind it to a language
> however we could easily add that on top or leave it up to the factory to
> perform specific binding.
I guess so, but I've not your experience on the subject ;)
Some application such as Weblogic generate automatically
generates WSDL from the class. Maybe that could be a way?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Alexis Agahi <al...@users.sourceforge.net>.
Peter Donald wrote:
> Hi,
>
> On Wed, 21 Aug 2002 07:46, Alexis Agahi wrote:
>
>>Why not using Web Services Description Language?
>>http://www.w3.org/TR/wsdl
>>with
>>WSDL4J http://www-124.ibm.com/developerworks/projects/wsdl4j/
>>provided by http://xml.apache.org/axis/index.html
>>
>>And FYI
>>Web Services Invocation Framework
>>http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsif/java/readme.htm?
>>rev=HEAD&content-type=text/html Web Services Inspection Language
>>http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsil/java/README.htm
>
>
> I acturally read through some of this and it looks neat. I was not aware that
> a "web service" could actually be a CORBA/DCOM/RMI call and not SOAP. From my
> reading of things you could "theoretically" define any distributed service
> using WSDL. Is this correct?
>
> Essentially there is messages (either requests or responses) and ports
> (methods/procedures/access points). These calls are made via an underlying
> framework, in Axises case it is via a call router?
>
> The one restriction being that it does not allow any "context" information if
> understand it correctly ? (ie security/transaction attributes that are common
> in other remoting frameworks).
Just FYI (but this could be offtopic here), I just notice that
Web Service Choreography Interface (WSCI) has been submitted to W3C.
http://www.w3.org/TR/2002/NOTE-wsci-20020808/
"WSCI describes how Web Service operations – such as those
defined by WSDL [WSDL]– can be choreographed in the context of a
message exchange in which the Web Service participates.
Interactions between services – either in a business context or
not – always follow and implement choreographed message exchanges
(processes). WSCI is the first step towards enabling the mapping
of services as components realizing those processes.
WSCI also describes how the choreography of these operations
should expose relevant information, such as message correlation,
exception handling, transaction description and dynamic
participation capabilities."
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
Hi,
On Wed, 21 Aug 2002 07:46, Alexis Agahi wrote:
> Why not using Web Services Description Language?
> http://www.w3.org/TR/wsdl
> with
> WSDL4J http://www-124.ibm.com/developerworks/projects/wsdl4j/
> provided by http://xml.apache.org/axis/index.html
>
> And FYI
> Web Services Invocation Framework
> http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsif/java/readme.htm?
>rev=HEAD&content-type=text/html Web Services Inspection Language
> http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsil/java/README.htm
I acturally read through some of this and it looks neat. I was not aware that
a "web service" could actually be a CORBA/DCOM/RMI call and not SOAP. From my
reading of things you could "theoretically" define any distributed service
using WSDL. Is this correct?
Essentially there is messages (either requests or responses) and ports
(methods/procedures/access points). These calls are made via an underlying
framework, in Axises case it is via a call router?
The one restriction being that it does not allow any "context" information if
understand it correctly ? (ie security/transaction attributes that are common
in other remoting frameworks).
Anyways that would definetly be a good way to represent a webservice service
however the one thing it does not define is how to bind it to a language
however we could easily add that on top or leave it up to the factory to
perform specific binding.
--
Cheers,
Peter Donald
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
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 them.
>
>
> If that is the case you could still use the same interface with a slight
> modification
>
> <block name="my-block-remote"
> impl="resource:/my/soap/descriptor.xml"
> factory="org.apache.avalon.factorys.SoapFactory">
> </block>
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.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Alexis Agahi <al...@users.sourceforge.net>.
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 them.
>
>
> If that is the case you could still use the same interface with a slight
> modification
>
> <block name="my-block-remote"
> impl="resource:/my/soap/descriptor.xml"
> factory="org.apache.avalon.factorys.SoapFactory">
> </block>
>
> 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
>
> <soap>
> <uri>htts://..."</uri>
> <wsdl location="..."/>
> <security-credentials>
> ...
> </security-credentials>
> </soap>
>
> 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.
Why not using Web Services Description Language?
http://www.w3.org/TR/wsdl
with
WSDL4J http://www-124.ibm.com/developerworks/projects/wsdl4j/
provided by http://xml.apache.org/axis/index.html
And FYI
Web Services Invocation Framework
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsif/java/readme.htm?rev=HEAD&content-type=text/html
Web Services Inspection Language
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-axis-wsil/java/README.htm
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
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
modification
<block name="my-block-remote"
impl="resource:/my/soap/descriptor.xml"
factory="org.apache.avalon.factorys.SoapFactory">
</block>
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
<soap>
<uri>htts://..."</uri>
<wsdl location="..."/>
<security-credentials>
...
</security-credentials>
</soap>
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.
--
Cheers,
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
On Tue, 20 Aug 2002 06:07, Paul Hammant wrote:
> Peter,
>
> >[.. soap ..]
> >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>
>
> Don't like the factory by class name thing. It implies that the thing
> will be instantiated. I'd prefer that it was a key to an instance,
> either one from a standard set loaded by the kernel or some custom one
> provided by the assembler.
kool. Thats the same complaint someone else had ;) So you would suggest that
you either use standard factory names or you define factorys at top of
assembly file and then reuse shortname?
<factory name="rmi-factory" factory="org.apache.avalon.factorys.RMIFactory">
...some parameters?...
</factory>
...
<block name="my-block-remote"
impl="rmi://brainstem.dyndns.org/kane/ScoreDatabase"
factory="rmi-factory">
</block>
> Anyway it is close to AltRMI in kernel perhaps? It is also a little
> more suitable to the job...
AltRMI could have a factory. I guess my main point was that any remote or
alternative component system should be able to participate in the system and
using this abstraction would allow it.
--
Cheers,
Peter Donald
----------------------------------------------------------------
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
----------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>[.. soap ..]
>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>
>
Don't like the factory by class name thing. It implies that the thing
will be instantiated. I'd prefer that it was a key to an instance,
either one from a standard set loaded by the kernel or some custom one
provided by the assembler.
Anyway it is close to AltRMI in kernel perhaps? It is also a little
more suitable to the job...
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: three improvements to avalon/phoenix
Posted by Peter Donald <pe...@apache.org>.
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?
--
Cheers,
Peter Donald
"All my life I wanted to be someone; I guess I should have been more
specific."
-- Jane Wagner
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>