Core model specifications (April, 11)
<<< Back to [[Final soa model design]]
This model has been initiated during the April, 11 "codecamp" attended by Open Wide, Nuxeo & EasiFab. Note that:
- The vocabulary has yet to be refined (e.g. some words weren't translated from French to English)
- The model is still incomplete and subject to changes, as it has to be tested against more use cases (including those from partners absent from the meeting)
Resources
- Picture of the schema produced during the April, 12 codecamp
The model is designed around three main categories of information:
- Design
- Implementation
- Deployment
Each facet of the SOA matches different concepts that are, however, linked together.
- Requirements (FR=Exigences): Set of documents that describe the design of a set of additions/changes to the SOA. Serves as a space of storage for design documents (both business design and application architecture), and as a collaborative space to work on design-related topics.
- Service: A web service, that can be or not provided by the company hosting the EasySOA instance.
- System (synonym: ServiceAPI?): An coherent set of Services from a business point of view
-
Provider: ????
- The organization that provides a Service?
- A proxy for a service, used to determine service dependencies + who provides what?
- SLR: Service-Level Requirements, or what is required from a Provider when implementing/deploying a Service.
-
Deliverable (FR=Livrable): Artifact needed for the implementation of services. It might directly implement one or more services, or be required by these.
- Deployable artifact location
- Source code location
- Datasets / Tests
- Technical requirements
- Developer documentation
- Deployment recipes
- Environment: Instance of the information system (or a part of it), deployed for a specific purpose (= production, staging, development...)
- DeployedDeliverable (FR=Implantation): An instance of a Deliverable, deployed on an application server, within an Environment.
- Endpoint: A Service made available through the web by a DeployedDeliverable, at a specific URL.
- SLA: Service-Level Agreement. An agreement made between the provider and the consumer of an Endpoint regarding its Quality of Service.
- SLM: Service-Level Reporting(?). Gathers relevant data that mainly ensures that an SLA has been succesfully satisfied.
Versioning is managed independently a 3 levels, that match the 3 categories of information mentioned earlier: design, implementation, and deployment.
- All design information is versioned System-wise
- All implementation information is versioned Deliverable-wise
- All deployment information is versioned Environment-wise
-
Business architect: Initiates an application creation by producing the business requirements of an application.
- R/W on Requirements*
-
Technical architect:
- R/W on Requirements*
- All developer rights
-
Developer:
- R on Requirements
- R/W on Deliverable
All rights are granted for documents that are relevant for each user, e.g. two developers might have access to different Requirements/Deliverables.
*A more detailed representation of the rights would require to split Business & Technical requirements into two entities, and set rights accordingly. In the context of EasySOA all requirements are gathered together for the sake of simplicity.
The EasySOA model aims to support several navigation views (~ 1 per role), most of them having yet to be clearly specified.
- Navigation by project: Allows all users to explore any resource related to a project. Thus, it gathers arbitrarily all Environments, Deliverables & Requirements that are worked on (through a dashboard?), and helps collaborating around them.