Raymond Feng wrote:
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
Raymond,
I am happy with the idea of the workspace as a way of coordinating numbers of
contributions.
The thing that I find VERY odd in the current arrangements is that the *MAIN* code for reading an
individual contribution is in the module workspace-impl, with some of its interfaces defined in
module "workspace".
Meanwhile, there is a module called "contribution" that does not contain the actual code for
processing a contribution, but mostly interfaces used by processors for things that you might find
in a contribution.
I think that this should be reorganized, so that actual contribution processing code is in
"contribution" and that "workspace-impl" has code for handling workspaces over the top of individual
contributions.
Yours, Mike.
