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]
