I have some concerns over the proposed approach to use one JVM to find out
how the SCA domain works. IMO, it might lead us to oversimplified
assumptions. I would rather start with two JSE standalone nodes that are
part of an SCA domain. Using Tomcat webapp also has the risk to mix non SCA
domain related issues into the picture.
1) One JVM running with one Node (standalone)
2) One JVM running with multiple Nodes (webapp or OSGi)
3) Multiple JVMs running 1 or 2 in the same SCA domain
We already have some stories for 1 and 2. The simplest form for 3 would be
two JVMs with each running with a standalone Node.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <antel...@apache.org>
Sent: Friday, May 29, 2009 3:43 AM
To: <dev@tuscany.apache.org>
Subject: Re: Discovery-based SCA Domain for OSGi RFC 119
On Thu, May 28, 2009 at 11:39 AM, Simon Laws <simonsl...@googlemail.com>
wrote:
I'd like to expand a little on what actual scenarios are being
discussed here.
This discussion may well go on and on without achieving much as
happened in some previous discussions without specific objectives so
as a concrete scenario as what i'd like to get working is the SCA
domain used by the new Tuscany Tomcat integration which would work as
follows:
- The tomcat instance would be a domain. It could also be useful for a
Tomcat instance to contain multiple domains or be part of a wider
domain but i'd like to leave those complications to later.
- SCA contributions (webapps and jars/zips etc) can be added during
runtime so the domain needs to support adding and starting
dynamically. Stopping, updating, and removing would be good too but
that can be left till later
- The domain is running within a single JVM so it doesn't need any
remote distribution technology which helps keep things simple
- It would be great to also get the SCAClient API able to talk to the
Tomcat domain from a JSE client. I guess thats a slightly different
topic but it might be useful to keep it in mind
This seems simple and familiar enough that we'll all be able to
understand it and we have most of that in place now other than being
able to wire across the Tuscany Nodes so it should be easy enough to
implement and test as we work out and agree on what to do for the
domain. I don't think it matters if it uses the "node or domain
centric" approaches that have been mentioned, or uses the existing
Node classes or some new Domian APIs and interfaces, we just need to
get something working so we can show some progress.
Does anyone want more detail on any of that? Or disagree with having
this as something to achieve?
...ant
