Full model design choices
<<< 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). 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, as new projects will little by little add new requirements for a Service, we are able to retrieve all of these documents at once when browsing the Service.
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 with the "technical document" preset, that will automatically set the Architect & Developer roles to it.
Systems are usually a set of Services that are relevant to certain TargetRoles (more exactly, Systems can store anything within Services, Clients or 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).
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.
The distinction between Services and Clients is necessary to clarify the fact that no Service or Client can depend on it. 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 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).
Usually when a Service (or a Client) is created, ServiceReferences are also created to know what other Services are required, or even any RequirementsTarget type, as Service references constraints can take various forms. This can be used, for instance, for the generation of a .properties file to store all URLs required by a web service/web app : When a Service is deployed, according to the constraints of each reference, they should eventually translate to one Endpoint or another (limitation: this Environment-dependant link from Endpoint to Endpoint is not stored in the model).
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 (note: if it's relevant, we could actually include Deployable dependencies within the model too, as any AbstractService can require any RequirementsTarget, including Deployables).
DeployedDeliverable = 1 Deliverable deployed on 1 Environment. Each DeployedDeliverable can expose zero (Client), one or more Services, each one being made available on one Endpoint.
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 storing SLA data on the Endpoint node, and by attaching a Consumer to the Endpoint.
Organizations could be implemented as user groups, allowing members of each organization to gain access to the documentation of all Endpoints they consume.
Thanks to Endpoints monitoring, we are available to store RecordedDatasets (= set of web service exchanges), which can be then reused for TestSuites - either as-is, or after Templatization. TestSuites, as they only test (web-)Services), can only be run on DeployedDeliverables.
(XXX: We might want to store the results at Deliverable level?)