IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'approche SOA passe-t-elle nécessairement par des approches distribuées
Et des communications distantes inter-applicatives ?

Le , par ego

20PARTAGES

0  0 
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.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de zortar
Futur Membre du Club https://www.developpez.com
Le 13/11/2009 à 13:00
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.
1  0 
Avatar de aymen83
Membre actif https://www.developpez.com
Le 11/11/2009 à 11:58
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]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.
0  0 
Avatar de ego
Rédacteur https://www.developpez.com
Le 11/11/2009 à 12:44
Tout d'abord merci pour ton retour
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 ?
0  0 
Avatar de aymen83
Membre actif https://www.developpez.com
Le 11/11/2009 à 14:23
Citation Envoyé par ego Voir le message
Tout d'abord merci pour ton retour
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
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??

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.


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"
0  0 
Avatar de ego
Rédacteur https://www.developpez.com
Le 11/11/2009 à 14:47
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.

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.

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)
0  0 
Avatar de Alesque
Membre du Club https://www.developpez.com
Le 11/11/2009 à 20:16
Citation Envoyé par ego Voir le message
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
0  0 
Avatar de ego
Rédacteur https://www.developpez.com
Le 11/11/2009 à 20:31
super retour, je te remercie !

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 ?
0  0 
Avatar de Alesque
Membre du Club https://www.developpez.com
Le 12/11/2009 à 0:00
Citation Envoyé par ego Voir le message
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 :

0  0 
Avatar de TheNOHDirector
Membre du Club https://www.developpez.com
Le 13/11/2009 à 11:45
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]
0  0 
Avatar de ego
Rédacteur https://www.developpez.com
Le 13/11/2009 à 20:48
@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
0  0