FraSCAti Studio integration in EasySOA / Nuxeo

[mdutoo]

Integration principles :

• as much as possible, metadata (ex. FStudio app id) stored only on Nuxeo's side (since made for that), save if required for standalone FStudio (ex. FStudio's "friends"). This requires :
  • that FStudio asks Nuxeo about what to display (EasySOA model remote API), so that it takes into account the user's environment : ex. which services in the choice box (and display "could be available if you ask for a proxy" ones in grey). NB. As for Talend, services could be chosen in EasySOA / Nuxeo's web interface until API is stable enough for a dedicated FStudio browsing UI to be written.
  • that FStudio tells EasySOA / Nuxeo about changes (new app, newly consumes a service...) in a timely manner (on demand / with "isDirty" ? scheduled ? or on click ??) : EasySOA devtime & runtime app discovery API
• the last kind of interactions is due to EasySOA's service "use" actions : automatic proxy instantiation, and shortcuts to FStudio wizards

  Perimeter :

  Minimal FraSCAti Studio functionalities

• Java & Javascript implementations
• local deployment
• redoing in FraSCAti Studio the Glue sample should work : https://github.com/easysoa/EasySOA/blob/master/samples/easysoa-samples-events/src/test/resources/eventPafSample.composite

  On-demand proxies and wizards from service "use" portal :

• OW requirements on FStudio API for on-demand proxies (see draft below, and #59 #33) and other EasySOA service "use" actions (see API Contract's service use portail #99)
• OW principles of mapping : each "proxy" app should also below to a single "Light proxy platform" System and NOT be an "app" System (but possibly a "easysoa proxy" System, for "easysoa by easysoa").
• TODO INRIA implement it and provide test / example clients, typically as a remote service that does :
  • ServiceManager.createApplication() (on a given composite template and all his parameters)
  • Compiler.compile()
  • Deploye.deploy()
• TODO OW use it, if possible from FraSCAti in Nuxeo client.

  EasySOA model remote API

• TODO INRIA & OW principles of EasySOA Core registry integration in FStudio : as an optional remote service registry.
  • TODO INRIA Michel Question : how do you (already or planned) share & reuse services & endpoints in standalone FStudio, ex. by allowing to copy endpoints and interfaces and paste them as references in other composites ?
  • TODO INRIA Michel Question : does FStudio have a service index & search component or feature on its own besides EasySOA Registry (Philippe talked about publishing an index of services on Twitter...) ? If yes, they'd have to be synchronized or federated.
• alternatives :
  • FStudio displays EasySOA Core Search UI parametered by the appropriate filtering (ex. only endpoints with the WSDL of a known service). Cons : requires UI integration i.e. SSO (using node...) & callback :
  • In FStudio, clicking on "Find service" opens the FStudio Service selection UI in named page or iframe,
  • that redirects to EasySOA Query UI with parameters, where the user searches / filters / browses and selects a service,
  • which redirects to FStudio Service selection UI with id of selected service in param,
  • where the chosen service is now selected and will be applied when user clicks on "OK" to close the page or iframe)
  • FStudio queries REST services (from Content Automation) and displays results using its own interface. Requires designing FraSCAti interfaces (JAXRS ?) for Automation services (though this could be a wider, interesting goal). Cons : additional work & search won't be as powerful as using the full blown EasySOA Core UI.
  • would require INRIA to query SOA model through Nuxeo Content Automation API (or others), and display results
• TODO INRIA LATER check that user can't input / upload WSDLs / services that he has no access to according to EasySOA (or even remove manual input when integrated with EasySOA ?)

  EasySOA devtime & runtime app discovery API

• OW principles of mapping of FStudio app & services to EasySOA model *: all apps in a single "Light platform" System (and / or "User X Light platform" for each user ?),
  • each app as "app" and "deployable" Systems,
  • LATER if possible each subcomposite as "construction" subSystem
• TODO OW design & provide it. Alternatives :
  • use automatic SCA discovery at FraSCAti startup. TODO OW Question : is it enough or are there other parameters to provide (ex. from FStudio db) ? (If not see next)
  • trigger explicity SCA discovery (ex. when click on "save")
• TODO INRIA use it to say what changes
  • TODO INRIA Question : is the runtime udpate mechanism in any way similar ??

Related to TODO OW the EasySOA / Nuxeo business side of this API.

Other integration

• authentication :
  • SSO ?
  • federation using OAuth, TODO Nuxeo, INRIA ?
• integration of social aspects : TODO Nuxeo help INRIA on it (FStudio's "friends" with Nuxeo's social module, OAuth, possibly Gadget UI...)
• TODO INRIA (optional) if possible, embed in Nuxeo, using f in n work done

  API Drafts

OW requirements on API Studio, draft :

• create/remove/updateProxies( Proxy...{ template, params, shouldBeStarted, shouldGoToStudio, targetStudioPage })
• TODO OW should we have a listTemplates() return Template...{ params, infos } ? NO rather in App discovery API !

[mkalam-alami]

CR after a discussion regarding the service query UI

2 main interesting ways to make the UI:

• A: Either make a generic EasySOA Search UI to be used by any application that needs it (like Google Custom search, Solr)
• B: Or directly use the EasySOA REST API & build a specific UI

(Also C: allow to use EasySOA Registry as the true FStudio backend for service storage, but only possible if the INRIA is willing to do it)

Pros for solution A

• Allows to do develop only once all that is needed to make a user choose a Service(/Deployable/other) from EasySOA
  • Service import in FraSCAti Studio
  • Service import in Talend ESB
  • Service import in other WS engines
  • Specific integration with EasySOA client companies
  • => Turns the Search UI into a whole, sellable product on top of the registry
• On the contrary, solution B requires specific UI development/maintenance for each software that integrates it
• Allows to showcase the EasySOA capabilities in matter of service search and reusability
  • (for instance, a specific FraSCAti Studio UI might underuse the EasySOA capabilities)
• Regular EasySOA users might be more comfortable searching services directly from EasySOA
  • (a badly made client UI might not allow him to search services the way he's used to)

Pros for solution B

• Integration with applications is less complex & tailor made
  • Needed work for B:
  • Integration to translate the REST data model into the wanted model
  • Development of a specific UI
  • Needed work for A:
  • Integration of the EasySOA Query UI
  • Integration with the authentication system
  • Integration to translate the Query UI callback into the wanted model
  • Possibly some additional uses of the REST API if the callback contents doesn't fit the needs (e.g. to access documents attached to a service)
• More consistent UI / user experience
• Lowered amount of work for the EasySOA consortium (or rather: much less work for Open Wide, more for INRIA/Talend)
  • Not incompatible with making A in the future