Full model design choices (30.05)
<<< Back to [[Final soa model design]]
This page serves as a legend for the full model schema, explaining the choices behind some parts of the model.
Set of documents that describe the design of a set of additions/changes to the SOA. Serves as a space of storage for RequirementsDocuments (both business design and application architecture), and as a collaborative space to work on design-related topics.
Store design information related to one or more system(s)/service(s)/etc. Each document is produced as part of a Requirements set.
A specific class is defined for such documents so that:
- Each one of them can be independently linked to the anything that relate to it. For instance, a requirements document might affect several Services, or a whole Deployable, or several requirements can be attached, project after project, on the same Service.
- These documents can be (at least in part) parsed to store relevant information that might help set up design validation.
- RequirementsDocuments can be either business-oriented or technical, thus can be relevant to different user roles. The model stores this through "TargetRoles", allowing to display the document differently (or even hide it) according to the user.
EXAMPLE: an SCA document should be imported as a technical document, that will:
- Set the Architect & Developer roles to it ;
- Create Services and make the document be attached to each one of them ;
- Parse Service dependencies to allow for the validation of the services dependencies.
NOTE: If a RequirementsDocument is attached to a Service, it will also be visible to all ServiceImplementations/Endpoints of this Service.
Systems are usually a set of Services that are relevant to certain TargetRoles (but more exactly, Systems can store anything such as Services, Deployables or even other Systems). Thanks to this generic definition, any user can build a system that make sense to him (an application, an API, etc.). They could even be generated, like media players' automatic playlists (thus the ManagedSystems).
Systems serve as the basis for the creation of various document hierarchies, as needed to explore the repository.
The word Service stands for a definition of a web service, independently from its implementation or the endpoint where it will be deployed.
The difference between Services and Clients is that clients cannot provide any web service. They are used to store, for example, "connectors" for developers, i.e. sources to ease the use of a web service ; they are also ideal to store Workflows that use web services, or even UIs over web services.
A distinction between Services and Clients is necessary to clarify the fact that no Service or Client can depend on a Client. Aside from that, they are managed in a similar way (both have implementations, both can be deployed, etc.).
We need to know which organization is responsible for a providing specific Service. It might be implemented as user groups, allowing to display the related Service differently if a user is part of the Provider group or not (= potential consumer).
NOTE: Unlike with the CodeCamp version of the model, there is here only one entity for both providers and consumers. It make sense as a same organization can be provider for some services, while it is consumer of others. Provider/Consumers are relations rather than entities.
One Deliverable matches one artifact, that can potentially be deployed by EasySOA (if the technology is supported), and can contain or not ServiceImplementations.
Deliverables that do not implement an AbstractService (= Service or Client) don't really 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.
NRegarding Clients: The name ServiceImplementation is a bit misleading as Clients can be implemented = can have a ServiceImplementation.
Each ServiceImplementation should be attached to one or more Users, who will be responsible for it. These users do not necessarily have to be part of the Organization that provide the service, as another Organization might want, for instance, create a mock of a Service for internal needs.
It is a good practice to make sure each implementation has someone responsible for it, as:
- Anyone who wants to work with it will know who to talk to
- The person in charge will be notified if something goes wrong (validation failure)
DeployedDeliverable = 1 Deliverable deployed on 1 Environment. Each DeployedDeliverable can expose zero (if it is a Client), or one or more Services, each one being made available on one Endpoint.
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).
NOTE: To make things clear, there are two things that need to be explained:
-
The core of the model (i.e. not the green classes) aims at storing what is expected for the SOA. The main consequence of this is that 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.
-
It is irrelevant here to store dependencies between Services (= service definitions). While these relations are conceptually interesting, in practice there are only two ways to make a service depend clearly on another:
- Either by hard-coding this dependency in the Deliverable
- Or by making it part of deployment parameters
In either way, it results in having Endpoints depending on other Endpoints. This might sound like a limitation, but this approach has several advantages:
- It is simple
- Several implementations of a Service might have different dependencies
- It does not refrain from implementing any EasySOA feature. For example, if we want to develop a new implementation of an existing service, we can still ask provide forking:
- First, the user has to choose a specific DeployedDeliverable to fork (e.g. "Deployable that implements Service A from production"), making it enough information for EasySOA to retrieve which Endpoints will be published and their dependencies.
- Once the service is forked, one or more Endpoints are created, that inherits the dependencies from production. The user can then change these dependencies to make them fit a development environment, for instance by replacing each required service with a mock. EasySOA can assist this step by suggesting, for each dependency, Endpoints that match the same Services.
When a Service is made available with a certain Service-Level Agreement, it is made from a Provider to a Consumer, on a specific Endpoint. That's what we decided to follow in the model, by attaching a Consumer to the Endpoint through an SLA.
Organizations could be implemented as user groups, allowing members of each organization to gain access to the documentation of all Endpoints they consume.
NOTE: Unlike with the CodeCamp version of the model, there is here only one entity for both providers and consumers. It make sense as a same organization can be provider for some services, while it is consumer of others. Provider/Consumers are relations rather than entities.
The Validators allow to check the quality of Services. In other words, they compare what is expected to what is actually published on the SOA. For instance, their role is to tell if a specific Endpoint is actually online, if it matches its requirements, or if it remains consistent through time.
Validators can either be set directly on an Endpoint or upstream, on ServiceImplementations or Services. The goal is simply to make it easier to attach a validator for all Endpoints of a Service(Implementation), present or future.
NOTE: There is no "AvailabilityValidator" as an Endpoint should be available in order to even validate it. The Endpoint.SLM data stores whether the Endpoint is online (+ the date of this information), but also the uptime level and possibly other things stored by either Validators or monitoring tools.
Thanks to Endpoints monitoring, we are available to store RecordedDatasets (= set of web service exchanges), which can be then reused for validation - either as-is, or after Templatization. TestSuites, as they only test (web-)Services), can only be run on DeployedDeliverables.
While RecordedDatasets are stored at Endpoint level, we can make EasySOA ease their reuse for the testing of other implementations/deployments of the same Service.