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.
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? Also can the current
deployer/loader/builder framework be used for deserializing the physical
model objects and applying the changeset on the target runtime?
Ta
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: SCDL Location in Composite Implementation
Date: Mon, 29 Jan 2007 15:24:56 -0800
The normative reference here is the name of the composite being used -
scdlLocation and scdlResource are things we've added to allow that name to
be resolved in a Java runtime as, to date, there is no spec- defined
mechanism for doing that. This is related to the artifact resolution
thread Raymond and I are having.
In the federated case, I don't think that we can use the user- supplied
SCDL to define what needs to be deployed. This is because the logical
model supplied by the user can be mapped to different physical
environments - for example, a single composite could be decomposed to
multiple physical runtimes resulting in components from it being
physically deployed separately. If that happens, what is physically
running is not the user-supplied model but some subset of it.
I think we can handle this in a couple of ways. One is to synthesize
composites to represent the physical deployments; this has the advantage
of reusing the existing model but the disadvantage that it conflates the
logical and physical models. Another is to add extensions to the logical
model to reflect physical characteristics and then have each runtime just
deploy the bits that are relevant to it; again this conflates the logical
and physical models. A third is to separate logical and physical models
entirely, passing to the runtimes just the information needed to build the
runtime objects (basically a physical model); I think this is our better
option as it separates the logical and physical concerns which is in line
with our existing separation between config model and runtime objects.
Coming back to the original subject, this would mean that things like
scdlLocation or any other artifact resolution metadata would only apply
where the logical model was being processed. When it comes to the physical
representation, these would have already been resolved and converted to
their physical representation which would be passed to the target runtime
/by-value./ All references would have been converted and the component
builders on the target runtime would have a complete definition to work
from.
I think we have to do this. If we pass references down to the targets then
we run the risk that different targets will process the references
differently leading to inconsistent deployment across the federation.
--
Jeremy
On Jan 29, 2007, at 2:30 PM, Meeraj Kunnumpurath wrote:
Hi,
Currently SCDL location is modelled as a URL in CompositeImplementation
class. This works ok as long as the SCDL is loaded from a URL. However,
with the stuff I am working on with federated assembly, an SCDL may be
transported into the runtime through the discovery mechanism and thw SCDL
contents may be materialized fully in memory. I was wondering whether we
need a higher-level abstraction than URL or stick with URL and write
custom protocol handlers were the source for the URL is not a standard
one (an in-memory byte array for example).
To give a bit of context, I have been thinking of using the existing
deployer/loader/builder framwork that is used for local deployment in the
federated scenario as well.
Thanks
Meeraj
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
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]
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
