On Thu, May 7, 2009 at 5:39 PM, Raymond Feng <[email protected]> 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. >
I agree with you the implementation.node approach doesn't seem very natural, also the workspace modules are merging several functions that would be better separate. I think we need to revisit and refactor this by striping it down to as simple as possible and then putting back and moving functions around as appropriate, and thats whats been starting in node-impl2. The build and all tests pass using node-impl2 so how about replacing node-impl with that and going from there? ...ant
