The following commits got my attentions:
http://svn.apache.org/viewvc?rev=779058&view=rev
http://svn.apache.org/viewvc?rev=779059&view=rev
I think the consensus is to keep the workspace/workspace-impl to deal with a
collection of contributions. As we rebuild the domain story, there modules
are still needed.
Thanks,
Raymond
--------------------------------------------------
From: "Raymond Feng" <[email protected]>
Sent: Friday, May 08, 2009 10:19 AM
To: <[email protected]>
Subject: Re: Node usage of the workspace and implementation-node modules
+1 on the summary from Simon.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Friday, May 08, 2009 1:23 AM
To: <[email protected]>
Subject: Re: Node usage of the workspace and implementation-node modules
On Fri, May 8, 2009 at 8:02 AM, Mike Edwards
<[email protected]> wrote:
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.
I think I'm agreeing with Mike here.
Contribution* modules - process individual contributions gets my +1
Workspace* modules - process a collection of contributions (I would
include in this the cross-contribution dependency building stuff) also
gets my +1
A small adjustment. Not that different from what we have now.
Now, implementation.node. This is not a question of dependency but
function. I don't like that we use implementation.node in the way it
is currently used to represent node default configuration. At best
it's confusing. If the composite that describes a node were describing
the system services exposed by the node then fair game but that is not
the case now. However I fully expect this to be discussed and refined
during the process of implementing OASIS compliant domain function so
don't think we need to come to a conclusion during this more abstract
module dependency/structure discussion. So I suggest we defer this
part for another thread.
my 2c
Simon
