On Jan 29, 2007, at 3:47 PM, Meeraj Kunnumpurath wrote:
Based on the third option, I think we need to come up with the
following,
1. Classes that represent the physical model that represents the
artifacts sent to target slave runtimes for deployment.
2. A component that is responsible on the master runtime
responsible for assembling the physical model from a logical
assembly and interacting with the discovery service to transport
them to remote slave runtimes.
3. An inter-operable serialiation protocol that is used to
represent the physical model on the wire.
4. A framework for handling the serialization/de-serialization
between physical model objects and their wire-level representation.
5. A component that is responsible on the slave runtime to deploy
the deserialized model objects.
Agreed.
For 3, I think we should use XML for that as there is no guarantee
that the source and target runtimes will be implemented using the
same technology. The content would be the XML types defined in by 1)
and that must be extensible and versioned. Serialization between wire-
format messages (XML) and in-memory mode should be selectable by each
runtime implementation - the Java kernel uses custom loaders for
this, I believe the C++/Native kernel uses SDO.
For 5), I think the component/message processor would be fairly
lightweight - most of the work should be in the builders (with which
builder to use selected by QName of the config object).
One key question is how much of this do we need to build from
scratch and how much we can leverage on the existing assets. Can
the physical model leverage on the existing model classes?
I used to think so but recently I've been thinking we should separate
logical from physical. The logical model objects would represent SCDL
concepts, the physical ones would be lower level targeted as input
for the builders. For example, to build a Java component, the builder
for it should be passed a definition for the implementation,
injection sites, value factories, inbound and outbound wires with
interceptor chains and binding definitions.
Time permitting, I'll try and post a snippet for this tonight.
Also can the current deployer/loader/builder framework be used for
deserializing the physical model objects and applying the changeset
on the target runtime?
Framework wise, yes I think so although from above I think we need
more information in the handoff to the builder.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
