Hi,
Thank you for describing the scenario. It's really helpful to understand how
all the pieces work together from a user perspective.
I have a few comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, January 24, 2008 11:47 AM
Subject: Re: SCA contribution packaging schemes: was: SCA runtimes
ant elder wrote:
[snip]
The (F), (G) and (H) would use the packaging in your (B). For your (B)
how/where were you expecting those sca contribution jars to get used?
Ah I'm happy to see that there are not so many packaging schemes after all
:)
We've already started to discuss contribution usage scenarios in [1].
Here's a longer scenario, showing how I want to use contributions and
composites in a domain for the store tutorial I've been working on.
There are three contributions in the tutorial:
- assets.jar containing most implementation artifacts
- store.jar containing the main store components
- cloud.jar containing utility components in the service "cloud"
Both store.jar and cloud.jar import artifacts from assets.jar.
1. Create assets.jar and store.jar (using scheme B).
2. Open my tutorial domain in my Web browser, upload store.jar to the
domain.
A degenerated case is to copy store.jar to a folder containing the
contributions for a given SCA domain. But the web-based management is better
suitable for a distributed env.
3. List the contributions in the domain, store.jar shows a red-x error as
some of its imports are not resolvable.
We could have something similar to the OSGi console to show the status of
each contribution (such as INSTALLED, RESOLVED). For those that cannot be
fully resolved, we should be able to tell which "import" is not satisfied.
4. Upload assets.jar. Both assets.jar and store.jar show in the list with
no red-x.
5. List the deployable composites, find http://store#store under
store.jar. Open it in my browser to check it's what I want.
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.
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. Or the GUI could select the required
contributions/composites as we mark one deployable composite.
8. Assuming I have 2 machines for running SCA in my network and have
already declared these 2 machines to my domain, allocate composites to
them. Select http://store#store and associate it with machine1. Store.jar
and assets.jar are downloaded to machine1 and machine1 configured with
http://store#store.
I assume the closure (a set of contributions required by the deployable
composite) should be downloaded.
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?
10. Display the list of deployed composites, select http://store#store,
click the start button, select http://cloud#cloud, click start.
Hope this helps.
[1] http://marc.info/?l=tuscany-dev&m=119952302226006
--
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]
