Full model design choices
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.
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 ServiceClient) is created, ServiceReferences are also created to know what other Services are required. According to the constraints of each reference, it translates to one Service or another.
(XXX This link might be impractical to resolve constraints to implementation/deployment-specific information)
One Deliverable matches one artifact, that can potentially be deployed by EasySOA (if the technology is supported), and can expose or not a web service, according to if it implements a Service or ServiceClient.
Deliverables that are not directly related to a ServiceConsumer (= Service or ServiceClient) won't be stored in the model. Instead, 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.
DeployedDeliverable = 1 Deliverable deployed on 1 Environment. Each DeployedDeliverable can expose zero (ServiceClient), 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.
Consumers can be viewed as user groups, allowing members of each organization to gain access to Endpoint documentation via EasySOA.
(XXX: A Consumer might be a Provider of something else, and vice versa. Maybe we need only one "Organization" entity.)
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 DeployedDeloverables.
(XXX: But we might want to store the results at Deliverable level?)