Clean architecture for velocity-templatized services #107
Comments
|
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
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" <[email protected]> > À: "Christophe Munilla" <[email protected]> > Cc: [email protected], "Philippe Merle" <[email protected]>, "Jeremie Guillemotte" > <[email protected]> > 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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 :
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.
The text was updated successfully, but these errors were encountered: