Jeremy,
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
ones.
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.
Ta
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Federated Deployment (was SCDL Location in Composite
Implementation)
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"
class="sample.Component1Factory"/>
</java:component>
or
<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">$
{base64EncodedBytecodeForTheFactory}</instanceFactory>
</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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.
http://www.msn.txt4content.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
