I think there are a couple of extra things needed here:
Firstly, just a list of <interceptor>'s is not going to be enough. We
really need each one to be configurable, something like:
<inBoundWires>
<wire uri="wire1">
<int:cloner ... params .../>
</wire>
where the <int:cloner> element identifies the appropriate clone
interceptor.
We also need to be able to define physical bindings, so the wire may
not be one that connects the component to another component in that
runtime, but to a transport binding used to call another node:
<outBoundWires>
<wire uri="wire3">
<transport:axis2 .. binding params ... />
</wire>
On the last note, it might be easier for now to add a new Component
implementation that was created by the PCB rather than trying to
retrofit PojoAtomicComponent.
--
Jeremy
On Feb 8, 2007, at 3:26 PM, Meeraj Kunnumpurath wrote:
Thanks Jim.
Based on what you said, this is how plan to have the on the wire
XML representation of the Java Physical component definition.
<componentJava componentId="uri" xmlns="http://tuscany.apache.org/
xmlns/1.0-SNAPSHOT">
<instanceFactoryByteCode>Base 64 Encoded byte code</
instanceFactoryByteCode>
<inBoundWires>
<wire uri="wire1">
<interceptor uri="int1"/>
<interceptor uri="int2"/>
</wire>
<wire uri="wire2">
<interceptor uri="int1"/>
</wire>
</inBoundWires>
<outBoundWires>
<wire uri="wire3">
<interceptor uri="int3"/>
<interceptor uri="int4"/>
</wire>
</outBoundWires>
</component-java>
The wire and policy metadata will be defined in the base class
PhysicalComponentDefinition, since they are applicable for all
component types and not just the Java component type. This will get
unmarshalled on the slave and passed into the builder. The builder
would create the InboundWireImpl and OutboundWireImpl instances and
add them to the component. Would we need anything more than the URI
when the wire instances are created by the builder. If yes, would
that be part of the physical component definition as well?
Also, for the JavaAtomicComponent, I am planning to pass in the
instance factory into the component from the builder, so that it
can be used later when createInstance is called. I am also
wondering with all these changes, is it worth simplifying the
PojoAtomicComponent and JavaAtomicComponent , since most of the
stuff in PojoConfiguration is going to be encapsulated in the
dynamically generated byte code for the instance factory. Maybe,
Jeremy has a view on this as well.
Ta
Meeraj
From: Jim Marino <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: Physical Component Defintion
Date: Thu, 8 Feb 2007 14:43:40 -0800
On Feb 7, 2007, at 2:49 PM, Meeraj Kunnumpurath wrote:
Jim,
I have been looking at the work you have been doing with
component manager and URIs and figuring out how this would fit
in with federated deployment model I have been working on.
Currently, the master creates the physical component defintion
to get the component running on the slave. This gets marshalled
and sent to the slave through the discovery service. On the
slave this is picked up by the federated deployer to be
umarshalled using the marshaller framework. The component gets
built from the physical component definition by the new builder
framework. The XML fragment for Java components looks as follows,
<componentJava componentId="uri" xmlns="http://
tuscany.apache.org/ xmlns/1.0-SNAPSHOT">
<instanceFactoryByteCode>Base 64 Encoded byte code</
instanceFactoryByteCode>
</component-java>
I was thinking about wrapping the loaded instance factory into
the JavaAtomicComponent in the javaPhysicalComponentBuilder and
expect the wires to be resolved when createInstance is called on
the component. Would you need any additional information on top
of the instance factory to create the wires, interceptors,
policies etc on the slave.
Yes, I think we will eventually need information to constitute
interceptor chains on the slave. I was thinking the policy
builders would be run on the master and serialize wire
information as part of the portable component definition. On the
slave, a series of interceptor builders would be used to add
interceptors to a wire as it is created by the WireService on a
slave. This would effectively split our single-VM wire
construction process across VMs and enable our federated design.
All of the wire processing, normalization, and optimization would
be done on the master. On the slave, the interceptor builders
could be dispatched to based on a QName and would just be
responsible for providing portable interceptors. We will also
need to allow for extensible interceptor information but the
serialization/deserialization process should work similar to the
way Marshallers work.
Wires could then be handed to the instance factory for use in
injection. This give us a completely distributed wiring engine
that is very fast :-)
Also, where do you expect the autowire aspects resolved?
I would expect autowire to be resolved as the model is processed
on the master. This will allow us to remove autowire
specializations from the slave. I plan to do this in steps.
First, move autowire from CompositeComponent to ComponentManager.
Then, move it from ComponentManager to the resolve step during
loading. As we move it to loading, I also plan to implement it
according to the recent 1.0 spec changes.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Laugh, share and connect with Windows Live Messenger http://
clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://
imagine-msn.com/messenger/launch80/default.aspx?locale=en-
us&source=hmtagline
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
