2.x Version1 - 26/8
Need to define what the different parts do and if they are all required
SCA Domain/Node Diagrams (PDF) (OpenOffice odg File)
Composite Application Deployment with SCA Domain
Players:
- Domain Manager
- Endpoint Registry
- Node
- TuscanyKernel (NodeManager)
- JVM
Domain:
1) Deployment: Manage SCA contributions, composites and node configurations.
This is the deployment manager that helps SCA assemblers/deployers to
partition the domain composite into smaller composite applications that can
be deployed a specific runtime unit. For example, the administrator can
starts with a deployable composite. The domain manager can then find the
required contributions based on the import/export. The composite application
can then be allocated a node. It ends up with a configuration for a node.
A node can have a fixed configuration to a given composite application. Or
the domain can assign a composite application to the node dynamically based
on the capability of the node (such as implementation/binding/policy types).
In a node-centric view, node configurations can be manually crafted
(programmatically or via node.xml) or locally discovered (from the
classpath).
In a domain-centric view, node configurations are received from the domain
(by connecting to the domain deployment manager or taking a pre-built xml
document).
2) Runtime: Share service descriptions so that we can perform SCA
domain-level wiring. This can be done in "online" mode or "offline" mode.
Online mode: There is a live service registry (centralized or distributed)
that keeps up-to-date information of the domain-level service descriptions.
Offline mode: The domain-level service descriptions are pre-built (or even
pre-resolved) and a SNAPSHOT of that is used. For example, some XML
documents (such as a deployment composite with all the SCA endpoints)
resolved are used to store the domain metadata.
Variations of use cases at different levels
Contributions
Case |
Options |
---|---|
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 |
|
b2 |
one or more composite files but which are listed in |
|
b3 |
one or more composite files but which are present in |
|
Nodes (where node = the wrapper for an instance of Tuscany runtime)
|
|
|
---|---|---|
c1 |
node(s) with contributions passed in on command line, |
|
c2 |
node(s) with contributions pulled from domain manager |
|
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 node configured from command line, programmatically, in node.xml (c1) |
|
|
1 node configured from command line, programmatically, in node.xml (c1) |
|
|
1 node packaged with webapp (c3) |
|
|
tomcat instance as a domain (c5) |
|
|
eclipse workspace as domain (c4) |
|
|
|
|
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.
Entities |
Operations |
Descriptions |
---|---|---|
Node |
Create with configuration |
|
Endpoint Registry (should this be domain registry now) |
Add/remove/query endpoints |
|
Domain Manager |
Add/Remove contribution |
|