tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Meeraj Kunnumpurath" <m.kunnumpur...@hotmail.co.uk>
Subject Re: Federated Deployment (was SCDL Location in Composite Implementation)
Date Sat, 03 Feb 2007 21:01:52 GMT

I have been working on the marshallers for the physical model, so that they 
can be transported from master to slave runtimes in a federated model. I 
think what you suggested is closely related to what I am working on. If I 
understand you right,

1. The assembly service on the master will create the physical model from 
the logical model
2. The Java physical model could be as simple as having the runtime 
generated byte code for the instance factory, with your second option
3. The marshaller framework will marshal the physical model and send it to 
the target slave through the discovery service
4. On the slave, the federated deployer will unmarshall the physical 
component model and use the builder to create the live component
5. This would require changes to the current builder framework and I can see 
this should simplify the current builders quite a bit.
6. What I would suggest is to start a new builder framework in parallel and 
deprecate the old one. The current deployer can continue to use the old 
builder framework and the federted one will use the new one. Once we have 
the builders for all the current component types, we can get rid of the old 
7. The builder will use the instance factory to create the component and 
wire all the properties and references.
8. I don't know whether this fits in with the component manager stuff Jim is 
working on, I would assume the federated deployer will have to call the 
component manager to register the component.

I have already started on the physical model. Since, this fits in closely 
with the physical model and federated deployment, I can include the new 
builder framwork in the work I am doing currently.


>From: Jeremy Boynes <jboynes@apache.org>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Re: Federated Deployment (was SCDL Location in Composite 
>Date: Sat, 3 Feb 2007 12:38:38 -0800
>On Jan 29, 2007, at 6:50 PM, Jeremy Boynes wrote:
>>Instead, I think the data sent should define the configuration data  
>>needed by the JavaComponentBuilder, something like:
>>    <java:component xmlns:java="http://tuscany.apache.org/xmlns/java/ 1.0"
>>                    uri="http://www.example.com/D1/Component1"
>>                    scope="Composite"
>>                    eagerInit='true'>
>>      <implementation class="sample.Component1Impl"  classLoader="MyApp"/>
>>      <constructor>
>>        <param class="sample.Component2">
>>           <rmi:binding xmlns:rmi="http://tuscany.apache.org/xmlns/ 
>>rmi/1.0" uri="http://m2:1099/D1/Component2"/>
>>        </param>
>>      </constructor>
>>      <injection>
>>        <method name="setP1" type="java.lang.String">
>>           <java:simpleTypeFactory>fooValue</java:simpleTypeFactory>
>>        </method>
>>      </injection>
>>   </java:component>
>>The XML is meant to be illustrative. It's also meant to be internal  to 
>>the runtime and not editable by users :-)
>I was thinking about this and about the number of XML entities needed  to 
>define the input for the builder. We don't need all the  flexibility here 
>as the generator and the builder are very closely  coupled (down to the 
>version level). In light of that, we can  simplify the generator and 
>builder implementation simply by hard  wiring this to bytecode. This has 
>other advantages as well in terms  of runtime simplicity and performance, 
>it would also allow users  willing to dig into the Tuscany SPIs to provide 
>their own factory.
>The basic change here would be to define an InstanceFactory that  returns a 
>fully initialized instance for the target component:
>class InstanceFactory<T> {
>   InstanceWrapper<T> createInstance();
>The implementation of this can be provided by the user (which allows  
>codegen at development time), generated during contribution, or  generated 
>during logical->physical mapping. The resulting physical  component 
>definition would be:
>    <java:component xmlns:java="http://tuscany.apache.org/xmlns/java/ 1.0"
>                    uri="http://www.example.com/D1/Component1"
>                    scope="Composite"
>                    eagerInit='true'>
>      <instanceFactory classLoader="MyApp"  
>   </java:component>
>    <java:component xmlns:java="http://tuscany.apache.org/xmlns/java/ 1.0"
>                    uri="http://www.example.com/D1/Component1"
>                    scope="Composite"
>                    eagerInit='true'>
>      <instanceFactory classLoader="MyApp">$ 
>   </java:component>
>depending on where the generation was done (i.e. is the factory  already in 
>the MyApp classloader or not).
>All property and physical binding configuration can be handled by the  
>implementation of this factory. The builder though would still need  to be 
>involved to ensure all the local wires in and out of the  component were 
>connected. It could pass the outbound reference  factories to the 
>InstanceFactory implementation during construction.
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Get Hotmail, News, Sport and Entertainment from MSN on your mobile.  

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

View raw message