From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: Federated Deployment (was SCDL Location in Composite
Implementation)
Date: Mon, 29 Jan 2007 16:17:21 -0800
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.
I think, regardless of the serialization mechanism that used to represent
the wire-level representation of the transported physical model, the
collaborating runtimes will have to agree on the same discovery protocol.
For example, if a Java runtime chooses to use JXTA as the protocol for
distributing physical model artifacts, the target C++ runtime will have to
agree on the same protocol.
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).
Yeah, a message listener will be selected based on the QName of the payload
and the builder will have injected depenedncies of whatever components that
are required to perform any downstream processing like reconstituting the
physical model in memory, calling the builder, deployer etc.
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.
In addition to the physical model, there will also be control commands like
start/stop component etc. I think it will be useful to have a definitive
list of infoset exchanged between the master and slave runtimes. Both in XML
and the equivalent Java model classes.
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.
The current builder abstraction accepts the parent component, component
definition and deployment context to build the component. Would any
additional information you envisage in building a component in the federated
model be included in the component definition?
--
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]
