Full model design choices
<<< Back to [[Final soa model design]]
This page serves as a legend for the model schemas, explaining the choices behind most parts of the model.
- Changes from the 30.05 version
- Global directions
- Core model
- Design
- Implementation
- Deployment
- Transversal
- Validation extensions
- Business extensions
- Client is renamed to Software, and its relations have been reworked to fix various flaws (mainly the "Client can have a ServiceImplemention" issue).
- Changed the Endpoints dependency relation to a relation between an EndpointsConsumer and an Endpoint. An EndpointConsumer can either be a Deliverable (hard-coded dependency) or a DeployedDeliverable (configured dependency). The reason for this is that it's almost impossible to tell if an Endpoint actually depends on another. For instance, if a Deployable exposes 2 Endpoints and consumes 1, we cannot be certain about how the consumed Endpoint was used: was it for the first exposed web service? the second? both/none? With the new mapping, we store data at a wider granularity, but at least we're certain of it's accuracy. In any case, this shouldn't have much consequences in the EasySOA UI, and will allow support for the worflow use case.
- Removed the User "responsibility" relation, for lack of precise needs
- Extended Validators capabilities, by splitting them into Runtime-, Source- and WebValidators, that can be attached to most SOANode types.
- Refactored the RequirementsDocuments-related part ; notably, the Requirements type is now merged with System.
Minor changes
- RequirementsTarget is renamed to SOANode
- AbstractService is renamed to AbstractFunctionality
- The core of the SOA model stores what must exist and what is planned to exist.
- Example 1: As soon as we start working on an service implementation, it can be created within the model. There might not be any code yet on it, but it is planned to exist.
- Example 2: If an endpoint is stored within the model, it doesn't mean we're sure it's online, nor that we're sure that it actually exposes the service we expect. What we're storing is what the endpoint must be.
- The core of the SOA model is centered on service implementations and endpoints. Service definitions are mainly here for the classification of these implementations/endpoints, i.e. to be able to know when several artifacts implement the same service.
- The distinction between what must exist and what is planned is a matter of life cycle of the core model contents.
- The "validation" extensions to the model are meant to validate the web services of the SOA at several steps of its life, by checking the sources, the runtime context & the endpoints themselves. It checks what actually exists against what must exists, i.e.:
- The data of the core model
- Any additional requirements that, while they do not fit the model, can be parsed and understood by EasySOA for the purposes of validation. This includes certain documents produced at design time, such as BPMN processes.
The word Service stands for a definition of a web service, independently from its implementation or the endpoint where it will be deployed.
The word Software stands for a software component (or brick application) 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.
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.
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 is added by further extensions to the model.
We need to know which organization is responsible for a providing specific Service or System. Organizations might be implemented as user groups, allowing to display the related feature 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 either implement or require web services 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.
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 it is a Sofware), 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 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 DeployedDeliverable deployment parameters
This is represented in the model by the fact that both classes extend EndpointConsumer. 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 anyway
- 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.
- Regarding the ability to store dependencies specified during design time (and to use these data for validation), see ArchitectureRequirementsDocument + ArchitectureRequirementsValidator.
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.). These 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. They can also be attached documentation that will then be attached to all children.
Example: "Requirements system" = 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.
All types of SOANodes (Service, Software, Deliverable, ServiceImplementation, DeployedDeliverable, Endpoint, System) have in common:
- An ID
- A name
- The ability to have RequirementsDocuments attached
- The ability to have any additional documentation 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 EasySOA created 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.
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.
There are 3 types of validators:
- WebValidator: validates an Endpoint thanks to HTTP requests
- SourcesValidator: validates a Deliverable by parsing its sources
- RuntimeValidator: validates a DeployedDeliverable by analyzing it's state during runtime
NOTE: WebValidators 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. Similar aggregation can be done with the other types of Validators.
Remark: 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 captured 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.
RequirementsDocuments have additional functionality compared to simple Documents: these documents can be (at least in part) parsed to store relevant information that might help set up validation features.
EXAMPLE: during the import of an SCA composite as a RequirementsDocument, EasySOA will:
- Set the Architect & Developer roles to it ;
- Create Endpoints and make sure the document is attached to each one of them ;
- Parse Endpoints dependencies and store them within the RequirementsDocument, to allow for the validation of these dependencies.
NOTE: If a RequirementsDocument is attached to a Service, it will also be visible to all ServiceImplementations/Endpoints of this Service. Idem for Systems/Deliverables/DeployedDeliverables.
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.