Re: Physical Component Defintion
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 instanceFactoryByteCodeBase 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]
Re: Physical Component Defintion
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; instanceFactoryByteCodeBase 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: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org 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 instanceFactoryByteCodeBase 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/msnnkwme002001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx
Re: Physical Component Defintion
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 instanceFactoryByteCodeBase 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: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org 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 instanceFactoryByteCodeBase 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
Re: Physical Component Defintion
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 instanceFactoryByteCodeBase 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. We'll need to refactor the wire signatures. I think we'll be able to remove ServiceContract and Operation. I think we can stage this by creating parallel classes for wires and then changing over. 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? We will need additional data per operation such as the callback name. We can add this in as we go. 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: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org 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 instanceFactoryByteCodeBase 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
Re: Physical Component Defintion
From: Jeremy Boynes [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Physical Component Defintion
Date: Thu, 8 Feb 2007 20:13:10 -0800
On Feb 8, 2007, at 4:42 PM, Jeremy Boynes wrote:
On Feb 8, 2007, at 3:26 PM, Meeraj Kunnumpurath wrote:
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.
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.
I need something like this for the launched implementation type in the
client environment. I'll add a new implementation as a peer to PAC and we
can work out the builder for creating that.
Cool. Also, on the definition side I was thinking about creating classes
that encapsulate information on portable wire definitions etc. For example
..
public class PhycicalComponentDefinition extends ModelObject {
private URI componentId;
private SetWireDefinition inboundWires;
private SetWireDefinition outboundWires;
}
public class WireDefinition {
private URI wireUri;
private SetInterceptorDefinition interceptors;
anything eles needed to create the wire on the slave
}
I will start on this before I go on holidays today. I am back Monday
morning. I can carry on the federated model when I come back, also, I can
give a hand with stabilizing the runtime.
Ta
Meeraj
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
