Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clean architecture for velocity-templatized services #107

Open
mdutoo opened this issue Mar 16, 2012 · 1 comment
Open

Clean architecture for velocity-templatized services #107

mdutoo opened this issue Mar 16, 2012 · 1 comment
Labels
INRIA Open Wide

Comments

@mdutoo
Copy link
Member

mdutoo commented Mar 16, 2012

We've hacked FraSCAti's implementation.velocity twice in order to provide exchange templates (built automatically from correlated suggestions) as SOAP services, as described in #73 "Message API : store and reuse for replay & simulation" (see details there) :

=> Questions to INRIA :

  • could we have done that without hacking, especially how to add another implementation kind to implementation.velocity ? Is that also possible in others ex. implementation.java ??
  • could some be contributed to FraSCAti (ex. the first one), how ? If we wanted to commit it ourselves in FraSCAti how would / could we ?
  • can this kind of feature (simulating SOAP services, "meta" service, "proxy" implementation) be done better (notably using FraSCAti capabilities), how ? (this is also interesting for providing Nuxeo Content Automation as SOAP, see discussion Nuxeo and SOAP).

Then provide it to INRIA as basis of a (possibly new implementation) contribution & for patches, improvements and feedback on how to develop such things ("meta" service, "proxy" implementation... all also ex. for providing Nuxeo Content Automation as SOAP) for FraSCAti.
@mdutoo mdutoo mentioned this issue Mar 16, 2012
Open
@philippemerle
Copy link
Member

I read your patches and I don't understand why you need to patch <implementation.velocity>.

I think you could simply write your own Servlet SCA components to do the same.

Have a look at:

But perhaps I miss some important thing in your patches.

cmunilla pushed a commit that referenced this issue Sep 18, 2012
INRIA - Point fin Christophe
f4e182c 
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
INRIA Open Wide
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mdutoo @philippemerle