Deployment API

[Jeremy Boynes <jb...@apache.org>]

We currently have a deployment SPI that supports the creation of new  
components from the configuration object model. This is powerful  
interface as it provides the user with complete control over the  
creation of components in the runtime. That power comes with a price  
though in that the user needs access to the configuration model  
classes (including portions supplied by extensions) and that makes it  
very hard to support remote (cross-VM) deployment.

I've started work on a deployment API that can be used by clients and/ 
or hosts to control what is running in a Tuscany based SCA Domain.  
There is some strawman code in o.a.t.host.deployment

The basic idea behind this is that there is an SCA Domain that  
represents all the services and components that a user has running.  
This Domain is a logical representation that spans multiple,  
cooperating, federated physical runtimes - that representation is an  
Assembly of components that provide and consume services. A user can  
manipulate the Assembly to determine which services are provided at  
any time (for example, by creating or deleting components) and which  
services are consumed (by changing the wiring). The Assembly is an  
instance of the Assembly Model used to describe the components in a  
Domain. It is a live instance so manipulation of it directly affects  
the services provided by the Domain. Portions of the Assembly can be  
statically represented by SCDL XML documents (e.g. a <composite>  
document can be used to describe the implementation of a component in  
terms of others).

All manipulations are performed through an AssemblyService exposed by  
the Domain. This can be called directly (for example, it could be  
bound to a web service and invoked from a client), or indirectly (for  
example, copying a file to a directory could trigger changes such as  
creating a component). A manipulation is represented by a change-set  
resource whose content describes the operations to be performed (such  
as create component). The format for that is determined by the  
content-type of the resource and can be anything understood by the  
implementation; examples would be XML, serialized Java objects,  
Groovy script, and so on.

Now the Assembly is a logical representation of the Domain's services  
and as such does not itself contain any physical implementation  
artifacts. What it does contain though is references to certain  
definitions that are used in the model. For example, it contains  
references to WSDL portTypes or Java interfaces that define service  
contracts, or it references Java classes, PHP scripts or <composite>s  
that define component implementations. These definitions are made  
available to the Domain through a ContributionService that allows  
physical artifacts (resources) to be contributed into the Domain. For  
example, a user might contribute a JAR file containing Java bytecode,  
a XML document containing WSDL components, or an archive type like an  
EAR that contains other resources. The ContributionService  
implementation inspects the resource based on  its content-type to  
determine what definitions it provides and then makes them available  
for use from the Assembly.

--
Jeremy

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org