Hi,
Starting with the J2SE based runtime sounds like a balanced approach. I
think the embedded HTTP support (Tomcat or Jetty) will provide us the
web-based UI capability to install/uninstall/list contributions and
deploy/undeploy composites. I also see great similarity with the
Tuscany/Geronimo deep integration (Tuscany as a Geronimo plugin) where the
GUI can be an extension to the Geronimo admin console.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, January 27, 2008 9:34 PM
Subject: Re: SCA contribution packaging schemes: was: SCA runtimes
ant elder wrote:
On Jan 24, 2008 7:47 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
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.
3. List the contributions in the domain, store.jar shows a red-x error
as some of its imports are not resolvable.
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.
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.
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.
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
That all sounds wonderful, will be really good when we get to there.
There's
a lot to do for all that to work
There's not a lot to do. Most of the necessary work is to decouple all the
code that's implementing too much runtime magic getting in the way of the
simple scenario I've described here.
though so as a stepping stone how about
getting this to work on a single node first without the gui and
individual
deployment steps and then add those things once we have something basic
working?
Sorry to disagree, I'm approaching this the other way around:
1. Get the user experience and the UI right first.
2. Work through the individual steps and make sure they make sense.
3. Clean up all the magic code currently tying all the steps together, and
make the individual functions (add/remove a contribution, validate a
contribution, get a contribution closure) usable.
4. Lastly, implement minimal code to bootstrap a runtime node from a
deployed composite (for the last step in the scenario).
The basic idea is to drive the development of the underlying plumbing from
the scenario and user experience and not the other way around.
Where do we want this to run? - I'd quite like at least one of the
options
to be as a regular webapp in Tomcat.
I don't think that a Webapp is the right architecture but I may be wrong
or missing something, so you should probably just try and see for yourself
if this is what you want to do.
I'm more interested in getting the above scenario working well with one
option for now: the J2SE based runtime. That's what I've started to work
on.
--
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]
