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
