-
Notifications
You must be signed in to change notification settings - Fork 8
Runtime management architecture
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.
- 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.
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.
Here are listed how some of the technologies we could support match the different notions:
| 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 |
TODO