Cleanup Relation Management in EasySOA-registry

[tiry]

The current code and prototype want to use relationships.

Nuxeo Platform proposes several solutions for managing this kind of link :

• RDF relationships
• Core relationships (i.e. Document based)
• Proxies

From my current understanding, use Core Relations would be the best option since it allows for easy complexes queries that contains both attributes on the documents, security and links.

But we need to define more precisely what needs to be done in EasySOA.

[mdutoo]

TODO mkalam expand on this, notably for relations involving : service references, reference environment elements.

[mkalam-alami]

Here are the main types of relations we have started to discuss. Note: in order to better understand what we need, it's best to take a look at the scenarios defined on this slideshow

• Service reference: We have to store the dependency from a service to 0/n other services. Since it's a reference, we shouldn't link to a specific implementation, but rather a service contract.
  • Current implementation: the ServiceReference doctype holds a metadata with the ID of the referenced service. Right now, the ServiceReferences are stored at Application level and not Service level (it was done for convenience when implementing the SCA parsing).
• Link between environments: EasySOA should allow to "fork" environments, allowing to work on a develepment environment which is directly derived from the staging one for instance. We have to store the link between these environments to allow, among others, for validating the work in progress against the reference environment.
  • Current implementation: Services + Workspaces hold a metadata with the ID of the referenced Service/Workspace.
• Link between a service and its technical definition: could be either a WSDL or something else, according to the service technology.
  • Current implementation: Right now only WSDLs are supported, and stored in the file:content metadata.
• Link between the service contracts, their implementations, and the deployed services: As seen in the slideshow, there are somehow 3 levels of "abstraction" for the services. We need to represent all three point of views of the SOA, and create the corresponding relations between documents.
  • Current implementation: A Service contains all the information about its specifications, its implementation and its deployment, making the use of relations unnecessary, but leading to a lack of decoupling.