ServiceDiscoveryMapper across apps and envs

ServiceDiscoveryMapper

service discovery works like this : SDService.discoverService(env / use context, service info including url)

Its server implementation has to be able to find the right application and map with other environments (ex. dev vs staging), here's how it must be done.

Server implementation has to be handled by a chain of different implementations of ServiceDiscoveryMappers. Each implementation uses conf contained in each app(Impl) in one or more SDMapperConf (sdmapperconf in the model).

1 SDServicesRootMapper : (default and most useful one) a SDMapper where only a root part of all service url is abstracted / propertized across envs. How it works :

if finds an app with a corresponding "service root" kind of sdmapperconf (for that does a select of serviceroots on active env and service.url.startsWith(serviceroot.url)), then (customHandle() then) adds the service there.
else only suggests new app first (ex. in dashboard) : looks for app to copy / "import" in forked env(s) along same query, or fully new app (wizard...)
besides, its customHandle() could be customized ex. in MyCustomSDServicesRootMapper to handle some weird service url mapping ex. "flatify"
NB. the full service URL in the current env can still be saved in a temporary / cached / recomputed / dirtied Nuxeo property to ease things.

2 LATER SDRegexpMapper : any part of the URL can be abstracted / propertized across envs. It works like SDServicesRootMapper, except select is done using matchesRegexp() instead of startsWith(). Nuxeo doesn't provide this for now, so (either add it or) rather develop a SDRegexpServiceRootMapper which does regexp using Java only on the result of the select of the SDServiceRootMapper part.

Service mapping across environments is then achieved : either by adapting the service url just the same way according to its sdmapperconf when crossing in another environment, or by storing also the relative url when first adding the service.

Note that this is actually an application of #75 "templatized properties".

With deployable discovery

When (provided or consumed) services are discovered within deployables during deployable discovery (see #97), deployable discovery configuration can feed the env / use context, such as which deployable provides or consumes it, ex. FraSCAti composite discovery (but also ex. which project & app, as configured in maven deployable discovery plugin).

AppImplConfProducer

Does the opposite : in a file (served in HTTP, or as a maven artifact...) outputs $serviceName=$servicesRootUrl/$serviceUrlRightPart for all services of the selected env (or even for all consumed services i.e. references of the selected AppImpl).

Transiting to another env

The user either creates a new env and copies the AppImpl in it (env fork), then inputs the changed rootServicesUrl ; or chooses an existing env to update, in which case the rootServicesUrl is kept and the appImpl replaced. NB. in both cases checks are done afterwards, typically through validation, especially in the second case.

DONE first impl on current model

Use the current serviceUrl as a temporary cache, use the existing servicesRootUrl, add serviceUrlRightPart property to the model. Develop the SDServicesRootMapper using them, and update the current serviceUrl explicitly only when it changes i.e. when forking / replacing as said. This way the current code and scenarii should still work.
Then develop the SDServicesRootEnvPropProducer as a WebEngine template for URLs like http://nuxeo/envprop/envName[/appimpl].
introduce the SDRM in the dbb and other discoveries if possible
use the produced envprop file in demos : manually first, LATER then write a simple HTTP client and let it be used be a demo, then output a maven bundle...
Allow to update applications manually
- For that, manage a link to a reference application (same as workspace to env, service to service)
- Warning: is the link kept when updating an environment?
- TODO Impact analysis

easysoa / EasySOA