SOA ou autre, a-t-on tant besoin de "distribution" ?

Contexte : monde de la gestion....

Une petite réflexion sur tout ces moyens d'appel à distance : RMI, IIOP, WebServices, EJB, Corba,....

As-t-on réellement besoin de tout ça ? Pourquoi parle t-on toujours de distribution/appel distant quand on parle de SOA ?

Plus j'y pense et plus je me dis que tout cela ne sert peut-être pas tant que ça.

Bon, ok il faut expliquer un peu...

L'idée est : "quand a t-on vraiment besoin de distribution ?"

1- Ben quand une IHM doit appeler un serveur "métier". Dans des cas simple ou on fait du Web et que tout est sur le même serveur, ce n'est même pas nécessaire. Mais, ok, pour des question de sécurité et donc d'architecture, partons du principe qu'une IHM doit toujours faire appel à des services "distants" pour dialoguer avec le "métier".

Dans ce cas, quelle est la nature des "services" appelés par l'IHM ?
Si on a des règles d'architecture correctes, c'est à dire que l'on a pas de métier côté IHM et que l'on se doit de minimiser les aller/retour entre IHM et métier (pour les perfs !), eh bien ces "services" sont forcément des services dédiés à l'IHM. Ce que je veux dire c'est que ces services ne sont pas fondamentalement "métier" ou tout au moins pas réutilisables dans un autre contexte que cette IHM. Alors ok, comme on fait de la bonne conception, ces "services" font s'appuyer, "derrière", sur des composants de plus bas niveau qui eux seront indépendant de l'IHM et seront plus "métier".
Ces "services IHM" sont-ils alors des services au sens "SOA" ? Est-ce que ce ne seraient pas plutôt les composants de "derrière" qui sont les services au sens SOA ? Mais si oui, alors ces composants n'ont pas besoin de distribution car ils sont sur le serveur.

2- Bon, ok, toujours avec cette idée que les services "SOA" sont les composants de "derrière". Ces composants peuvent avoir besoin d'appeler des services d'autres applications. Ah bon ? Lesquels réellement ? Dans un SI, les applications ont des responsabilités claires et il est rare que le métier "transactionnel" soit beaucoup réparti entre plusieurs applications. Au "pire", on a des référentiels communs ou des "mécanismes généraux" qui sont partagés. Pour ces référentiels ou mécanismes, on peut très bien se passer de distribution en déployant les "librairies" qui les constituent sur les différents serveur métier. On a alors des composants locaux qui doivent simplement être déployés correctement sur plusieurs serveurs.
En dehors de ces "applications particulières", la communication avec d'autres applications est souvent asynchrone. Soit via des évènements temps réel soit via des fichiers et là il n'y a pas besoin de distribution.


Bref, je me demande si on ne devrait pas limiter l'importance des technos de distribution dans nos approches d'architecte et plus réfléchir à la modularité de nos applications et à leur mode de déploiement dans les serveurs d'application en fonction des liens qu'elles peuvent avoir.
Et au final, plus se concentrer sur des problématiques comme celles qui tournent autour d'OSGI (modularité, versioning) et des "nouveaux serveurs d'applications" (où la distribution n'est pas le coeur du discours)

Des avis ?

nb : j'ai mentionner que ces réflexions étaient faites dans le contexte d'un SI "Gestion" mais je me demande si ce n'est pas vrai dans l'absolu.

salut ego,

le centre d'intêret d'une architecture SOA est avant tout l'intégration, c'est à dire fournir un moyen de communication et de synchronization entre plusieurs system .
A mon avis, avant de se dire qu'on va faire du soa,on doit se poser 2 questions essentiels

1. [1]pourquoi a t-on besoin de faire du SOA?
   [2]quelles sont les repércusions d'une telle architecture sur notre SI?

dans plusieurs cas, il peut s'avirer qu'on a pas besoin. et Simple system qui joue le role d'un Proxy(centraliser nos services dans un seul "module") entre plusieurs environnement peut très bien etre plus approprié. C'est plus connue comme lightWeight SOA.
Parce que, SOA, est vraiment très difficile à mettre en ouevre. Vu le nombre énorme de technologies dont on besoin de maitriser pour pouvoir mettre cette architecture.

Tout d'abord merci pour ton retour :D

Citation:

---

Parce que, SOA, est vraiment très difficile à mettre en ouevre. Vu le nombre énorme de technologies dont on besoin de maitriser pour pouvoir mettre cette architecture.

---

Mais SOA n'a rien à voir avec la technique et ce n'est pas difficile, c'est ce que l'on fait tous les jours !!!
J'ai volontairement parlé de SOA car justement on nous rabats les oreilles avec ça mais rien de nouveau en vérité.

Tu parles d'intégration ? Mais même cette notion est sujette à polémique. Un SI n'a pas à "intégrer" des applications, il faut avant tout REFLECHIR à son SI et à son architecture = donner des responsabilités aux applications. Ensuite on pense au services rendus et requis et on regarde comment mettre en oeuvre tout ça. C'est du SOA si on veut mettre un nom à la mode mais ce n'est rien d'autre que de la bonne conception à papa.

D'autres retours ?

Citation:

---

Envoyé par ego

Tout d'abord merci pour ton retour :D
Mais SOA n'a rien à voir avec la technique et ce n'est pas difficile, c'est ce que l'on fait tous les jours !!!

---

vous faites du SOA tous les jours??si je comprend bien vous confondez SOA avec les web services, ou que je me trompe:aie:
mais vous etes donc familiers aux aspects tels que le monotoring et le logging et tous ce qui des registry. Tous ça ne demande pas -t -il de la techniques??

Citation:

---

J'ai volontairement parlé de SOA car justement on nous rabats les oreilles avec ça mais rien de nouveau en vérité.

---

quant à inscruster le terme SOA n'importe ou ça c'est vrai.

Citation:

---

Tu parles d'intégration ? Mais même cette notion est sujette à polémique. Un SI n'a pas à "intégrer" des applications, il faut avant tout REFLECHIR à son SI et à son architecture = donner des responsabilités aux applications. Ensuite on pense au services rendus et requis et on regarde comment mettre en oeuvre tout ça. C'est du SOA si on veut mettre un nom à la mode mais ce n'est rien d'autre que de la bonne conception à papa.

---

Je parle d'intégration, mais l'intégration ne demande pas-t-elle de mettre une architecture. Définir comment nos applications vont communiquer? utiliseront ils le meme langage("de communication")? seront ils connecter de la meme façon ("Protocole")

Citation:

---

vous faites du SOA tous les jours??

---

Mais oui ! Depuis des années comme pratiquement tout le monde en informatique, en fait. Ce n'est pas parce que quelqu'un à inventé un mot que rien n'existait avant. Dans un SI, on a des applications qui communiquent entre elles, non ? Ben ça y est, on fait du SOA ou de .........l'informatique tout court.

Citation:

---

si je comprend bien vous confondez SOA avec les web services, ou que je me trompe

---

Je ne vois pas pourquoi tu dis cela. Non, je ne confond pas.

Citation:

---

mais vous etes donc familiers aux aspects tels que le monotoring et le logging et tous ce qui des registry. Tous ça ne demande pas -t -il de la techniques??

---

Il y a toujours de la technique en informatique mais ce n'est JAMAIS le fond du problème, c'est ce que je veux dire.

Un des trucs du moment qui traite réellement du SOA mais que ne le mentionne absolument pas, c'est OSGI. C'est vers cela que je voudrais voir si la discussion peut aller. Et aussi voir si finalement, les futurs serveurs d'applications ne devraient/devront pas être plutôt centrée sur la modularité et le versioning plutôt que centrés sur la tuyauterie tels qu'ils l'ont beaucoup été jusqu'à maintenant. Peut être parce que le modèle de composants EJB (plus avant la version 3 encore) n'était finalement pas un bon modèle pour construire nos applications (il l'est peut être pour la simple "distribution" de certains services)

Citation:

---

Envoyé par ego

Mais oui ! Depuis des années comme pratiquement tout le monde en informatique, en fait. Ce n'est pas parce que quelqu'un à inventé un mot que rien n'existait avant. Dans un SI, on a des applications qui communiquent entre elles, non ? Ben ça y est, on fait du SOA ou de .........l'informatique tout court.


Je ne vois pas pourquoi tu dis cela. Non, je ne confond pas.


Il y a toujours de la technique en informatique mais ce n'est JAMAIS le fond du problème, c'est ce que je veux dire.

Un des trucs du moment qui traite réellement du SOA mais que ne le mentionne absolument pas, c'est OSGI. C'est vers cela que je voudrais voir si la discussion peut aller. Et aussi voir si finalement, les futurs serveurs d'applications ne devraient/devront pas être plutôt centrée sur la modularité et le versioning plutôt que centrés sur la tuyauterie tels qu'ils l'ont beaucoup été jusqu'à maintenant. Peut être parce que le modèle de composants EJB (plus avant la version 3 encore) n'était finalement pas un bon modèle pour construire nos applications (il l'est peut être pour la simple "distribution" de certains services)

---

Jonas a fait un pas supplémentaire dans l'intégration J2EE & OSGi. Tu peux appeler facilement un service d'un bundle OSGi depuis un EJB et ton EJB peux être intégré à un bundle OSGi si j'ai bien suivi. Par contre ce n'est pas portable évidement.

Tant que Java ne se décidera pas sur son framework modulaire, on reste un peu scotcher. Regarde Glassfish, ils ont créé le kernel hk2 pour cacher l'implémentation OSGi (Felix Inside). Mais comme ils n'utilisent pas une norme, l'intégrer à plus haut niveau c'est rendre le modèle de développement propriétaire et plus du tout portable comme Jonas.

Le jour ou on aura un standard pour modulariser et versionner, l'intégration avec les serveurs J2EE pourra se faire. Tant que le standard n'existe pas l'intégration ne peut se faire sans perdre la compatibilité.

L'autre solution à surveiller c'est que OSGI intègre des services Enterprise comme les transactions distribuées. Et il me semble que c'est une des specs de OSGI 4.2.

Maintenant, je reste très pragmatique. Qu'est ce que cela nous apporte en terme de productivité ? Pour l'instant je ne vois pas trop.

Malgré tout j'ai préconisé en 2007 à une société d'utiliser OSGi, mais c'était dans un autre contexte. Un plateau de développement FR C++, donc se former à Java avec ou sans OSGi ça ne coutait pas bcp plus cher. 4 bureaux de dev répartis dans le monde (US, UK, FR, ML) tous java excepté le plateau FR mais d'un niveau très hétérogène. Et je voyais dans OSGi un bon moyen de standardiser le dev (OSGi force les bonnes pratiques en découplant interface et implémentation), d'augmenter la réutilisabilité du code (encore faut il que celui qui design pense à designer pour qu'il soit réutilisable) via la création d'un repository de bundles et limiter les jar hell vu qu'il ne fallait pas trop compter sur la concertation des équipes pour sélectionner les versions des third party à utiliser.

Pour une petite équipe rigoureuse et d'un bon niveau, interface POJO et java.util.ServiceLoader tu t'en sors aussi bien.

Mais l'arme fatale à toutes ces technos c'est de bien designer son code métier pour le rendre indépendant de l'infrastructure. Une fois le code métier encapsulé on peut déjà le tester très facilement. Et on peut à loisir implémenter le code infra pour faire tourner la persistence avec hibernate ou autre, le publish subscribe avec jms ou une simple dequeue, et déployer le tout sous spring ou encore jboss ou encore déléguer la résolution des services à OSGi ;)

super retour, je te remercie !

Citation:

---

Maintenant, je reste très pragmatique. Qu'est ce que cela nous apporte en terme de productivité ?

---

Là, je te rejoins car j'ai l'impression que la gestion des versions, un peu partout (MANIFEST, scripts Ant/Ivy ou Maven, gestion du/des repositories,...) est pas simple à mettre en place.
Si tu as des "patterns" je suis intéressé.
Sinon, d'accord avec toi sur la conception qui doit A LA BASE être correcte et indépendante des technos. Pour moi, LA règle c'est vraiment de penser POJO et de n'utiliser les technos que pour les "protocoles d'accès". Les composants "techniques" ne devant faire que de la délégation vers les POJO

Concernant ton expérience, quels ont (sont) été les points forts et les points faibles autour d'OSGI ?

Citation:

---

Envoyé par ego

Là, je te rejoins car j'ai l'impression que la gestion des versions, un peu partout (MANIFEST, scripts Ant/Ivy ou Maven, gestion du/des repositories,...) est pas simple à mettre en place.

---

Au niveau repository que ce soit pour Maven 2 ou les bundles OSGi :

• Nexus Sonatype Pro
• OSGi Bundle Repository (OBR) Support

Je suis d'accord avec toi ego, SOA ne veut pas nécessairement dire distribué! Je travaille sur une application composée de services métier, techniquement les services sont dans des EJB-JAR et l'ensemble est packagé dans un EAR, cet ensemble est découpée en strate. Les services de haut niveau ou à valeur ajoutée sont composés de service de plus bas niveau. Je pense que cette application est typiquement une très bonne représentation d'une architecture orientée service.

Ici l'application n'est pas distribuée, car elle tourne sur une même JVM. Celà dit il y a bien du RMI pour que les EJB-JAR communiquent entre eux. Mais il s'agit plus là de câblage interne que le container fait pour nous.

Par rapport à ce que tu disais sur les responsabilités, notre application a plusieures responsabilités réparties entre les services qu'elle expose. Chaque service exposé se compose de services ayant un périmètre plus fin de responsabilité.

Il y a longtemps pour des raisons techniques mais aussi pour des raisons business, nous avons fait un découpage de notre application depuis une application encore plus grosse. Du coup nous avons aujourd'hui un découpage dans le SI, avec des appels distants.

N'oublions pas non plus que le SOA, ce n'est pas seulement des services au sens composant, mais aussi des clients, des batchs, des systèmes legacy qui doivent s'interconnecter. Par exemple notre application fait appel a des systèmes legacy et à un mainframe, des batchs sont lancés régulièrement, et des clients internes et externes se connectent à notre application.

Donc oui je pense que de faire une architecture distribuée - techniquement du code qui n'est pas sur la même JVM - a un sens. Ce sens doit bien entendu être soutenu par le business et par les besoins techniques.

En ce qui concerne la modularité et le versionning nous avons travaillé dessus, mais ce n'est clairement pas pas optimal. Techniquement OSGI et CXF pourrait bien ouvrir la voie sur ces deux sujets. En parlant de ça un livre vient de sortir sur le versionning des contrats de WebServices, évidement il faut avoir choisi une approche Contract First pour en profiter.

[ame="http://www.amazon.fr/Web-Service-Contract-Design-Versioning/dp/013613517X/ref=sr_1_1?ie=UTF8&s=english-books&qid=1258108838&sr=8-1"]Web Service Contract Design and Versioning for SOA[/ame]

Ce thread est très intéressant et pose de bonnes questions.

Avant de répondre sur certains points (je suis architecte dans l'équipe JOnAS),
est-ce qu'on peut partager un vocabulaire commun sur la SOA et l'architecture du système d'information ?

La SOA est un paradigme architectural.

Les gens utilisent le terme SOA pour désigner* différentes choses :
- SOBA (Service Oriented Business Architecture)
- SOA integration (par exemple utiliser un ESB pour intégrer des applications)
- SOA modernization (par exemple donner un accès Web Service à une application existante, ou mettre en place un serveur déchange qui permet de gérer des flux hétérogènes entre applications)

Seul le SOBA relève «*véritablement*» de la SOA.
Dans ce cas, il s'agit d'écrire de nouvelles applications avec une architecture SOA. A partir de l'analyse des processus de l'entreprise, sont déterminés successivement :
- les services fonctionnels correspondants aux activités
- les services applicatifs
- les services techniques

Pour développer l'architecture adaptée dans une organisation, un cadre architectural comme le TOGAF identifie bien* les niveaux suivants :
Business architecture (Process)
Information Systems ( data and application architecture)
Technology Architecture


OSGi (la SOA dans* une VM) apporte la modularité à Java
au même titre que la SOA apporte la modularité à l'Enterprise Architecture.

Celà étant dit, je suis d'accord avec ego, une chose importante c'est bien la capacité à réaliser les "services de derrières" sous forme d'applications (services ) composites.
Même si les problèmes de distributions font dépenser beaucoup d'énergie, il ne faut pas perdre de vue que ce n'est pas une finalité et que l'important c'est bien ces fameux services qui doivent bien tourner quelque part, et le serveur d'application de nouvelle génération est une place de choix.
Et c'est bien là tout l'enjeu de nos travaux, la modularité, le versioning, et la composition. Nous le faisons avec iPOJO mais notre obsession est bien de le faire de manière la plus* standard possible (dans une approche best of breed), le meilleur des deux mondes Java EE et OSGi (et pas l'inverse).
Nous regardons aussi avec attention la distribution OSGi qui va dans le sens d'une simplification de toute cette couche protocolaire "legacy".
OSGi permet de gérer correctement dynamisme (mise à jour à chaud, substitution, lazy loading) et l'aggrégation de briques open source. Dans JOnAS sont intégrés "facilement" CXF (pile Web service et routage), la médiation Camel, la gestion des règles avec Drools, et tout autre composant OSGi.

Je suis d'accord que tout ça ne concerne pas que le SI Gestion mais tout système (industriel, embarqué, etc).


Pour revenir à la distribution, la distribution vient de l'architecture. Quand on répond à certaines questions d'EA on arrive à de la distribution.
Si on prend les questions du Framework Zachmann
What ? How ? When ? Who ? bien souvent elles conduisent à une architecture distribuée mais effectivement SOA ne veut pas forcément dire distribution (OSGi en est le premier exemple). Ensuite comment est faite cette distribution et à quel niveau, c'est une autre question.
Il y a eu dans le passé une vision homogène de la distribution, et je pense que c'est cette vision là de la distribution qui n'est pas la bonne.

Il y a donc des besoins de distribution, cela va encore s'accentuer avec le cloud. JavaEE ou D-OSGi permettent de masquer cette distribution à l'application.
SCA offre aussi un modèle de programmation qui permet de masquer cette distribution.
Comment va évoluer SCA par rapport à Java EE et D-OSGi, pour l'instant on ne sait pas trop.

Pour revenir aux objectifs de la SOA, même si aujourd'hui, la tendance est plus à la flexibilité du système d'information plutôt qu'à la réutilisation des services, dans les deux cas le repository de bundle OSGi apporte une vraie valeur.

@zortar
Merci pour ce retour précieux, sans vouloir offancer les autres, d'une personne qui travail au coeur d'un serveur d'appli comme Jonas.

Je me demande par contre pourquoi on a DOSGI d'un côté et JEE de l'autre. Une convergeance tout au moins côté Java me semblerait totalement nécessaire. Et c'est d'ailleurs ce que Jonas tente de faire pour le moment en permettant de publier un EJB comme service OSGI et aussi avec l'injection de services OSGI dans un EJB.

Erik_qui_croit_dur_à_OSGI

Effectivement il s'agit avant tout d'une architecture Business qu'elle soit distribuée ou pas - la question d'architectures non-distribuées se pose cependant de moins en moins...

J'ai fait du Corba en 1998 et c'était un grand pas en avant pour faire communiquer des applications hétérogènes. C'était de la programmation 'ouverte' où l'on partait de 0 et on construisait l'application. Cependant ce n'était pas une architecture mais un bus.

10 ans plus tard, il ne s'agit plus de faire du code comme dans le temps mais plutôt de la tuyauterie entre des composants architecturaux prédéfinis - ceci est valable quand on utilise des solutions d'entreprise - selon des standards ou référentiels qui font partie de la IT Governance et Compliance. Oracle, SAP, Cognos, SAS implémentent tous (avec plus ou moins de facilités offertes) cette couche SOA.

J'ai assisté le 19 Novembre 09 au workshop Oracle Fusion Middleware pour la version 11gR1 et la couche SOA prend en input les SGBDR ou ERP hétérogènes et propose en output des services homogènes.

De plus, Oracle ont sorti au dessus de la couche Fusion Middleware (SOA) la couche AIA (Application Integration Architecture) qui propose des composants afin de structurer encore plus les services pour faciliter les liens avec le frontend.

SOA et AIA sont l'homogénéisation de l'EAI (Enterprise Application Integration) qui était/est classique mais propriétaire - l'implémentation même du bus était/est propriétaire.

Avant de se focaliser sur les aspects techniques, il faut considérer ce que l'on vise comme résultat à l'échelle nécessaire (celle de l'entreprise autant que possible) mais aussi dans le temps (scalabilité, etc.)

Mais justement, je pense que l'utilisation de Java à grande échelle sur l'ensemble des applis d'un SI n'existe pas encore et on ne se rend pas compte que si quelques services distribués ça fonctionne bien à "petite" échelle, à grande échelle, je reste très dubitatif.
Pour la petite histoire, les EAI n'ont jamais vraiment percés et je ne vois pas pourquoi les ESB changeraient quelque chose d'autant plus que beaucoup d'ESB sont centrés au Java et les WebServices uniquement (plus transferts de fichiers). Et c'est un comble d'être à ce point "mono-techno/langage" quand on veut faire de l'intégration. Quid des applications existantes écrites dans d'autres langages ?

Bref, je pense que l'omniprésence de la notion de distribution quand on parle de "services" ne me parait pas adéquate par rapport à la problématique même de "services".
Le "vrai" problème pas encore totalement résolu c'est la notion de versioning de services et toute la gestion qui va autour. ça c'est un vrai vrai problème qui ne commance à être vraiment traité que depuis que l'on a OSGI

zortar léve un concept intéressant :

il faut décorréler le service rendu du moyen de rendre le service.

Globalement, la partie conception doit définir les services à rendre, la façon de les rendre étant une problématique purement technique.

En outre, je contredis la plateforme Java EE sur les aspects techniques. C'est trop confus, trop de choses, trop de plomberie.

La plateforme .Net, avec en plus WCF, les Web Services (très très simples à mettre en oeuvre), le messaging et bien plus simple à mettre en oeuvre.

Citation:

---

Envoyé par zortar

La SOA est un paradigme architectural.

---

C'est exact, mais malheureusement il n'est pas traité en tant que tel.

Soit on voit le service comme un paradigme (c'est mon cas), soit on voit le service comme un synonyme de composant (qui par définition, rend un service). Avec la seconde vision (la plus répondu, y compris dans ce fil de discussion), il est difficile de ne pas se dire qu'il s'agit d'un concept marketing pour redonner un coup de jeune à une autre paradigme, celui des composants. Ce qui est vrai, c'est que les problématiques liées à la communication d'un ensemble de composants distribués et hétérogènes ont fait d'énormes progrès. Malgrè tout, cela reste fondamentalement le paradigme composant, qui a toujours insisté sur l'aspect communication (sans avoir les solutions techniques à l'époque) pour pouvoir assembler (certains dirons intégrer) des briques logicielles en un tout cohérent. Par exemple, OSGi est un framework composant par excellence, pourvu de mécanismes d'assemblage de composants (les bundles), réalisé à chaud, de surcroit. Il n'y a pas l'ombre du paradigme SOA la dedans.

Pour changer de paradigme, il faut plus que des améliorations techniques (si bonnes soient-elles), il faut changer l'approche avec laquelle le développement est traditionnellement considéré. Justement, le paradigme des services prévoit la découverte dynamiques des composants, qui deviennent ainsi des "services" dans le jargon : ils sont là, quelque-part, disponibles, et attendent le "client". Tout comme j'organise ma journée autour d'un ensemble de services (bus, cantine, la poste, coiffeur), il doit être possible (cas idéal) de construire un SI par orchestration de services réalisés par d'autres. Cela requière de savoir ce que l'on veut (poster une lettre, se faire une nouvelle coupe de cheveux), reléguant sa réalisation concrète au second plan. C'est un peu la remarque de B.AF il me semble. C'est ainsi que le notion d'annuaire de services a naturellement fait son apparition. Sans annuaire, vous ne faites pas du SOA, vous faites un SI dont les composants applicatifs sont répartis. Point barre.

Oui je te confirme.

Ca ne sert à rien d'avoir la plateforme technique si l'on ne maitrise pas les services attendus. Ou alors ça fini dans des frameworks tellement technique qu'il n'apporte plus grand chose à cause d'une courbe d'apprentissage monstrueuse.

poucez vous m'aider à Commentez la citation suivante " SOA n’a pas nécessairement besoin de web services. Tous les web services ne sont pas basés sur SOA"