On Feb 3, 2007, at 1:01 PM, Meeraj Kunnumpurath wrote:
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.
This should fit in quite well since the component manager will
support a federated component tree (parents and children are
referenced through URI, not directly). The new deployer can register
directly with the CM. The latter will be used by the connector to
wire source to target. This will allow us to remove the distinction
between composite/atomic components. It will also allow us to move
autowire into the resolve phase so the Connector and
CompositeComponent implementations will not need to traverse the
component tree; in fact, direct references to parents and children
will not be held and will instead be managed through the CM's URI
approach. After that, we can get rid of SCAObject.isSystem since that
can be accommodated by the URI scheme to give us a compact wiring
engine. As we progress, we will also want to allow for wire-path
optimizations, probably by the master. I think we can do some very
interesting things with federated autowire and path-analysis.
I'm in the process of doing the refactors to core to incorporate the
CM. This may take a little while but I will try and stage it as best
I can.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
