Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Scaling up FraSCAti proxies #59

Open
mdutoo opened this Issue · 0 comments

1 participant

@mdutoo
Owner

Outbound calls from proxies using FraSCAti

For now, each proxy (scaffolder i.e. WSDL2HTML and REST2SOAP, monitoring) is instanciated once and calls proxied service using Apache HTTP Client. How to do this call in a more FraSCAti-like way ? Alternatives :

keep proxies as singletons, but

  • add in FraSCAti the ability to call a web service the "message" way, i.e. using XML content rather than objects, kind of an outgoing binding.http with an HTTPMessage (or Servlet) interface
  • this is interesting in discovery phase when services are not yet known, but less interesting later

instantiate a new proxy "on demand" for each proxied service

For instance when the user wants to call existing services that have to be sandboxed, or to monitor all services in his architecture, or to instantiate one dedicated WS proxy for each WS service discovered using the previous method

This requires :

  • in addition to an instantiation manager ("ProxyFactory"),
  • for non-SOAP HTTP ("RESTful") services,
    • a non-SOAP HTTP client (outoing) binding and interface, actually like said "HTTPMessage".
    • An alternative is to go full SOAP (or JAXRS-based REST) and handle non JAXRS-based REST by designing a JAXRS interface in front of it, possibly in a helped, automatic and dynamic way thanks to ex. machine learning on monitored exchanges, bridges from Google Discovery, SPoRE spec and RX Schema.
  • for proxies used in HTTP proxy mode (monitoring, fuse),
    • check that this mode works in FraSCAti. Notably, will FraSCAti out-of-the-box URL-based service routing redirect to the right FraSCAti Services according to the actual target HTTP URL (which differs from HOST header in HTTP proxy) ?
    • An alternative is to only support HTTP tunnel mode i.e. classic HTTP which FraSCAti supports out of the box - not a bad alternative since both require changing client-side properties. Such routing could be done either outside using connect or inside if possible using Camel or a custom proxy using an outgoing binding.http.
    • Note that these proxies only provide non-functional, hidden to business features.
  • (if this still implies that binding.http is used) solve #37 Problem to close a Jetty HTTP binding component else binding.http won't be able to be stopped.

FraSCAti design and deployment :

  • FraSCAti instantiation & deployment manager : actually works already in Web Explorer and even standalone, will be furthered in FraSCAti ProxyFactory & Studio
  • FraSCAti app development : automatic creation of "proxy" composites referencing business interfaces. SCA (abstract components, composition, includes) can be used but is not enough. So generated from (velocity or further MDA) templates, programmatically against the SCA metamodel, directly against the runtime (REST) model to allow for dynamic reconfiguration ?
  • FraSCAti app configuration : propertizing, similar to above but lighter. For this FraSCAti properties have limits :
    • they CAN be changed in a single place (the root composite, though that requires to wire all properties in there), but can't be set outside the jar (properties file) => allow external property file, lookup all ${...} properties up to the root composite
    • they CAN be of complex types (using JAXB properties), but can't be built using code. This requires to use dedicated business services providing them : PropertyProviderService instead of FraSCAti properties, however it removes some (?) of their interesting features.
    • UPDATE 20120726 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 ?)
  • FraSCAti templates composition manager : FraSCAti ProxyFactory, Web Explorer & Studio

Support of any service definition

(any WSDL see #23, but also with authentication or not...) as client or proxy / mockup server - alternatives :

  • TODO OW TEST IT configuring CXF below FraSCAti (ie Spring cxf-config.xml file, helps ex. by FraSCAti pre-filling with http-conduit according to services) and configuring CXF through FraSCAti, see #27
  • LATER MAYBE multi runtime. Opens a door for Talend, node.js, bare CXF
@christophe-m christophe-m referenced this issue from a commit
@christophe-m christophe-m 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 (https://github.com/easysoa/EasySOA/wiki/Frascati-in-nuxeo-architecture) :  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" <marc.dutoo@openwide.fr>
> À: "Christophe Munilla" <christophe.munilla@inria.fr>
> Cc: easysoa-consortium@googlegroups.com, "Philippe Merle" <philippe.merle@inria.fr>, "Jeremie Guillemotte"
> <jeremie.guillemotte@openwide.fr>
> 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 à
> https://github.com/easysoa/EasySOA/wiki/Frascati-in-nuxeo-architecture
> * 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 <jeremie.guillemotte@openwide.fr>
f4e182c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.