easysoa/EasySOA — Issue #72: 2-environment registry with publishing and validation engine
Author: mdutoo
Created: 2011-11-30 15:27:21+00:00
State: open
Labels: Open Wide

Those 2 are :

2 envs
* a published "master" env. Concretely, it comes from publishing the nowadays staging-like, demo one.
* referred to by a dev env, which uses it as the reference env against which its own discovered services are validated

* environment publishing, document versioning
* service discoveries in published "master" environment becoming the contract's constraints, or in other words "checkboxes" / holes that are waiting to be filled in dev envs referring to it by similar discoveries again & validation engine
* queries (to find services...) filtered along the contract's constraints (ex. same service, same wsdl...) ; Q nuxeo semantic engine (sparql ?, jena) ?
* possible actions on validation pbs / invalid service discoveries / notification database
* environment versioning, upgrading to latest version
* export to props (for frascati SmartTravel or cxf Server), manual or possibly maven
* whole Light development cycle. Notably sandboxed services : service which has different urls according to env, tunnelnode (tunnelnode-like routing could be simulated using node.js or nuxeo)
* also Integration development cycle whitout development and staging.

first steps :
* allow to publish the first (nowadays) staging-like environemnt to a "master" published environment
* allow document tree to support several "environments" (workspaces)
* reference to a published version of the registry as "master" from another development environment. Q Are original services linked to their published version and how ? => OK "section" schema prop in original document thanks to Nuxeo proxy documents
* on a change in a workspace environment, trigger the validation engine to validate all its (discovered) elements against those of its reference published environment. LATER do it in a finer manner (per document / service, or event per delta)
* make it pluggable using a Validator.validate(element) return { OK/Conflict/Unkown/..., message } interface. LATER possibly use POJOs to model everything a given Validator implementation needs to know to perform validation, and any kind of information it deduces, so this POJOs could be used to perform further actions on notif ? and / or use notification database rather than validations ?
* implement Validator it for : presence of application, service (api ? references ?) ; service definition (for wsdl) ; LATER tests, rework model so discovery info / validation info are UNDER services
* list all of the dev env's validator results in a WebEngine or node.js UI : { element, validatorName, result}
* reuse it for the master env, and enrich it to become a dashboard of what's validated, including discoveries, but also some simple service stats (counter), call publication from it
* in dev UI, on unknown validations (or its source element ??), add actions : Approve, Ignore (blacklist maybe by a boolean prop on doc), Reset (removes what caused it) ; LATER add group or even global actions.
* in dev UI, add action allowing to (from master to dev env) : copy as external service(s), mock impl using selected service(s) (and references) ; LATER clone impl (Light only)
* assemble all these actions in a single interface, create simple Light (which sandboxes external services) and Integration implementations (which does not), share as much code as possible