FraSCAti Studio integration in EasySOA / Nuxeo #100

mdutoo opened this Issue Jan 20, 2012 · 1 comment


None yet

2 participants

mdutoo commented Jan 20, 2012

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

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 !

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
@cmunilla cmunilla added a commit that referenced this issue Sep 18, 2012
@cmunilla @JGuillemotte cmunilla + JGuillemotte INRIA - Point fin Christophe
Bonjour Marc, Jérémie, Philippe, ... les autres,

J'ai fait avancer les modules nuxeo du trunk FraSCAti et ai réalisé un refactoring d'EasySOA afin de prendre en compte le code en question. Pour le moment, il n'est pas possible pour moi de déployer les modules nuxeo de FraSCAti et donc de simplement commiter mon travail sur git. En prévention (départ proche), je joints à ce mail un patch permettant d'appliquer le refactoring sur la version courante d'EasySOA (version du lundi 27 aout à 21h00).

J'ai ajouter les dépendances binding.nuxeo et implementation.nuxeo (réalisée par Philippe) au lanceur nuxeo-frascati.

Architecture de FraSCAti dans Nuxeo ( :  Marc a parfaitement retranscrit ce dont nous avons eu l'occasion de nous entretenir par téléphone, et je ne pense pas pouvoir y ajouter quoi que ce soit qui ne serait une redite.

Architecture s'appuyant sur un FraSCAti dans nuxeo minimal et immuable, combiné à un FraSCAti remote "enrichi": elle demandera d'appliquer des règles identiques à celles décrites dans le wiki (les erreurs apparaitront plus rapidement, ce qui peut être un avantage), mais nécessitera l'ajout des composants permettant la communication entre les deux FraSCAti, ou EasySOA et FraSCAti. Le choix de cette architecture reste à évaluer au regard des conflits apparaissant avec un FraSCAti embarqué et de la difficulté à les résoudre (le problème d'instanciation du WebExplorer a t-il finalement trouvé une issue ?)

Bonne fin de journée
Christophe Munilla

----- Mail original -----
> De: "Marc Dutoo" <>
> À: "Christophe Munilla" <>
> Cc:, "Philippe Merle" <>, "Jeremie Guillemotte"
> <>
> Envoyé: Jeudi 26 Juillet 2012 10:37:05
> Objet: INRIA - Point fin Christophe
> Hello Christophe
> Comme promis, mes notes !
> Je te laisse avancer comme indiqué.
> Cordialement,
> Marc
> ---+++ Point timeline :
> Christophe a travaillé sur EasySOA depuis mars 2011, avec fin du
> contrat
> le 31/08/2012.
> Son sujet a d'abord été OSGi (sur existant fractal-osgi), puis s'est
> focalisé sur frascati dans nuxeo, où a été réutilisé non seulement
> approche mais aussi architecture et implémentation. Si et quand nuxeo
> sera pleinement OSGi, il sera simple d'y passer.
> Il a également réalisé récemment un binding NuxeoDM. Il permet en
> plus
> de réutiliser un service nuxeo dans frascati, ou injecter un service
> frascati dans le registry runtime nuxeo). Il réutilise l'isolation de
> FraSCAti dans Nuxeo de manière plus générique (nuxeo-runtime-bridge
> est
> devenu frascati-runtime-bridge). Il vise s'il a le temps aussi
> développer une implementation.nuxeo (i.e. sca-iser un service/bundle
> nuxeo).
> ---+++ FraSCAti dans Nuxeo - pérenniser :
> pour pallier à l'instabilité chronique de l'intégration, avec Jérémie
> :
> * solidifier règles, procédures et découpage actuels. Voir, enrichir
> et
> donner feedback à
> * passer à du plus générique (binding.nuxeo) pour pallier au départ
> de
> Christophe : découpage entre les responsabilités OW et INRIA plus
> clair
> et mieux maintenu
> * envisager un frascati distant (avec les mêmes principes de
> découpage,
> ne le simplifie pas lui mais seulement le packaging), avec en local à
> nuxeo un minimum ne changeant jamais
> ---+++ Suites FraSCAti pour EasySOA :
> archi :
> * pb de compilation sur Mac (le build se croit sous Windows) : faire
> une
> issue avec le fichier buildr hacké et les pbs (l. 13 nuxeoctl, l. 277
> node.js)
> * #67 pb web-explorer : remarche pour Christophe (inaccessibilité
> jettison par cxf, à déplacer avec elles dans serviceRegistry/lib)
> mais
> pas dans Nuxeo
> * #100 intégration fstudio : avis Christophe sur l'architecture ?
> (distant voir ci-dessus ? local ?? ou déployant les on-demand proxies
> en
> local et les apps en distant ?) NB. la partie métier et api est vue
> avec
> mdirix, pour Christophe  )
> pas prioritaire :
> * #49 CUSTOM_JAVA_OPTS (à mettre dans le Jira ?)
> * #107 hacked implementation.velocity : TODO Christophe des idées
> pour
> une architecture évitant le hack et séparant bien le générique
> FraSCAti
> et le spécifique EasySOA l'étendant ?
> a priori plutôt Philippe :
> * #92 (build) how to integrate (nightly snapshots of) fractal in
> frascati ??
> * propertizing (#59) : probably rather use a model of the
> configuration
> state of the component / proxy that will be updatable, just like
> ExchangeEventHandler's Subscriptions, than FraSCAti properties
> (though
> they may be used for init ?? otherwise how to init on-demand proxies
> ?)
> * #23 mock any ws (still addressing i.e. jaxws Features or cxf
> interceptors ??)

Signed-off-by: Jeremie Guillemotte <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment