WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

SOA : Définition, Utilisation dans le monde de la banque et méthodologie de test

( Télécharger le fichier original )
par Cédric MORA
IFIPS - Maison de l'ingénieur - Spécialité informatique 2008
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

LES ESB (ENTERPRISE SERVICE BUS)

La définition de l'ESB permet de se rendre compte que c'est l'environnement parfait pour appliquer SOA. L'ESB est le médiateur : c'est une technologie informatique intergicielle permettant à des applications hétérogènes d'interagir au travers de services standards qu'elles mettent à disposition. Les principes sont la découverte dynamique (notre annuaire de services), la chorégraphie et l'orchestration de services (pas de coordinateur central dans la chorégraphie, chaque service connaît les services qu'il doit appeler) et la communication par messages. Les standards sont ceux des services web (SOAP, WSDL, ...) mais aussi la norme JBI (ESB est une implémentation de cette norme qui permet à des composants de communiquer via des messages), les messages JMS (Java Message Services) que je vais décrire plus tard, ... L'ESB permet de surveiller le trafic (« monitoring », console d'administration, fichiers de log, ...), d'imposer une qualité de service (gestion des transactions, assure la réception, permet de mettre en place des sécurités).

On peut voir l'ESB s'intégrer très bien en tant que médiateur :

L'ESB se place en médiateur entre les fournisseurs et les consommateurs de service.

Schéma simplifié d'un ESB (beaucoup de possibilités sont offertes).

Il existe beaucoup de patterns d'intégration - le terme français patron est peu utilisé - pour un ESB, qui modifient un peu le schéma ci-dessus et le complètent. J'ai détaillé ces patterns en annexe. Ils m'ont alors permis d'identifier, pour chaque projet dont on m'a donné la documentation, le pattern utilisé. J'ai d'ailleurs pu me rendre compte qu'un des projets ne faisait pas non plus vraiment du SOA mais plutôt des Web Services sans respecter l'architecture. Chaque pattern s'applique dans des conditions particulières et tout est possible si l'architecture SOA est respectée. Il est même possible, même si ce n'est pas recommandé, d'avoir plusieurs ESBs sous certaines conditions.

Les ESBs sont devenus très importants dans l'architecture SOA, ils offrent des possibilités qui deviennent indispensables à toute architecture. Parmi ces possibilités, il est possible de compléter SOA avec EDA (Event-Driven Architecture) qui est l'architecture dirigée par les évènements.

EDA (EVENT-DRIVEN ARCHITECTURE)

Un ESB permet aussi de faire de l'EDA qui est parfois vu comme un mode d'implémentation asynchrone de SOA ou juste une extension permettant de compléter l'architecture. Le fonctionnement est ici un peu différent : nous avons été habitués au « Request and Reply » (envoi d'une requête et réception de la réponse) alors qu'ici le principe est « Publish and Subscribe » (les informations sont publiées et si on veut les recevoir, on s'y abonne).

Une application publie des évènements dans un topic. Toutes les applications peuvent s'abonner à ce topic pour recevoir les évènements quand ils sont publiés.

La publication est dynamique : si jamais il y a de l'information à transmettre, elle est publiée et tout le monde peut souscrire à ce service à n'importe quel moment.

Les messages sont envoyés par une application dans une queue. Une autre application peut lire un message dans cette queue : elle le consomme. (Point à Point)

Le format des messages échangés pour utiliser cette fonctionnalité est, par exemple, JMS (Java Message Services). JMS permet deux modes de fonctionnement : le « Publish and Subscribe » - cela s'appelle un Topic -, et le « Send and Receive » - la Queue, envoi et récupération de messages -.

Les queues et les topics sont hébergés sur l'ESB. Un message JMS peut contenir un objet java ou du texte (donc du XML ou même des messages SOAP). Ce même message contient un en-tête permettant d'ajouter des informations (durée de vie, queue ou topic de retour de réponse, ...)

Pour comparer avec les Web Services appelés avec des messages SOAP sur HTTP, on a, d'un côté les Web Services avec des fichiers générés des 2 côtés pour faire le lien entre les messages échangés, et de l'autre une queue ou un topic faisant le lien :

· Web Service (HTTP)

Web Service

Skeleton

Stub

Client

· Queue (JMS)

Queue

Application

Application

En expliquant cette possibilité, on comprend que ce qui est important est la conception du service. L'idéal serait de proposer plusieurs moyens pour accéder au service selon la situation. On peut imaginer un objet natif qui gère les achats et utilise des applications de l'entreprise pour propager l'information. Cet objet peut avoir des méthodes pour acheter, ajouter des produits au panier, donner les informations de l'acheteur, etc. Appeler ces méthodes à un niveau local ne pose pas de problème mais, comme évoqué dans la définition des services, ce n'est pas une solution.

La solution est de fournir une méthode unique pour ajouter un ordre d'achat contenant toutes les données nécessaires. Cette méthode peut être décrite par le biais d'une interface et accessible par diverses technologies. Le service ne change pas, seulement le protocole de communication et le format des données échangées. Au consommateur du service de choisir le meilleur moyen d'accéder au service.

précédent sommaire suivant