V1 Model specifications
<<< Back to [[EasySOA 1.0 specs]]
The word Service stands for a definition of a web service, independently from its implementation or the endpoint where it will be deployed. The Service represents the design-level information of the web services: its primary purposes are to collaborate during the design phase, hold arbitrary functional documentation, and maintain a relation between all implementations of the same service. The core model is unable to store dependency requirements between services (e.g.: BPMN documents can be imported as part of the documentation, but it's information cannot be parsed and maintained within the model) ; this feature should be added by further extensions to the model.
The main difference between Services and Software is that software components cannot provide any web service. They are used to represent, for example, "connectors" for developers, i.e. sources to ease the use of a web service ; they are also ideal to store Workflows or even UIs that require web services. A Software stands for a software component (or application brick) whose supporting technology may not have been determined, but is known to be homogeneous. For example, a Software in EasySOA may not be implemented using both PHP and Java code. If it is, then the Software should be modeled as a System which contains two software components.
One Deliverable matches one artifact that can potentially be deployed by EasySOA (if the technology is supported), and can contain or not ServiceImplementations. ServiceImplementations mainly help linking a Deliverable to the Service it implements, but can also store specific information like its relative path from the application root URL.
Deliverables that do not either implement or consume web services (such as libraries) usually don't have a use as part of the model, and should not be stored. In order to be able to deploy those too, we'll use the specificities of each supported technology during deployment: e.g. Maven POMs will be parsed when we want to deploy the dependencies, instead of storing these dependencies within the model.
While it is not an encouraged practice, Deliverables can contain hard-coded dependencies to Endpoints.
DeployedDeliverable = 1 Deliverable deployed on 1 Environment. Each DeployedDeliverable can expose zero (if a Software), one or more Services, each one being made available on one Endpoint. If the URLs of the Endpoints consumed by the DeployedDeliverable are provided as part of the deployment configuration, it will be possible to store these dependencies within the model (as DeployedDeliverables are EndpointConsumers).
When Deployables are managed by EasySOA (i.e. handles deployment/start/stop/etc.), DeployedDeliverables allow to track the state of these Deployables (see DeployedDeliverables.State).
An Endpoint can depend on other Endpoints: this relation serves as the storage of service dependencies. Not only the services dependencies are useful information as such, but also it might serve for the generation of URLs configurations (URL lists as a .properties file for instance).
Endpoints that are created do not necessarily exist nor match the expected service. The import of a SCA component, for instance, will generate several Endpoints and create relations between them without asking questions. Comparing what is expected to what is actually exposed is the role of the Validators (not part of this version of the model).
The dependency for a specific Endpoint should be stored in the model in two cases:
- Either when hard-coding this dependency in the Deliverable
- Or when making it part of DeployedDeliverable deployment parameters
A Document stores information related to one or more system(s)/service(s)/etc. A specific class is defined for documents because:
- Each one of them should be independently linked to the anything that relate to it. For instance, a document might affect several Services, or a whole Deployable ; or several documents can be attached, project after project, on the same Service.
- Documents can be either business-oriented or technical, thus can be relevant to different user roles. The target roles should be defined during document creation, allowing to display the document differently (or even hide it) according to the user.
Systems are usually an arbitrary set of Services that are relevant to certain user roles. But more exactly, Systems can store anything such as Services, Deployables or even other Systems, making them similar to the notion of folders. Thanks to this generic definition, any user can build a system that makes sense to him (an application, an API, etc.). System hierarchies could even be generated, like media players' automatic playlists (thus the AutoSystems).
Systems serve as the basis for the creation of various document hierarchies, as needed to explore the repository. They can also be attached documentation that will then be attached to all children.
All types of SOANodes (Service, Software, Deliverable, ServiceImplementation, DeployedDeliverable, Endpoint, System) have in common:
- An ID
- A name
- The ability to have Documents attached
- The ability to collaborate on them
- Except System, they have a lifecycle state: Placeholder, Project, Validated
NOTE: The "placeholder" state stands for any node that has been created by EasySOA by anticipation, but do not exist yet at that time. For example, using a BPMN file to build the SOA structure will create placeholder Endpoints (among others) for the "production" environment.