Hi,
I think it's better to discuss the design in the context of a simple
scenario so that we can see the whole picture. I'm giving a try to capture
what I understand. Please forgive me if there's anything dumb and help me
complete/fix it.
1) For the purpose of illustration, let's assume that we have a SCA domain
(D1) with two active runtimes: R1 and R2. R1 is running on machine M1 and R2
on machine M2.
There is a logic composite (Composite0) representing the SCA domain D1.
2) An SCA application is developed and packaged as a jar file. The jar file
contains a SCDL to represent a compoiste Composite1 with two components:
Component1 and Component2. The SCDL file references a global element or type
in a.xsd by QName for property definitions.
MyApp.jar:
sample.Component1Impl
sample.Component2Impl
META-INF/sca/default.scdl
xsd/a.xsd
The jar file is contributed to the SCA domain. Some services will be
responsible for scanning/loading artifacts in the contribution. Is
"ContributionProcessor" or "ContributionService" for this purpose?
Is artifact resolving going to happen during this phase?
3) A service (AssemblyService?) will add Composite1 to the logical composite
representing the SCA domain.
Then the SCA domain will be:
Composite0:
include Composite1:
Component1
Component2
4) We decide to deploy Composite1 distributedly: Compnent1 to runtime R1 and
Component2 to runtime R2.
R1: Composite1.Component1
R2: Composite1.Component2
So a subset of Composite1 (physical model?) will be sent to R1 and the other
to R2 using some sort of XML messages. Component1 is activated at R1 and
Component2 is activated at R2. They are now running.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, January 29, 2007 4:17 PM
Subject: Re: Federated Deployment (was SCDL Location in Composite
Implementation)
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
