Discussion :

[ego]

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.

[aymen83]

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.

[ego]

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 ?

[aymen83]

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")

[ego]

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)

[Alesque]

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

[acerodon]

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

[ego]

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

[B.AF]

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.

[09765493]

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"