Comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, January 24, 2008 2:11 PM
Subject: Re: SCA contribution packaging schemes: was: SCA runtimes
Some more input on steps 7 and 9.
I agree with your other comments (snipped out to keep this short).
Raymond Feng wrote:
[snip]
7. Upload cloud.jar, find deployable composite http://cloud#cloud in it,
mark it deployed. The red-x on deployed composite http://store#store is
now gone.
We should be able to deploy multiple composites in one shot as they might
have cross-references.
Yes, but the simple "one composite at a time" deployment scheme that I
described still supports your cross-reference case, or am I missing
something?
I'm a bit confused by that your statement in :
6. Mark http://store#store as deployed. Store has a reference to a
CurrencyConverter service (from composite http://cloud#cloud which is
not in my domain yet) so it shows a red-x and appears disabled.
In this case, the target service is not in my domain yet, but it shouldn't
prevent http://store#store from being assigned to a node to start the
composite. The relationship between the reference and service is
loosely-coupled, right? It could be a warning though.
I assume when we select a deployable composite from a contribution, we just
have to create a collection of contributions required to deploy the
composite. Let's say let have two deployable composites http//store#store
and http://cloud#cloud. It could end up with two downloadable zips:
store.jar & assets.jar for store composite and cloud.jar & asset.jar for
cloud composite. One zip can be downloaded to machine 1 and the other goes
to machine 2. There is no need to check if a reference in store composite
can be fulfilled by a service in cloud composite.
Or the GUI could select the required
contributions/composites as we mark one deployable composite.
We could do that, except that the required composites might not be
available in the domain yet.
I should say required contrbutions.
[snip]
9. Select http://cloud#cloud and associate it with machine2. Cloud.jar
and assets.jar are downloaded to machine2 and machine2 is configured
with http://cloud#cloud.
Who initiates the download? Is it a pull or push model?
I was thinking about push: the domain triggers the download.
To avoid over-engineering this too quickly, how about starting simple and
just generating a zip of the artifacts and let the administrator FTP and
unzip it on the target machine?
In other words I think we need to be comfortable with executing the
install / resolve / deploy / configure / distribute steps manually before
trying to automate them.
It's import to keep all these steps separate and manually operatable. For
example, we could expose management services over JMX, and the control be
invoked from any JMX-enabled consolse/command line.
--
Jean-Sebastien
---------------------------------------------------------------------
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]
