Work towards a final version of the SOA metamodel

[mkalam-alami]

Related issues: #85 (relations, see comments), #82 (lifecycle, see comments)

Schemas

• Early (06.2011) metamodel draft: https://github.com/easysoa/EasySOA/wiki/img/model/EasySOAModelClassesV2.png
• Model built from the unified API: https://github.com/easysoa/EasySOA/wiki/img/model/UnifiedAPIModel-Light.png
• The same model, more complete: https://github.com/easysoa/EasySOA/wiki/img/model/UnifiedAPIModel.png
• Some use cases viewed through the same model: https://github.com/easysoa/EasySOA/raw/6f89b0ead119637ed873299ed788a08a6ab8f5cf/communication/slideshows/ScenariiSchemas.ppt

  Main issues to work on

Most of these issues boil down to the question of the scope of the model: do we keep it as a simple documentation/collaboration tool + a view of the SOA to be used by other EasySOA components? Or do we embed Light/Integration-related information and features?

Features

• Deployables: For now environments aren't much more than folders with references between them - forking and deploying now doesn't make a lot of sense since it only acts on the model. Environments should be able to know which servers they are holding, and in the case of EasySOA-supported platforms, be able to deploy/remove services and start/stop them. This also implies the management of deployable services: what should be known/stored in Nuxeo? What other tools do we need?
  • New model's solution: Only link to external deployables, may them be Maven packages (store URL, and maybe package info), Light packages (stored in the Light solution? or also in a Maven repo?), etc.
• Service lifecycle/Multiple hierarchies: The API design lead to distinguish 3 approaches on services - 'service design/contract' (business), 'service implementation' and 'deployed service' (technical). This could potentially lead to 3 distinct (but tightly linked) hierarchies of services. Are they all really needed given the use cases we want to support? What is the cost of implementing this?
  • New model's solution: Use a same "Service" object for all three views, but customize the UI according to the user role. However, this will need to find some solutions to avoid data duplication.
• Service vs Operation: A same web service can provide several operations - storing them could be useful for using services (eg scaffolder). Do we go to a such fine level?
  • New model's solution: Operations are part of the documentation (a structured, generated UserDoc would allow for instance to build Light clients automatically)
• Other features that may or may not be in the scope of the model:
  • Versioning
  • New model: Yes, everything has versioning, with a specific logic when it comes to publication (centered on services)
  • Proxies/Proxy Features
  • New model: Store proxy definitions, that can be used then by the proxy manager through the API
  • Testing
  • New model: Store all validation definitions, including tests. Exchanges to be used to generate tests will probably not be stored in the model though.
  • Design/Project management
  • New model: "Features" and such are not part of the core model. Can be contributed on top of it according to the EasiFab needs (e.g. a solution for features: /featureroot/feature/linksToServices, or are EasySOA environment enough?)
  • SLA
  • New model: Stored as documentation, set up by defining 'proxy features'.

    Non-features

• Decoupling: Depending on the scope of the model, the modular/extensible capabilities of Nuxeo could allow us to split it into several layers (eg: documentation + collaborative, discovery, validation, Integration features...).
• Terminology: Define more precisely the various entities considered in the model/API.
• Supported techonologies: Support for REST services?

[mkalam-alami]

Technical challenges

• Maintain a service ref. relation after new publication: When an environment (= Section) is "forked", the produced Workspace contains links to "referenced services" from the forked environment. If, later, this environment is updated (= published again), how can we make sure the links won't be broken?