V1 Functional specifications

<<< Back to [[EasySOA 1.0 specs]]

Summary

1. Service registry
2. Document hierarchies
3. Rights
4. Versioning
5. Discovery
6. Web discovery
7. Code discovery
8. Runtime discovery
9. Manual documentation import

Service registry

Document hierarchies

Views for actor types

• Business: Functional, process-oriented hierarchy of services (for now arbitrary Systems). Usually produced at design-time, as part of the business design phase.
• Architecture : Technical yet abstract hierarchy, splitting information between coherent applications and software components (Software). Usually produced at design-time, as part of the architecture design phase.
• Implementation : Technical hierarchy, in order to display implementations information (Deployables/ServiceImplementations). Implementations are sorted according to the platform they are part of. Similar to the Nuxeo Platform Explorer.
• Endpoints : By environment, view runtime information (Endpoints).

Viewpoints for organizations

An organization has / can have a self-centered viewpoint of a given soa it is involved in.

Rights

An organization might want to only have parts of its SOA exposed (for other people to use it), without wanting to share the rest (in read or at least write). In order to do that, any provider must be able to reuse/share/synchronize some of his documents with other Organizations.

Versioning

Versioning : lorsqu'un document est mis à jour, besoin de 'snapshoter' tous les Systèmes qui le contiennent.

Discovery

Web discovery

• Made possible by the discovery by browsing tool.

Impact on the model

• Discover Endpoints information
  • Service name
  • WSDL contents
  • Web paged where the service has been found
  • (+ anything that might be useful for further use by WebValidators)
• Build links between:
  • Endpoints & Applications (= Endpoints hierarchy), by reusing the source page title for instance

Code discovery

• Made possible by parsing an SCM repository
  • Parse JAX-RS annotations
  • Parse Maven POM

Impact on the model

• Discover Deployables & ServiceImplementation information
  • Deployable Name
  • Deployable Maven ID / Mavel repository location
  • ServiceImpl Class name (+ file location in SCM/Sonar?)
  • ServiceImpl Relative URL path
• Build links between:
  • Deployables & Services/Softwares, additionally store the service's Java interface there

Runtime discovery

• Made possible by classpath analysis
  • Match classpath contents with Deployables (through their Maven IDs)

Impact on the model

• Discover links between an entironment's platform (= System), its DeployedDeliverables and the Deliverables.

Manual documentation import

• Ability to attach documents anywhere
• Ability to specify the document type, making the document being available to different user types
  • Business doc (usually to business-oriented Systems, also Software/Services)
  • Tech user doc (usually to ServiceImpls)
  • Architecture doc (usally to architecture-oriented Systems)
  • Infrastructure tech doc (SLA) (usually to Endpoints or endpoint-related Systems)
  • End user doc (usually to business-oriented Systems)

Impact on the model

• Attach documents to arbitrary SOANodes
• A document attached to a System is also attached to all his children
• Idem for Service > ServiceImpl > Endpoint
• Idem for Deliverable > ServiceImpl
• Idem for DeployedDeliverable > Endpoint