Tag Archives: soa

Débugguer des web services

Grâce ou à cause de la SOAmania du moment on croise de plus en plus de web services sur les projets. Et quand il s’agit de débugger plusieurs appels successifs de web services c’est pas toujours simple.

Heureusement les petits gars d’Axis ont prévu le coup.
Le jar d’axis contient un programme qui répond au dou nom de tcpMon
pour le lancer cette ligne de commande suffit:
java -cp axis.jar org.apache.axis.utils.tcpmon

tunnel.gif En fait c’est un simple proxy/tunnel http qui se met entre le client et le serveur. Il permet de voir les requêtes qui passe, de les modifier et de les rejouer. Simple et efficace. Pour en savoir plus Using the Axis TCP Monitor TcpMon.

Si vous avez besoin d’un outil un peu moins rustique et que vous etes prêt à dépenser la somme de 99$ Mindreef SOAPscope devrait vous combler. Parmi les fonctionalités en plus par rapport à tcpMon on retiendra:
– Gestion du WSDL
– Enregistrement et partage de scénario de test ou de bug
– Sait sniffer le réseau pour récupérer les messages SOAP (évite d’avoir à se positionner en proxy)
– Fournit des stats sur les temps de réponse

Livre blanc: SOA et urbanisme

Trouvé dans les commentaires du blog Architecture Logicielle. Un excelent livre blanc:

“SOA et urbanisme – Le rôle des Architectures Orientées Services dans l’alignement métier des Systèmes d’Information”

Une idée forte qui revient tout au long de ce livre blanc est la nécessité d’un référentiel centralisé des données et services de l’entreprise. La création et la maintenance de ce référentiel ne peuvent se faire sans des outils adaptés. Etant actuellement impliqué dans un projet SOA avec un embrion de référentiel d’entreprise et sans outil je peut vous dire que c’est bigrement vrai.
Et on en remet une couche avec la Synthèse des Meilleures Pratiques SOA et Web Service par Orchestra network. Encore une bonne lecture avant de se lancer dans un projet “SOA”

SOA: la vision d’IBM

J’ai assisté à un séminaire d’IBM sur le thème: Mettre en oeuvre aujourd’hui une Architecture Orientée Services

J’ai trouvé les interventions très pertinentes et je suis d’accord avec cette vision. Voici une retranscription de mes notes. En italique mes réflexions perso.

Pour introduire le séminaire la directrice Websphere nous a parlé d’évolutions imposées par la compétition et de l’exigence du marché: la flexibilité. Mon dieu j’ai bien cru qu’on allait enchaîner sur le traité constitutionnel! Mais non, ouf, c’est le système d’information qui doit être flexible… Quoi que, une architecture orienté citoyen pour notre nouveau gouvernement, ça serait une idée 😉 Désolé, je m’égare. Les intervenants ont ensuite abordé la question sous différents angles. SOA, la notion de Service elle-même, Web services, BPEL et ESB sont les thèmes qui sont revenus. J’ai donc regroupé mes notes selon ces thèmes.

SOA

Soa est un style d’architecture
Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité.
On mesure le succès de la mise en place d’une SOA par le % de réutilisation des services.

Le but d’une SOA est de raccourcir les cycles de développement.
Le but d’une SOA est l’alignement de l’informatique sur le métier. Flexibilité dans le métier et dans le SI
Il faut augmenter le recouvrement entre le métier et l’informatique.
Il faut revisiter le métier pour le modéliser. Ce model doit être accepté et compris par les gens du SI et du métier.

SOA est une évolution technologique et une révolution dans la relation fonctionnel/ technique.
Un projet SOA doit être rattaché à la stratégie de l’entreprise sinon il n’a aucune chance de succès.

Le point départ de la démarche SOA est le constat suivant:
Les systèmes d’informations actuels sont trop souvent organisés par silos produits. Cette organisation offre peu de possibilités de réutilisation et ne permet pas de faire évoluer suffisamment rapidement le SI.

Principes fondamentaux derrière l’architecture SOA:
– Les ressources doivent être indépendantes de qui les utilisent
– Les évolutions technologiques ne doivent pas remettre en cause l’existant
– Découplage entre fournisseur et consommateur de services.

Il n’existe pas une recette pour garantir le succès de la mise en place d’une SOA mais des principes à respecter:
discussion entre IT et métier
se baser sur des use case métier
s’appuyer sur les standards

Bref rien de nouveau par rapport à un développement sans SOA.

Service

Un service n’est pas technologique mais métier (Importance des uses case). On trouvera la technologie dans l’implémentation du service métier.
Les services peuvent être combinés pour satisfaire à des processus. Ce qui permet de casser les silos.
Un service peut être appelé et peut appeler lui-même d’autres services

Un service est caractérisé par :
Neutralité vis-à-vis des protocoles de transport
Couplage faible entre consommateur et fournisseur
Une granularité importante

Identifier les services

C’est sans doute le problème central pour mettre en œuvre une SOA.

Seul les business analysts sont capables d’identifier un service réutilisable.

2 approches sont à considérer: (voir ce billet)

– Approche top-down:
La mise en place d’une SOA doit s’inscrire dans le cadre d’un plan directeur et d’une démarche d’urbanisation.

– Approche bottom-up:
La SOA est un moyen de réutiliser l’existant, on part des morceaux, on rassemble les bouts.
Mais une application legacy qui n’a pas été conçu dans le cadre d’une SOA est rarement réutilisable telle quelle. Il faut la modifier ou l’encapsuler.

IBM s’appuie sur 2 méthodologies pour mettre en place une SOA (c’est-à-dire identifier les services réutilisable):
– Component Business Modeling (CBM)
Le but est d’obtenir une cartographie du métier de l’entreprise.
A partir de cette carte on peut identifier les composants critiques selon les critères suivants:
Composant normal, compétitif ou différenciateur
Composant source de coûts ou de bénéfices

Un composant métier est délimité par les services qu’il consomme et ceux qu’il expose.

Cartographier le SI et faire correspondre cette cartographie avec celle du métier (urbanisation)

– Service Oriented Modeling & Architecture SOMA
Permet de faire le lien entre le métier et le SI

Décomposition en domaine (avec CBM)
Analyse de l’existant
Constitution d’un portefeuille de services candidats
Sélection et tri des services
Analyse des messages échangés

IBM recommande une approche MDD Model Driven Developpement pour la mise en place d’une SOA.

Ces méthodologies ne sont viables qu’en utilisant des outils. Les outils Rational bien sûr.

Granularité des services

La granularité des services est fondamentale dans une SOA. C’est elle qui va en grande partie déterminée la réutilisabilité des services. Il faut éviter une granularité trop fine car cela entraîne beaucoup d’interaction et donc des problèmes de performance en mode distribué. On recommande donc des services à “gros grain” (coarse grain) pour une SOA. Mais attention une granularité trop “épaisse”, un service qui fait trop de chose, risque de ne pas être réutilisable. Tout est question d’équilibre, il faut trouver le juste milieu.

Web Services
Une SOA peut se mettre en œuvre sans Web Services mais c’est aujourd’hui la meilleure solution disponible.
On peut utiliser les Web Services sans faire de SOA. Il s’agit alors d’une architecture point à point sans réutilisation.

Les Web service s’articule autour de 3 éléments: WSDL, SOAP, UDDI.
Seul WSDL est indispensable pour mettre en œuvre une SOA. Car c’est WSDL qui décrit le service

UDDI permet un binding dynamique des services (Le consommateurs découvre dynamiquement les services et leur fournisseurs). En pratique c’est très peu utilisé, la plus part des services sont consommés de manière statique: le consommateur connaît à l’avance le fournisseur.

BPEL
Norme permettant de décrire en xml des processus
Un processus est le résultat d’une orchestration de service. Le processus peut lui-même être accessible en tan que service.

On peut mettre en place une SOA sans orchestration de service. Mais à mon avis c’est passer à côté d’une grande partie de la valeur ajoutée d’une SOA.

ESB
Couche d’infrastructure qui optimise les échanges entre consommateurs et fournisseurs de services.
Le but d’un ESB est de permettre de communiquer de manière simple et standardisé entre des applications disparates.

C’est l’ESB qui fourni le service end-point. C’est le point d’entrée vers un service. Il doit être normalisé mais on ne sait pas qui fourni le service et comment il le fourni. On peut comparer le service end-point à une prise électrique. On peut brancher n’importe quel appareil qui respecte la norme (220 Volt, format de prise…) et la prise fournira du courant (le service) mais on ne sait pas d’où vient ce courant (centrale nucléaire, hydrolyque…)

Infrastructure SOA = middleware = ESB = Web Service + messaging (JMS) + integration Bref c’est de l’EAI

Mais il y aurait une différence avec l’EAI:

Dans un EAI on trouve une architecture en hub ou en étoile autour de connecteurs propriétaires liés au moteur d’intégration.
L’ESB est un EAI mais de part l’utilisation des web services les connecteurs sont dissociés du moteur d’intégration. On a donc plus de souplesse et d’ouverture. Je ne suis pas très convaincu, pour moi l’ESB reste un rebranding de l’EAI

Divers
On nous a aussi rapidement parlé de SDO, ça ressemble à du JDO ça a le goût de de JDO mais ce n’est pas du JDO…

IBM veut aussi faire un lien entre SOA et portails… Hum je ne vois pas bien… SOA pour accéder au contenu… Bof, REST ne serait pas plus adapté pour de la lecture de donnée??

On a aussi eu droit à une démo de Rational software architecte Ca à l’air pas mal pour faire de la modélisation UML. Mais on n’a pas eu les caractéristiques de la machine sur laquelle cela tournait…
Bon et bien sûr pour chacun de ces nombreux acronymes et concepts il existe un produit IBM qui va bien…

Recette pour un échec avec une SOA

Via Tim Bray

John Crupri nous explique que prendre des composants logiciels déjà existant et rajouter par dessus une couche de web services est une parfaite recette pour un échec dans la mise en place d’une architecture orientée service.
En effets ces composants n’ont certainement pas été conçus dans le cadre d’une SOA. Il y a donc peut de chance qu’ils soient atomiques, indépendents d’autres composants, et conçus avec une granunalirité les rendant réutilisables dans le cadre d’une SOA.

Bien que l’approche bottom-up (partir de l’existant pour construire une SOA) soit la plus naturelle et la plus simple. Il ne semble pas que soit la bonne approche. Il vaut mieux adopter un approche top-bottom: partir du business et aller vers la technique. Bref, l’application d’un principe qui n’est pas prêt de s’user: C’est la technique qui est au service du fonctionnel et non le contraire.
Tout celà nous rappel qu’il est nécessaire d’adopter une démarche d’urbanisation avant de ce lancer dans la mise en place d’une SOA.

Questions pour RESTafarians !

Après les architecture dé-testable voici les RESTafariens, à ne pas confondre avec les SOAPafariens 😉

Et c’est David Megginson qui pose 5 questions intéressantes. Ca commence par une définition simple de REST:

“REST in its now-broadened meaning is easy to explain: pieces of data (likely XML-encoded) sit out there on the web, and you manipulate them using HTTP’s GET, PUT. Try explaining SOAP, much less the essence of the whole WS-* family in one easy sentence like that, and you’ll see the difference.”

A lire, ainsi que les commentaires.