Composite Application Deployment with SCA Domain

The sample scenarios

A retail application is built using SCA. The application is developed and packaged as 3 contributions:

Asset: The common interfaces such as Catalog, Cart, Total
Store: The java implementation of Catalog, ShoppingCart and CurrencyConverter
Store-Client: The store client implementation

Both Store and Store-Client have dependency (importing the interfaces) on Asset.

There are two deployable composites:

StoreClient: It contains the StoreClient component with references to Catalog, Cart and Total
Store: It contains the ShoppingCart, Catalog and CurrencyConverter components

The application will be deployed to different machines or JVMs:

StoreClient: Run the store client
Store: Run the store services

Illustration of an SCA domain

Deployment Steps

Steps	Domain Services	SPIs	Tools	Note
Add Assets, Store, and StoreClient contributions to the domain	Install/Uninstall contributions	Workspace	Static: Add contribution URLs to the SCA domain manager Create a workspace.xml to list the contributions Add contributions to a repository Dynamic: Discover contributions from the network Watch a "contributions" folder	We can build different ways to make contributions available to the SCA domain.
Parse the contributions	Contribution Processing	ContributionScanner ArtifactProcessor
Resolve dependencies across contributions	Import/Export resolution	ContributionDependencyBuilder	Automatically calculated using the import/export Assembler can use the admin tool to select a list of contributions for a given composite application	We need to find out a collection of contributions to support a composite application based on the import/export statements
Find/Load/Resolve the composites from the contributions: Store composite StoreClient composite	The assembly builders	ArtifactProcessor CompositeBuilder	The endpoints using SCA addresses or relative URIs should be resolved against the physical base URIs for the bindings based on the node configuration. The resolution can be deferred to runtime over a service registry (which I treat it as a way to form the SCA domain dynamically)	Deployable composites can be designated by the contributions. It's also possible that the assembler to define a deployment composite on the fly.
Configure two nodes to the SCA domain, one to run the StoreClient and the other for Store. The Store one requires WS, ATOM and JSONRPC	implementation.node	NodeImplementation	Node can be predefined to the SCA domain using the admin tools. Node can also be provisioned from the cloud based on the requirements by the composite. Node can also be discovered on the network.There are types of nodes too: Standalone Webapp JEE (JSR-88 based deployment)	The node represents the computing capabilities in the SCA domain.
Assign a deployment composite to a node: StoreClient --> node1 Store --> node2	Run the composite application by a node		Node can connect to the domain manager to get the composite application. The composite application can also be pushed to nodes (running in daemon). The image of the composite application can be saved into a configuration file so that the node can run offline without connecting to the domain manager. Nodes can run p2p to consistute the SCA domain too.	The deployable image of an SCA composite application to a node is the composite and a list of contributions to support the composite application.
Monitor and control the services running on a node	See what's going on, start/stop the services