Hi,
The workspace and workspace-impl modules were introduced to model a
collection of contributions that are added to an SCA domain. Basically,
Tuscany allows
you to provide a "workspace.xml" to pre-define a list of contributions for
an SCA domain. And the workspace model provides the "install contribution"
and "uninstall contribution" services for the SCA domain. It functions as
the "contribution service".
Furthermore, the "workspace" becomes a special archive of artifacts that are
SCA contributions. Now the SCA contribution is just an artifact that is
identified by the contribution URI and can be loaded by the URL. The
ContributionContentProcessor from workspace-impl is a URLArtifactProcessor
that uses the ContributionScannerExtensionPoint to parse contributions in
different packaging schemes such as Folder, JAR, or ZIP.
The other player in the SCA domain management is the Node. Node is a
configuration of a runtime (like a "SCA virtual machine") that is capable of
running an SCA composite application. The Node configuration includes the
base URI for protocols supported by a given SCA binding. It also defines a
list of contributions and a deployable composite that make up the SCA
composite application. At this moment, the node is modeled as
"implementation.node" (see [3]). It doesn't seem very natural to me. Maybe
we should use a different way, such as "node.xml" and NodeConfiguration
model.
The SCA domain manager is developed as an SCA application. It manages
contributions, composites and nodes in the SCA domain. You can add
contributions to the SCA domain. The SCA domain manager can then load the
contributions, find the deployable composites, resolve the dependencies as
well as the wirings. A resolved SCA composite application can then be
deployed to the SCA node. To provide remote access, SCA domain manager uses
binding.atom and packages the messages as ATOM feeds. See [1] and [2] for
more details.
I understand we also desire a more dynamic way to constitute an SCA domain.
But conceptually, all the underlying domain level services stay the same.
It's a matter of how the Workspace/Contribution/Composite/Node models are
built, statically or dynamically in a centralized or distributed fashion.
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain
[2]
http://www.ibm.com/developerworks/webservices/library/ws-sca-tuscany/index.html
[3]
https://svn.apache.org/repos/asf/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/implementation/node/xml/TestNode.composite
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[email protected]>
Sent: Thursday, May 07, 2009 2:44 AM
To: <[email protected]>
Subject: Re: Node usage of the workspace and implementation-node modules
ant elder wrote:
Currently the node-impl module has dependencies on implementation-node
and the workspace modules, I think its worth exploring if thats
necessary. In r772526 i've created a new node-impl2 module thats a
copy of node-impl but with no dependencies on implementation-node or
the workspace modules. It does include 4 classes copied from
workspace-impl and they're still in the o.a.t.s.workspace package to
make that obvious. Comparing the two node-impl modules i think this
makes node-impl2 significantly cleaner and shows that having those
contribution classes in workspace-impl may not be the correct place
and they'd be better in one of the contribution* modules.
Any comments?
...ant
Ant,
I too am puzzled by the presence of the Contribution related classes in
the workspace-impl module.
I could not make any sense of why they were there rather than in the
Contribution module.
Can anyone offer an explanation of why the Contribution code is organized
in this way?
If there is no good reason for the current split then I'd argue for moving
the code into the contribution module.
Yours, Mike.
