Runtime management architecture

Needs

Functionality

EasySOA needs to allow for the deployment and startup of web services on various application servers, in order to:

• Allow to use FraSCAti Studio as an EasySOA Light runtime, and as the proxy provider for EasySOA ;
• Ease the deployment of web services for application servers, mainly simple, configuration-based systems (such as SoapUI, Bonita...).

It should allow for users to easily deploy one or several artifacts to the corresponding server, then have start/stop control over the server in question. An additional requirement is to be able to get information about each deployables' dependencies, or even, if possible/relevant, automatically deploy and launch said dependencies on user request.

While we do not have the ambition to support major all major service stacks, the solution needs to be easily extensible by making the architecture pluggable.

Core technologies to support

• Maven: Maven repositories are a major source of deployable artifacts ; supporting Maven would allow to deploy such artifacts on any compatible application server. A second aspect to handle is the support of POM artifacts as a source of information to retrieve dependencies.
• FraSCAti/FraSCAti Studio: As a part of EasySOA itself, FraSCAti represents a first, major use case for artifact/runtime management, and as such must be a first-class supported stack.
• EasySOA Core Model: By interacting with the EasySOA model, we should be able to retrieve information about deployables (e.g.: thanks to discovery by classpath analysis) and service dependencies, which should additionally allow for a tighter integration with the rest of EasySOA.
• EasySOA Artifact Repository: While it is not specified yet, it is planned to provide a form of technology-agnostic deployable repository within EasySOA (Nuxeo?), in order to make it easier to support non-Maven compatible servers(*)

(*) Some additional servers we could support are SoapUI and BPM engines (Bonita), whose "deployables" are simply configuration files that could easily be stored as documents within the service registry.

Specifications draft

Abstract model

The abstract model revolves around the abstract notion of Deployable, meaning a file or set of files that can be deployed and run on an application server. Other entities are:

• Deployable provider: Software capable of storing and providing deployables ;
• Deployable descriptor provider: File or software providing Deployable descriptors, meaning information regarding a deployable and/or its dependencies, at least allowing to retrieve the matching deployable within the Deployable provider ;
• Deployable server: Where deployables are deployed and launched.

Each entity matches one or several interfaces that one needs to implement in order to make it supported by EasySOA. The interoperability of these different entities is highly technology-dependent, something that we need to take in consideration while designing the interfaces/APIs. Example: Maven artifacts are a kind of Deployable which can be reused for a lot of Java-powered servers, but will be unsupported by others.

Core technologies to support

Here are listed how some of the technologies we could support match the different concepts:

	Maven techs	FraSCAti techs	EasySOA techs	SoapUI techs
Deployable	Maven artifact	FraSCAti Studio template		SoapUI configuration
Deployable Descriptor Provider	POM files		EasySOA Core Model
Deployable Provider		(FraSCAti Studio tpl. repository?)	EasySOA Repository
Deployable Server		FraSCAti [Studio]	(Node Light server?)	SoapUI mocks server

Interfaces

Here is a minimal detailed specification for the abstract model:

DeployableDescriptor Provides information about a deployable

Object getId() // Any ID or hash defining the deployable in a unique way
DeployableDescriptor[] getDependencies()
boolean isAllDependenciesKnown() // (*)

DeployableDescriptorProvider Source of information regarding deployables.

DeployableDescriptor[] getAllDescriptors

Deployable extends DeployableDescriptor Describes a deployable (can be a file or a directory).

URI getLocation()

DeployableProvider Allows to retrieve deployables

Deployable getDeployable(DeployableDescriptor descriptor) // (**)

DeployableServer The entry point for controlling servers. All functionality is contained within embedded services that can be or not supported according to the server type.

DeploymentService getDeploymentService() ServerControlService getServerControlService()

DeploymentService Allows to send or remove deployables

boolean deploy(Deployable d, boolean refreshServer) // (**) (***) boolean remove(Deployable d, boolean refreshServer) // (**) (***)

ServerControlService Allows to start/stop the server

boolean start()
boolean stop()

• (*) Returns true if we are sure no dependency is missing. Might be false if the Descriptor comes from some incomplete information from the EasySOA model.
• (**) At this point, the implementing class should test the given parameter to make sure the deployable/deployable descriptor is indeed supported.
• (***) The "refreshServer" option allows to to force a server refresh to make sure the deployable is indeed made (un)available. While with most servers, this means restarting the server, FraSCAti allows to deploy artifacts more dynamically, making this option useful.