easysoa/EasySOA — Issue #95: ServiceDiscoveryMapper across apps and envs
Author: mdutoo
Created: 2012-01-17 17:03:19+00:00
State: open
Labels: Open Wide

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 SDServiceRootMapper : (default and most useful one) a SDMapper where only a root part of the 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 MyCustomSDServiceRootMapper to handle some weird service url mapping ex. "flatify"

2 SDRegexpMapper : any part of the URL can be abstracted / propertized across envs. It works like SDServiceRootMapper, 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.