Current state of the SPI?

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

With trying to get containers and bindings going in the trunk again and it
looks like with all the core changes the SPI is a little out of date now.
Eg, there's classes like InsanceWrapperBase in the core that could be in the
SPI, TargetInvokerExtension could have more methods on TargetInvoker,
there's a whole bunch of old methods on AtomicComponent that aren't in
AtomicComponentExtension so have to be implemented in new Component impls,
etc. What are the plans for cleaning up this type of thing? I know there's a
a whole lot of change going on in the core right now so should i just wait
for that to settle down a bit before thinking about tidying up the SPI?

   ...ant

Re: Current state of the SPI?

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

On Mar 16, 2007, at 4:16 AM, ant elder wrote:

> With trying to get containers and bindings going in the trunk again  
> and it
> looks like with all the core changes the SPI is a little out of  
> date now.
> Eg, there's classes like InsanceWrapperBase in the core that could  
> be in the
> SPI, TargetInvokerExtension could have more methods on TargetInvoker,
> there's a whole bunch of old methods on AtomicComponent that aren't in
> AtomicComponentExtension so have to be implemented in new Component  
> impls,
> etc. What are the plans for cleaning up this type of thing? I know  
> there's a
> a whole lot of change going on in the core right now so should i  
> just wait
> for that to settle down a bit before thinking about tidying up the  
> SPI?
>
>   ...ant
Yeah we're in the process of trying to cut-over but do it in a way  
that does not break things. Consequently there are a lot of  
deprecated APIs. What we are trying to do is simplify the extension  
model along these lines:

1. ServiceBindings and ReferenceBindings will go away and people just  
write Components for extensions. This means wires in the runtime will  
be connected in on of the following ways:

- Component to Component. This is the basic case where a component  
reference is wired to a component service, i.e. two components wired  
together

- Transport binding Component to Component. For example, a component  
service exposed as a web service in the runtime could be a wire  
running from the Axis extension Component to the application  
Component providing the service. The Axis extension service may have  
to work with a ServletHost to accept incoming requests and pass then  
down one of the Wire's invocation chain.

- Component to transport binding Component. This is when an  
application component reference is wired to a composite reference  
that is configured with a binding. In the web services example, the  
transport binding Component would be responsible for taking  
invocations as they flowed through InvocationChains on the wire and  
flowing them out over the transport.

We have a new interface, WireAttacher, which is responsible for  
connecting a wire to a particular component type on the source and  
target sides. Each binding extension, component implementation type  
extension, etc. would provide an implementation. The same class that  
implements PhysicalComponentBuilder can also implement WireAttacher.  
The WireAttacher will have access to specific metadata for attaching  
the wire as subclasses of PhysicalWireSourceDefinition or  
PhysicalWireTargetDefinition. These can contain specific information  
related to the binding. A transport binding Component may also expose  
a specific contract for the WireAttacher to use when it give it the  
Wire.

2. We also don't need TargetInvoker anymore. Since we can perform  
wire optimization (i.e. just pass a direct reference), and we have  
the WireAttacher, the InvocationChains will just have interceptors.  
Typically, during the wire attach process for the target, an  
interceptor will be added to the chain. For Java component  
implementations, the JavaInvokerInterceptor does this. It is similar  
to TargetInvoker but is one less concept. Also, later, I think this  
design will allow us to further decompose some of the functions that  
were in TargetInvoker related to conversations out into separate  
interceptors thereby making the design cleaner.

I've made a start on the Hessian Binding  if you want to take a look  
for some examples.


Right now we have this refactored invocation and wiring  
infrastructure in place. We just need to connect this to the  
federation and marshalling parts over the next day or so. Once that  
is in place, all of the deprecated stuff can be removed.

One of the specific things that need to be done is we need to  
"bridge" the logical assembly model and the physical model used to  
instantiate runtime artifacts. As some background, in federation,  
there will be a master "Controller" (right now it is one physical  
node but in the future could be many) and "slave" nodes. When an  
assembly is contributed, it will be processed and indexed by the  
contribution service on the Controller. This would involve  
determining things like the component type. When a component is  
"deployed", the Controller will be responsible for converting the  
logical assembly model (basically what can be represented by SCDL)  
into a physical model. These will be done by Generators.

Generation is a multi-step process. The first step is to take a pass  
resolving autowires against the SCA Domain (the Controller always has  
a representation of the Domain). Once this is done, the Generators  
will convert ComponentDefinitions to PhysicalComponentDefinitions.  
The PCDs are a compact representation of the configured component  
used by the slave nodes to create Components. This process will be  
done by PhysicalComponentBuilders.

The second step is for binding target URIs expressed as SCA component  
names to be converted into URIs representing a node or series of  
nodes where the service is in the Domain. This is an area that needs  
a lot more work and thought. For example, I'm interested in how this  
process would interact with components targeted to a JEE application  
server. In WebLogic (I'm sure others are similar), we have an admin  
server that is responsible for distribution across a WLS cluster. It  
may be that URI's are resolved in stages and the Controller needs to  
talk with a "provisioner" on the WLS admin server that can provide  
further information.

Once this is done, the third step is to normalize wires. For example  
the following wire path:

Component A --> Composite Reference --->Composite Service --- 
 >Component B

can be normalized to:

Component A--->Component B

or

Component A-->Binding Component

Binding Component-->Component B

depending on whether a binding is configured or not.


Once we have the wire normalization in place, the Generators will  
create PhysicalWireDefinitions. This will contain a list of  
interceptor types by QName and other wire-specific information.  
Extensions may add additional metadata.

After we have a list of PhysicalComponentDefinitions and  
PhysicalWireDefinitions, we marshall them to slave nodes. On the  
slave nodes, they are de-marshalled and run through the builders by  
the FederatedDeployer. The Connector is then called to create wires  
from PhysicalWireDefinitions. During this process, it calls  
WireAttachers to connect wires to their target and source components.

There some more detail in this process so as you work your way  
through things, I'm sure one of us will answer any questions that  
come up.

Jim


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org