jeudi 7 août 2008

SOA partie 1

SOA pour les nuls .


Service Oriented Architecture For Dummies


Voici je que j'ai retenu de ce livre :

Qu'est qu'une architecture SOA ? :

Une Architecture Orientée Service est une architecture logicielle permettant de construire des applications correspondant à des processus métiers par assemblage 'lache' de composant.


* SOA est fait pour batir des applications de gestion
* SOA est une boite noire , SOA masque la complexité d'un SI et facilite le branchement de nouveaux composant à cette boite noire.
* Les composants SOA sont reliés entres eux par un couplage 'lache' . Cela veut dire qu'il est non seulement possible de remplacer un composant par un autre mais aussi que le nouveau composant peut avoir une interface ou une invocation différente .
* Les composants sont agencés entre eux de manière à fournir un service bien précis correspondant à un processus métier.

Le SI prendra la forme d'un ensemble de composants organisés autour d'un bus applicatif appelé ESB : Entreprise Service Bus.
L'ESB est le tuyau par lequel les messages circulent d'un composant à un autre.

En plus des composants applicatifs , on trouvera un certain nombre de composants spécifiques comme :

* Le SOA registry
* Le moteur de workflow
* Le service broker
* Le superviseur

Le SOA registry est une sorte de base de registre , ou de catalogue où sont stocker les descriptions des composants. Il est utilisé par le broker comme annuaire de référence , mais aussi par les développeurs d'application comme référentiel des composants. Il stocke la descriptions des composants , la façon d'y accéder et les règles de fonctionnement. C'est dans le registry que sont publié les services. On peut utiliser pour cela un annuaire des services (UDDI Registry)

Le moteur de workflow est le composant responsable du bon acheminement des messages par l'ESB.

Le broker est le composant qui permet la mise en relation des composants entres eux.

Le superviseur : c'est le grand chef d'orchestre et aussi le surveillant du bus. Il a la possibilité de communiquer avec des couches plus basses. Il est aidé dans sa tache par des 'agents' qui supervisent les composants.

Cinématique d'une transaction.
Exemple :le composant A désire envoyer un message applicatif au composant B.

* Le composant A va envoyer une requête au broker en lui indiquant sa demande.
* Le broker va lancer une recherche auprès du Registry pour connaitre le composant B à activer et comment le solliciter.
* En réponse du registry le broker va connecter les composants A et B.
* Le composant A va envoyer son message à B.

Chaque composant est doté d'un 'adaptateur' . Cet adaptateur fait l'interface entre le composant et le bus applicatif , un composant peut posséder plusieurs d'accès. Ces méthodes seront exposées dans le Registry.
Exemples d'adaptateur

* Web service : on accède au composant par le protocole HTTP(S)
* Terminal adaptateur
* Connecteurs SQL
* Connecteurs dédiés (LDAP, CORBA,SOAP)

Le composant 'Registry' sert donc à :

* Stocker les descriptions des interfaces
* Les définitions des processus métiers
* Les règles de gestion de ces processus métiers
* La description du niveau de service
* Les règles de gouvernance

Tout ceci forme les métadonnées, ces métadonnées seront exploitées par le Broker

Le Broker va réclamer au Registry les métadonnées des composants pour pouvoir les faire dialoguer entres eux.
Les composants ayant un adaptateur SOAP expose le plus souvent leur interface par le biais du protocole WSDL (Web Service Description Language) . Par ce langage les web service expose ses conventions de connexion , de syntaxe de message et de typage de données . Toutes ces informations sont reprisent dans le UDDI Registry (Universal Description ,Discovery , and Integration) .

Le bus des services (ESB).
Il sert à connecter les composants métiers et techniques, et gère notamment :

* Le service des messages applicatifs
* La validation des messages
* Le transport des messages
* Le transcodage des messages
* La sécurité (intégrité, encryptage)

Enfin il doit etre capable de gérer des niveaux de priorités des massages et doit s'adapter aux performances globales.

1 commentaire:

Pascal Siauve a dit…

Très intéressant et surtout très synthétique. Je suis sur un projet ou je dois utiliser un intergiciel toutefois reste à déterminer le socle technologique (ESB vs EAI). As-tu des éléments sur ce sujet ?
J'ai bien identifié le coté propriétaire vs solution d'architecture avec donc un coût soit en licence soit en développement. Il y a aussi l'avantage avec les ESB de s'orienter vers des solutions plus normées (JBI, JTA…). Ma question est surtout sur la charge, nombre de messages, taille des messages, sécurité, traçabilité, rapidité des échanges ….
Merci de ton avis.
A bientôt amigo.
Pascal