Re: extension apis

[ant elder <an...@gmail.com>]

Anyone had a chance to look at this, could i move
ExternalServiceTargetInvoker and ExternalServiceInvoker to extensions in the
core project?

   ...ant

On 4/30/06, ant elder <an...@gmail.com> wrote:
>
> I've just committed the first cut at moving all the Axis2 binding over to
> this. I wasn't completely sure how the externalService part was supposed to
> work, maybe you could have a look at what I've done and comment.
>
> The main relevant classes are ExternalWebServiceBuilder,
> ExternalServiceTargetInvoker, ExternalServiceInvoker, and
> Axis2ServiceInvoker.
>
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/axis2/builder/ExternalWebServiceBuilder.java
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/axis2/handler/ExternalServiceTargetInvoker.java
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/axis2/handler/ExternalServiceInvoker.java
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/axis2/handler/Axis2ServiceInvoker.java
>
> ExternalServiceTargetInvoker and ExternalServiceInvoker have nothing
> specific to the binding so I wondered if something like them should be
> provided in the o.a.t.core.extension package.
>
> If the code is mostly ok as it is now then the main remaining work is to
> change the WS entryPoint to use the TomcatHost mechanism to register the
> servlet, and to move all the configuring of each entryPoint out the servlet
> init.  Jeremy, I've not yet been able to get either of these to work yet so
> if you're about and have time to chat about this on IRC let me know.
>
>    ...ant
>
> On 4/26/06, Jim Marino <jm...@myromatours.com> wrote:
>
> > I've added the extension APIs to core for the following:
> >
> > - Bindings (entry points/external services)
> > - Component types (atomic/composite)
> > - Policy
> >
> > There are two basic levels, "simple" and "advanced". The simple
> > approach, which is designed for the "80%" case, involves extending
> > one of four support classes in core/extension. This approach hides as
> > much of the infrastructure as possible. I would like to iterate over
> > the API design since I am sure it will need to be changed as we
> > encounter different use cases. I would also like to eventually
> > automate creation of extension points further by creating IDE
> > templates which produce many of the extension classes, since quite a
> > few are wrote. The more advanced, or low-level, API can be released
> > later as we gain confidence in the design since it exposes more
> > capabilities.
> >
> > For example, with the simple approach, one needs to do the following
> > to implement a component type (the most complex scenario). The
> > description is also probably more complex than the code:
> >
> > 1. Write the assembly artifacts and loader as described on the wiki
> >
> > 2. Extend ContextFactoryBuilderSupport, overriding the
> > createContextFactory method, which passes back the ContextFactory for
> > the component type. JavaContextFactoryBuilder is an example, which is
> > a little more complex than it needs to be due to processing of
> > annotations for things like init and destroy, which I intend to
> > remove in refactorings today.
> >
> > 3. Write a Context and ContextFactory implementation. The
> > ContextFactory implementation is used by the runtime to create
> > configured Contexts, which manage component implementation instances.
> >
> > The ContextFactory will be passed properties (name, object value) and
> > wire factories. Wire factories are either of type SourceWireFactory
> > or TargetWireFactory, corresponding to outgoing wires for a reference
> > and incoming wires for a service respectively. Source and target
> > invocation chains (per operation) are connected by the runtime to
> > form a wire between two of the following: entry point, external
> > service, or component. If a non-component client calls locateService,
> > they will be returned a proxy fronting just the TargetWireFactory
> > invocation chains. The ContextFactory must take those factories and
> > pass them to a Context which "connects" them to the component
> > implementation instance. For example, the Java support wraps source
> > wire factories in an ObjectFactory which is used by an Injector to
> > create a proxy that is injected into a method or field on the
> > component implementation class. The proxy creation method is located
> > on WireFactory, the base class for SourceWireFactory and
> > TargetWireFactory.
> >
> > 3. Write a TargetInvoker implementation and extend
> > WireBuilderSupport, overriding createInvoker. The latter creates the
> > TargetInvoker, which is responsible for dispatching to an instance of
> > the component type. This class also contains another method,
> > handlesTargetType, which signals to the runtime which component
> > implementation type the wire builder creates target invokers for. I
> > intend to eliminate this as it may be reflected through generics. The
> > TargetInvoker interface is pretty simple, one has to implement
> > invokeTarget and clone.
> >
> > For component implementation types, a target invoker will generally
> > take the scope context the component is associated with and resolve
> > the component instance against it when it receives an invocation. The
> > TargetInvoker may cache the resolved result if the source is of a
> > lesser scope than the target (this information is passed into the
> > WireBuilder). Don't cache resolves when going from a greater to
> > lesser scope since that will result in "crossed" contexts. Clone is
> > necessary since TargetInvokers are cached on the source side of a
> > wire per operation and passed through both
> > source and target invokcation chains, where it is "invoked" by the
> > last interceptor in the target chain. TargetInvoker.clone() is called
> > by the proxy invocation handler (e.g. JDKInvocationHandler) if the
> > target invoker caches invocations on the first invoke of the
> > operation and held there. Otherwise it uses a "stateless invoker".
> > This allows us to optimize resolves away for sources of a lesser
> > scope.  All of this is probably more detail than a component
> > implementor will need to be aware of since the extension classes
> > abstract this away.
> >
> > 4. Contribute the loader, ContextFactory, and WireBuilder
> > implementations as a system module (along with the TargetInvoker
> > class). They will automagically be registered in the runtime and
> > everything should just work.
> >
> > Please take a look and provide feedback.
> >
> > Jim
> >
>
>

Re: extension apis

[Jim Marino <jm...@myromatours.com>]

Nice job on the web services extensions...I noticed you kind of got  
stuck with some nasty integration issues and had the brunt of dealing  
with them.


Yea I'd go ahead and move them up. FYI, we're working on some more  
things which may introduce changes but we'll make the appropriate  
refactors if needed.

Jim


On May 3, 2006, at 11:57 AM, ant elder wrote:

> Anyone had a chance to look at this, could i move
> ExternalServiceTargetInvoker and ExternalServiceInvoker to  
> extensions in the
> core project?
>
>   ...ant
>
> On 4/30/06, ant elder <an...@gmail.com> wrote:
>
>>
>> I've just committed the first cut at moving all the Axis2 binding  
>> over to
>> this. I wasn't completely sure how the externalService part was  
>> supposed to
>> work, maybe you could have a look at what I've done and comment.
>>
>> The main relevant classes are ExternalWebServiceBuilder,
>> ExternalServiceTargetInvoker, ExternalServiceInvoker, and
>> Axis2ServiceInvoker.
>>
>>
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ 
>> bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/ 
>> axis2/builder/ExternalWebServiceBuilder.java
>>
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ 
>> bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/ 
>> axis2/handler/ExternalServiceTargetInvoker.java
>>
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ 
>> bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/ 
>> axis2/handler/ExternalServiceInvoker.java
>>
>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ 
>> bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/ 
>> axis2/handler/Axis2ServiceInvoker.java
>>
>> ExternalServiceTargetInvoker and ExternalServiceInvoker have nothing
>> specific to the binding so I wondered if something like them  
>> should be
>> provided in the o.a.t.core.extension package.
>>
>> If the code is mostly ok as it is now then the main remaining work  
>> is to
>> change the WS entryPoint to use the TomcatHost mechanism to  
>> register the
>> servlet, and to move all the configuring of each entryPoint out  
>> the servlet
>> init.  Jeremy, I've not yet been able to get either of these to  
>> work yet so
>> if you're about and have time to chat about this on IRC let me know.
>>
>>    ...ant
>>
>> On 4/26/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>> > I've added the extension APIs to core for the following:
>> >
>> > - Bindings (entry points/external services)
>> > - Component types (atomic/composite)
>> > - Policy
>> >
>> > There are two basic levels, "simple" and "advanced". The simple
>> > approach, which is designed for the "80%" case, involves extending
>> > one of four support classes in core/extension. This approach  
>> hides as
>> > much of the infrastructure as possible. I would like to iterate  
>> over
>> > the API design since I am sure it will need to be changed as we
>> > encounter different use cases. I would also like to eventually
>> > automate creation of extension points further by creating IDE
>> > templates which produce many of the extension classes, since  
>> quite a
>> > few are wrote. The more advanced, or low-level, API can be released
>> > later as we gain confidence in the design since it exposes more
>> > capabilities.
>> >
>> > For example, with the simple approach, one needs to do the  
>> following
>> > to implement a component type (the most complex scenario). The
>> > description is also probably more complex than the code:
>> >
>> > 1. Write the assembly artifacts and loader as described on the wiki
>> >
>> > 2. Extend ContextFactoryBuilderSupport, overriding the
>> > createContextFactory method, which passes back the  
>> ContextFactory for
>> > the component type. JavaContextFactoryBuilder is an example,  
>> which is
>> > a little more complex than it needs to be due to processing of
>> > annotations for things like init and destroy, which I intend to
>> > remove in refactorings today.
>> >
>> > 3. Write a Context and ContextFactory implementation. The
>> > ContextFactory implementation is used by the runtime to create
>> > configured Contexts, which manage component implementation  
>> instances.
>> >
>> > The ContextFactory will be passed properties (name, object  
>> value) and
>> > wire factories. Wire factories are either of type SourceWireFactory
>> > or TargetWireFactory, corresponding to outgoing wires for a  
>> reference
>> > and incoming wires for a service respectively. Source and target
>> > invocation chains (per operation) are connected by the runtime to
>> > form a wire between two of the following: entry point, external
>> > service, or component. If a non-component client calls  
>> locateService,
>> > they will be returned a proxy fronting just the TargetWireFactory
>> > invocation chains. The ContextFactory must take those factories and
>> > pass them to a Context which "connects" them to the component
>> > implementation instance. For example, the Java support wraps source
>> > wire factories in an ObjectFactory which is used by an Injector to
>> > create a proxy that is injected into a method or field on the
>> > component implementation class. The proxy creation method is  
>> located
>> > on WireFactory, the base class for SourceWireFactory and
>> > TargetWireFactory.
>> >
>> > 3. Write a TargetInvoker implementation and extend
>> > WireBuilderSupport, overriding createInvoker. The latter creates  
>> the
>> > TargetInvoker, which is responsible for dispatching to an  
>> instance of
>> > the component type. This class also contains another method,
>> > handlesTargetType, which signals to the runtime which component
>> > implementation type the wire builder creates target invokers for. I
>> > intend to eliminate this as it may be reflected through  
>> generics. The
>> > TargetInvoker interface is pretty simple, one has to implement
>> > invokeTarget and clone.
>> >
>> > For component implementation types, a target invoker will generally
>> > take the scope context the component is associated with and resolve
>> > the component instance against it when it receives an  
>> invocation. The
>> > TargetInvoker may cache the resolved result if the source is of a
>> > lesser scope than the target (this information is passed into the
>> > WireBuilder). Don't cache resolves when going from a greater to
>> > lesser scope since that will result in "crossed" contexts. Clone is
>> > necessary since TargetInvokers are cached on the source side of a
>> > wire per operation and passed through both
>> > source and target invokcation chains, where it is "invoked" by the
>> > last interceptor in the target chain. TargetInvoker.clone() is  
>> called
>> > by the proxy invocation handler (e.g. JDKInvocationHandler) if the
>> > target invoker caches invocations on the first invoke of the
>> > operation and held there. Otherwise it uses a "stateless invoker".
>> > This allows us to optimize resolves away for sources of a lesser
>> > scope.  All of this is probably more detail than a component
>> > implementor will need to be aware of since the extension classes
>> > abstract this away.
>> >
>> > 4. Contribute the loader, ContextFactory, and WireBuilder
>> > implementations as a system module (along with the TargetInvoker
>> > class). They will automagically be registered in the runtime and
>> > everything should just work.
>> >
>> > Please take a look and provide feedback.
>> >
>> > Jim
>> >
>>
>>
>