Good summary. I have copied some of your text to the wiki page [2]. I also updated some of the diagrams at [3].

[3] http://cwiki.apache.org/confluence/download/attachments/2852380/sca-domain-node.pdf?version=2

Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Wednesday, September 30, 2009 3:37 AM
To: <[email protected]>
Subject: [2.x] reviewing/summarizing domain operation - was: Re: Discovery-based SCA Domain for OSGi RFC 119

Apologies that this is a bit of a long post....

I''d like to review some of the (orthoganol) choices a user has to
make based on what has been said on the referenced thread [1] and on
what has be said elsewhere.

Contributions
===================================================================

a1/ A single contribution
a2/ Multiple dependent contributions

where each contribution can be directories, jar, zip, bundle, war, ear...

Composites (when one or more are present in a contribution)
===================================================================

b1/ one or more composite files but which are not listed in
META-INF/sca-contribution.xml
b2/ one or more composite files but which are listed in
META-INF/sca-contribution.xml
b3/ one or more composite files but which are present in
META-INF/sca-deployables (is this still supported?)

Nodes (where node = the wrapper for an instance of Tuscany runtime)
===================================================================

c1/ node(s) with contributions passed in on command line,
programmatically, in node.xml or discovered from classpath
c2/ node(s) with contributions pulled from domain manager
(configuration is a URL)
c3/ node(s) in a webapp
c4/ node(s) as eclipse project(s)
c5/ node(s) integrated into Tomcat and Geronimo plugin
c6/ node(s) as OSGi service listeners? (is that the right term?)
c7/ node(s) in cloud (what does this mean)

One or more nodes may run in a single VM

Scenarios (and implications for what the runtime has to do)
===================================================================

1/ 1 node configured from command line, programmatically, in node.xml (c1)
  1 or more contributions are described in a node configuration
  node is started with node configuration
  services are immediately accessible

2/ >1 node configured from command line, programmatically, in node.xml (c1)
  each node has separate node configuration detailing domain name and
contributions
  each node is started with node configuration
  nodes exploit distributed registry to locate remote service
endpoints in same domain during wire resolution

3/ 1 node packaged with webapp (c3)
webapp is configured with a filter to run webapp contents as SCA application
  webapp deployed to unchanged container

4/ tomcat instance as a domain (c5)
  Webapp (jars/zips) equate to contributions
  tomcat extenstion runs contributions in nodes in single JVM
  nodes form domain using local version of registry in single JVM

5/ eclipse workspace as domain (c4)
  click on composite and start node
  nodes communicate using local registry (simplification of domain
manager approach that is in 1.x)

etc.

As a review exercise can we correct/complete this list by getting all
of the scenarios people have in their heads out on the table. I
believe we have all imagined different scenarios.


APIs (Resulting from above)
===========================

This is a TODO for this review. This is a mildly enhanced version of
what we already have or have discussed at various times.

Node
 Create with configuration
 Create with URL of configuration
 start
 stop

Endpoint Registry (should this be domain registry now)
 Add/remove/query endpoints
 Add/remove/query domain policy (new)

Domain Manager
 Add/Remove contribution
 Add/remove node
 Deploy/undeploy composite and associate with node
 Start/Stop node (do we need to maintain this in the domain manager?)
 Query (some work has been done on this but I've not tried it)
 (the domain manage is really made up of a number of service
interfaces including these here and the endpoint registry)

etc.

If we can give some more shape to this I propose we record what we
come up as an article on the 2.x documentation pages. In the short
term we can combine with the information on the wiki at [2]

Regards

Simon

[1] http://www.mail-archive.com/[email protected]/msg09220.html
[2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Domain

Reply via email to