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]
