Tag Archives: soa

SOAP is the EJB of XML???

Le débat fait rage sur TheServerSide après une série de billets provocateurs par Carlos E. Perez:

SOAP is Comatose But Not Officially Dead!
More Nails For SOAP’s Coffin
Why REST is Better – Explained in Code

Je trouve la comparaison avec les EJB assez judicieuse. SOAP et les spécification WS-* sont bien trop ambitieuses et complexes (comme les EJB), on nous promet que tout sera simple grâce à des outils (comme les EJB) la pluspart des applications n’ont pas besoin de toutes ces fonctions avancées (comme les EJB) et il existe des alternatives (comme pour les EJB).

Effectivement en face les examples d’architecture REST (très bonne description, à lire) extrémement efficace sont nombreux (del.icio.us, flickr, yahoo…)

Un example qui me semble assez percutant de ce que l’on peut faire avec du REST (et un peu de XPath)

A quand la spécification WS-REST ???

Le problème avec SOA

Voici un bon billet parlant de SOA

“It strikes me that making this particular SOA dream a reality is not about specs nor is it about tools, it’s about modelling things in a different way such that all the problems of changing requirements etc do not have substantial interface impact”

Voilà, tout est dit, mettre en place une architecture orienté service ce n’est pas un problème technique mais fonctionnel. Une SOA c’est etre capable de définir des interfaces qui pourront être réutilisées alors que les spécifications des applications les utilisants vont évoluer.

Ca suppose que ces interfaces soient définies par quelqu’un qui connaisse extrémement bien le métier de l’entreprise.
Ca suppose que l’on dépasse la vision projet pour passer à une vision entreprise.
Ca suppose que l’entreprise ait au préalable une organisation bien structuré. Les services d’une SOA sont la modélisation du fonctionnement de l’entreprise, si l’entreprise fonctionne mal sans SOA elle ne fonctionnera pas mieux avec.

D’ailleur google ne s’y trompe pas, quand on chercher architecture orientée services on trouve cette très bonne description par mega

Le problème avec SOA

Voici un bon billet parlant de SOA

“It strikes me that making this particular SOA dream a reality is not about specs nor is it about tools, it’s about modelling things in a different way such that all the problems of changing requirements etc do not have substantial interface impact”

Voilà, tout est dit, mettre en place une architecture orienté service ce n’est pas un problème technique mais fonctionnel. Une SOA c’est etre capable de définir des interfaces qui pourront être réutilisées alors que les spécifications des applications les utilisants vont évoluer.

Ca suppose que ces interfaces soient définies par quelqu’un qui connaisse extrémement bien le métier de l’entreprise.
Ca suppose que l’on dépasse la vision projet pour passer à une vision entreprise.
Ca suppose que l’entreprise ait au préalable une organisation bien structuré. Les services d’une SOA sont la modélisation du fonctionnement de l’entreprise, si l’entreprise fonctionne mal sans SOA elle ne fonctionnera pas mieux avec.

D’ailleur google ne s’y trompe pas, quand on chercher architecture orientée services on trouve cette très bonne description par mega

Domotique .Net et SOA même combat…

Julien Brunet nous offfre un lien vers un rapport de magistère: Étude et réalisation
d’une plate-forme domotique sur .Net

Ca peut paraitre surprenant mais ce rapport contient notament une description très claire, et à mon sens très juste, d’une Architecture orienté service

Aujourd’hui, les logiciels « Change On Demand » sont devenus très populaires, les besoins changent vite et il faut s’adapter le plus rapidement possible. De nombreux producteurs de logiciels, proposent dorénavant cette solution évolutive. Une des approches pour réaliser ce genre de produit est une Architecture Orientée Services. Celle-ci est devenue très répandue avec l’explosion des Services Web.Cette approche consiste à diviser le logiciel répondant à un problème, en un ensemble d’entités proposant des services. Chacune de ces entités peut utiliser les services proposés par d’autres entités. On obtient ainsi un réseau de services interagissant entre eux. Cette architecture s’appuie sur une architecture à composants ( implémentation « réelle » des services [Cervantes2004] ) et suit l’évolution logique des architectures logicielles [Endrei2004] ( figure 1) :

Les approches orientées services se caractérisent par :
• une transparence sur la localisation des services
• une indépendance des protocoles de communication
• une indépendance vis à vis des langages de programmation

L’infrastructure sous-jacente cache aux services ces détails. Il est aussi possible de substituer un service utilisé par un autre plus performant si celui-ci apparaît, ou par un service ayant un temps de réponse plus faible. Une architecture orientée services est basée sur 3 acteurs principaux : l’annuaire de services, le fournisseur de services et le demandeur de services. La figure 2 illustre les interactions entre ces 3 acteurs.
Lorsqu’un service est activé, il s’enregistre auprès de l’annuaire (1 ). Ainsi, lorsqu’un autre service a besoin de lui, il peut le retrouver dans l’annuaire ( 2 ) et se lier à lui ( 3 ), pour ensuite pouvoir l’invoquer.

Pour le reste lisez le rapport en plus vous aurez des schémas très clairs.

SOA et Web Services

Avec 2 buzz word pareils j’espère avoir attiré du monde 😉
Juste pour signaler que TheMiddleWareCompagnie publie un bluePrint concernant SOA. C’est sponsorisé par BEA, et je ne pourrais pas vous en dire plus car c’est quand même un document de 138 pages, il va falloir trouver un peu de temps pour le lire.
Par contre dans les commentaires de la news sur TheServerSide on trouve un lien vers une petite présentation qui définie de manière claire le “Service” dans “Service Oriented Architecture”. Les slides du symposium DNG de l’an dernier (à télécharger en bas de page) sont aussi une riche source d’information sur les architectures SOA.

Un point qui me semble important à retenir:
Une architecture SOA n’implique pas automatiquement l’utilisation de Services Web. C’est une possibilité mais ce n’est pas obligatoire.