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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
