CAHIER DES CHARGES - spirit182.free.frspirit182.free.fr/These-ESB-Benjamin-LINIER-rev1.pdf · 3 Exia.Cesi Benjamin LINIER Introduction Etudiant en 5ème année Management et Architecture

Exia.Cesi Année 2011-2012

Des bus de terrains, aux bus logiciels : Les « Entreprise Services Bus » (ESB)

THESE

Écrit par :

Benjamin LINIER Né le 9 avril 1986

À PAU

2 Exia.Cesi Benjamin LINIER

Sommaire

SOMMAIRE ...................................................................................................................................................... 2

INTRODUCTION ................................................................................................................................................ 3

ÉTAT DE L’ART .................................................................................................................................................. 4

1 PERIMETRE .............................................................................................................................................. 4

2 UN SYSTEME EN COUCHES : LE MODELE OSI ........................................................................................... 5

3 COUCHE PHYSIQUE : « LES BUS MATERIELS » .......................................................................................... 7

CARACTERISTIQUES D’UN BUS .................................................................................................................................... 7 EXEMPLES DE BUS .................................................................................................................................................... 9

4 TOPOLOGIE DES RESEAUX ..................................................................................................................... 11

TOPOLOGIE EN BUS ................................................................................................................................................ 11 TOPOLOGIE EN ETOILE (HUB AND SPOKE) ................................................................................................................... 13

5 COUCHE APPLICATION : « LES BUS LOGICIELS » ..................................................................................... 14

LES MIDDLEWARES ................................................................................................................................................. 14 LES ESB (ENTREPRISE SERVICE BUS) ......................................................................................................................... 15

6 BIBLIOGRAPHIE ..................................................................................................................................... 17

PROBLEMATIQUE ........................................................................................................................................... 19

7 QUELS SONT LES CONCEPTS CLES ? ....................................................................................................... 19

DEPLOIEMENT SUR UN SERVEUR D’APPLICATION .......................................................................................................... 19 CONTRAT DE SERVICE ............................................................................................................................................. 19 TRANSFORMATION DES MESSAGES ............................................................................................................................ 22 TRANSFORMATION DES DONNEES ............................................................................................................................. 22 PROTOCOLE DE TRANSPORT STANDARD ...................................................................................................................... 24 ROUTAGE INTELLIGENT ........................................................................................................................................... 25 ARCHITECTURE « NETWORK CENTRIC » ..................................................................................................................... 28

8 DIFFERENTES TECHNOLOGIES ................................................................................................................ 30

CORBA .............................................................................................................................................................. 30 DCE ................................................................................................................................................................... 31 DCOM ............................................................................................................................................................... 31 WCF .................................................................................................................................................................. 32 OPENESB / GLASSFISHESB ..................................................................................................................................... 33 PETALS ESB ......................................................................................................................................................... 34

9 NORMALISATIONS ................................................................................................................................ 35

SCA (SERVICE COMPONENT ARCHITECTURE) .............................................................................................................. 35 JBI (JAVA BUSINESS INTEGRATION) ........................................................................................................................... 38

PRATIQUE ...................................................................................................................................................... 39

CONCLUSION .................................................................................................................................................. 41

LEXIQUE ......................................................................................................................................................... 42


Introduction

Etudiant en 5ème année Management et Architecture des Systèmes d’Informations à l’Exia.Cesi de Pau, je réalise une thèse professionnelle sur un thème qui lie le domaine des logiciels avec le domaine des TIC (Technologies de l’Information et de la Communication) : les ESB (Entreprise Service Bus). J’ai choisis d’étudier ce thème car m’intéressant aux NTIC (Nouvelles Technologies de l’Information et de la Communication), à l’architecture des systèmes d’informations, et aux méthodes de développement logiciels, j’ai eu l’occasion lors de mes stages de travailler sur des projets où il y avait des ESB, mais ce concept me paraissait flou, voir inaboutis : En effet les principaux organismes de normalisation du web (IETF, ISO, W3C) ne spécifient pas le terme Entreprise Service Bus, et les grands acteurs du marché des logiciels présentent des concepts ESB qui sont parfois différents les uns des autres. Cette problématique soulève quelques interrogations auxquelles je vais répondre au travers de cette étude : Quels sont les concepts clés d’un ESB ? Quels sont les ESB du marché respectant ces concepts ? Une norme est-elle nécessaire pour fédérer les différents éditeurs de solutions ?


État de l’art

1 Périmètre Beaucoup d’ouvrages et d’articles présentent le concept de « Bus de services d’entreprise » comme une évolution des solutions d’EAI (Enterprise Application Integration), dont le principal but est de rationaliser l'intégration d’applications dans les entreprises. En effet grâce à un système EAI centralisé, les applications ne sont plus couplées par des liaisons point à point mais sont connectées au reste du système d’informations de façon indépendantes. L’EAI orchestre les communications selon le processus défini. Le livre blanc sur les ESB (Entreprise Services Bus) écrit par Adrien LOUIS met en évidence certains inconvénients des EAI, par exemple la présence de « single point of failure »1 dans les architectures centralisées, ou encore l’aspect propriétaire de leurs composants d’intégration (connecteurs, transformateurs de données, …) qui lie l'entreprise à l’éditeur. Les ESB reprennent les mêmes principes que les EAI mais s'appuient sur des standards, comme XML, WS-* …, puis reposent sur des architectures orientées services, dites « totalement distribuées ». Je n’insisterai pas dans ce mémoire sur la comparaison de ces deux technologies car beaucoup de travaux très intéressants exposent déjà le sujet, et mettent déjà en évidence la réduction les coûts d’intégration et de maintenance en intégrant un EAI ou un ESB. Ainsi j’introduirai les ESB en abordant un aspect peu traité : L’interopérabilité des applications dès leur conception grâce à une architecture de type « bus ». Cet État de l’Art expose le concept abstrait de « bus logiciel » ainsi que l’importance de standards, en s'appuyant sur des concepts concrets des domaines de la communication et des réseaux informatiques. J’exposerai en premier lieu la notion de « bus », et après avoir présenté les différentes pratiques, et topologies existantes, j’aborderai le sujet des « bus logiciels ». 1 Un « Single point of failure », ou « point unique de défaillance », est un élément critique dans un réseau, où si il venait à tomber en panne, cela affecterait l’ensemble du réseau.


2 Un système en couches : Le modèle OSI Le modèle OSI (Open Systems Interconnexion) est un modèle de communication proposé par l’ISO (International Organization for Standardization) visant à “ouvrir” l'interconnexion des systèmes informatiques, c’est à dire rendre interopérable les ordinateurs et leurs fonctions dans le monde entier. Ce modèle de communications est composé de sept couches : Couche 1 : La couche « physique » est la couche qui représente le matériel, elle regroupe des normes de liaisons physiques telles que 10BASE-2 par exemple pour des câbles coaxiaux, ou encore 100BASE-TX pour des câbles à double paire torsadés. Couche 2 : La couche « liaison » est une abstraction de la première couche, elle regroupe des protocoles qui implémentent ceux de la couche physique, en y ajoutant des notions d’adresses et de format de trames : Ethernet est un bon exemple. Couche 3 : La couche 3, la couche « réseau » vise l’interconnexion de réseaux de la couche inférieure en mettant en place un système d’adressage universel : IP (Internet Protocol), ainsi que des commutateurs de niveau 3 appelés routeurs. Couche 4 : La couche « transport » ajoute un niveau d’abstraction en permettant aux processus applicatifs de communiquer de façon transparente. Couche 5 : La couche « session » gère l’aspect transactionnel des communications, elle utilise la couche « transport » pour assurer l’échange de données de couches supérieures. Elle peut également permettre un cryptage de celles-ci. Couche 6 : La couche « présentation » représente le formatage des données, afin qu’elles soient traités par les applications. On trouve dans cette couche différents standards de formatage, comme par exemple XML, MIME, HTML, … Couche 7 : Il s’agit de la couche « application ». C’est celle qui est directement en relation avec les applications. Elle met à disposition un très large panel de protocoles, par exemple http utilisé par les serveurs web, ou encore SMTP utilisé par les serveurs de messagerie.


Ci-dessous un schéma qui représente les sept couches du modèle OSI :

Application

Présentation

Session

Transport

Réseau

Liaison

Physique

Interface couche 7/6






10011011

Application

Présentation

Session

Transport

Réseau

Liaison

Physique







Figure 1 : Modèle OSI


3 Couche physique : « les bus matériels » A l’origine, un bus est un élément constitué d’un ou plusieurs conducteurs physiques, servant à la communication d’équipements communicants (PC, serveur, cartes électroniques, …). L’émetteur et le récepteur sont connectés au même bus.

Caractéristiques d’un bus Deux types de liaisons Un bus peut être « série », c’est à dire que les bits sont véhiculés un à un selon une cadence de transmission sur une seule ligne, ou « parallèle », c’est à dire qu’il dispose de plusieurs lignes afin de transmettre plusieurs bits en même temps. Schématisation d’une liaison série transmettant une donnée de 8 bits sur 1 fil :

Émetteur Récepteur10100101

Figure 2 : liaison série

Schématisation d’une liaison parallèle transmettant la même donnée sur 8 fils :

Émetteur Récepteur1

0

0

1

0

1

1

0

Figure 3 : liaison parallèle


Mode de transmission Un bus permet aux équipements qui y sont connectés de communiquer soit dans un seul sens, comme le bus PS/2 liant une souris à un PC, soit dans les deux sens comme le bus IDE servant à l’écriture et à la lecture de données sur des disques durs. Nous parlons ici de modes simplex, ou de mode duplex. Dans le cas d’un bus IDE, qui est un bus parallèle sur 16 bits, les 16 conducteurs de données sont utilisés pour transmettre les données. Les équipements émettent alors à tours de rôle pour éviter les collisions. Il s’agit du mode half-duplex. Les bus séries sont souvent constituées de plusieurs lignes, ce qui permet alors de véhiculer l’information simultanément dans les deux directions, nous abordons alors la notion de mode full-duplex. Le schéma ci dessous illustre le mode full-duplex : Les équipements connectés au bus disposent d’un canal d’émission, et d’un canal de réception.

11010001

10100101Emission

Réception Emission

Réception

Equipement 1 Equipement 2

Figure 4 : liaison full-duplex

Mode de synchronisation Nous devons aussi aborder la notion de mode de synchronisation, importante dans les liaisons séries puisque le données sont composées de plusieurs bits transmis de façon successive, il faut donc que le récepteur distingue les données parmi les bits reçus, dans le même format que l’émetteur. En mode synchrone l'émetteur et le récepteur travaillent en même temps et les données sont transmises de façon cadencée suivant une horloge commune. En mode asynchrone, les données sont balisées par un bit de start et un bit de stop, ce qui permet leurs transmissions de façon irrégulière dans le temps.


Exemples de bus

Le bus USB (Universal Serial Bus)

Le bus USB est composé de quatre fils : une paire torsadée pour les données, et une paire pour l’alimentation. La communication se fait en half-duplex et est synchrone : Un équipement « maitre » transmet toutes les millisecondes une donnée spéciale servant à synchroniser les échanges. Il s’agit du paquet SOF (Start Of Frame), étant constitué de 11 bits dans la norme USB.

“Le début de paquet est marqué par la première transition D+D- (synchro) et la fin de paquet par l'état particulier EOP (End Of Packet) : D+=D-=0 pendant 2 bits puis on passe à l'état repos.”

Citation : http://ylescop.free.fr/mrim/cours/bus-USB.pdf

Voici les quatre fils schématisés, d’une liaison USB :

Equipement 1 Equipement 2

VBus

D +D -

GND

Longueur max : 5m

Figure 5 : Bus USB

Le bus RS-232 (port série) Les liaisons RS-232 (Recommended Standard 232) sont très utilisées dans les milieux de l’électronique et des réseaux informatiques. Le standard prévoie à l’origine une liaison sur 22fils, mais beaucoup d’équipement utilisent une sous-version de la norme complète, n’utilisant que 9 fils.

http://ylescop.free.fr/mrim/cours/bus-USB.pdf


Ci-dessous, une illustration du site internet http://techpubs.sgi.com. Elle représente le brochage d’un port série de PC, par un connecteur DB9.

Figure 6 : Connecteur port série

Nous constatons la présence de deux conducteurs de données sur cette liaison type série, ce qui permet un mode de transmission full duplex. Les appareils fonctionnant en RS-232 dispose d’une entrée RD pour la réception des données (Rx), et d’une sortie TD pour la transmission (Tx). Les autres conducteurs servent à envoyer des signaux de synchronisation, et de contrôle de flux (vérification de la validité des données transmises).

Le bus RS-422 Très utilisé dans l’électronique, le standard RS-422 permet de parcourir de longues distances (1200m). Il est fait de 4 fils véhiculant 100 kbit/s, la communication est full-duplex.

http://techpubs.sgi.com/


4 Topologie des réseaux

Topologie en bus Une topologie en bus est une topologie de réseau (informatiques, électroniques, ...), où les équipements sont connectés à un bus central et disposent chacun d’une adresse. Pour comprendre concrètement ce type de topologie basons nous sur l'exemple d’une technologie très connue : Le bus Ethernet. Les normes Ethernet de l’IEEE (Institute of Electrical and Electronics Engineers) ont pour but de standardiser l'interconnexion des équipements communicants. Elles offrent plusieurs standards de liaisons physiques types bus (10base2, 10baseT, …), et apportent en plus des normalisations dans les formats de trame, ce qui situe la technologie dans la couche “liaison” du modèle OSI. (au dessus de la couche “physique”). Voici la schématisation d’un bus Ethernet liant par exemple des ordinateurs et une imprimante :

Bus Ethernet

Figure 7 : Bus Ethernet

Dans ce type de topologie, plusieurs types de liaison physique peuvent être utilisés selon le standard choisis. Le standard 10BASE2 par exemple, utilise un câble coaxial


central et lie chaque poste par un connecteur en T. Ce standard faisant parti des plus anciens de la famille Ethernet, permet un mode de communication en half-duplex. Dans une telle liaison, étant donné que le câble central ne dispose que d’une seule âme servant à véhiculer l’information, les ordinateurs transmettent à tour de rôle et reçoivent tous le même signal donc les mêmes données. On dit qu’ils partagent le même domaine de collision, car s’ils émettent en même temps, les signaux se rencontrent et se perturbent. Les équipements d’un réseau en topologie bus disposent d’une adresse physique permettant d’identifier l’équipement sur le réseau. Dans le cas d’Ethernet, chaque équipement procède une adresse MAC (Media Access Control). Quel que soit le type de support choisis pour le bus (câble coaxial, fibres, ...), lors d’une communication, tout les équipements connectés entre l'émetteur et le récepteur perçoivent les messages, mais grâce à l’adresse MAC du destinataire inscrit dans l’en-tete de ceux-ci les équipements reconnaissent si ils en sont le destinataire. Les messages sont des données respectant le format de la norme, on parle de trame Ethernet, ou encore de paquet Ethernet. (« frame » ou « packet » en anglais). Voici le format d’une trame Ethernet de type II, elle contient l’adresse de l’émetteur, du destinataire, le type de trame, la donnée, puis quatre octets de contrôle Checksum2

(32bits).

Figure 8 : Trame Ethernet

Source de l’image : Wikipedia - http://fr.wikipedia.org/wiki/Ethernet

2 Checksum (somme de contrôle) : Il s’agit d’une opération logique effectuée sur les bits de données d’une trame, afin de vérifier sa validité à la réception.

http://fr.wikipedia.org/wiki/Ethernet


Topologie en étoile (Hub and Spoke) Une évolution de la topologie exposée précédemment consiste à placer au centre du réseau un élément actif, soit un concentrateur, soit un commutateur, et d’y raccorder chaque équipement du réseau par un bus dédié. Ce type de topologie est souvent appelé architecture « Hub and Spoke ». Un concentrateur (Hub) lie en un même point les bus qui y sont connectés. Tous les équipements partagent le même domaine de collision : Ils émettent à tour de rôle. Un commutateur (Switch) sépare les lignes et orchestre les communications. En lisant l’en-tête des trames, les commutateurs reconnaissent l’adresse de destination de celles-ci, et les transmettent ainsi sur le bus où est connecté l’équipement en question. Les équipements connectés au même commutateur partagent le même domaine de diffusion. Le schéma ci-dessous représente une topologie en étoile :

Commutateur

Bus 10 BASE-T ou 100 BASE-TX

Figure 9 : Topologie Hub and Spoke (étoile)

L’arrivée des standards se basant sur 4 fils ou encore sur 2 fibres obliques permet aux ordinateurs de communiquer maintenant en mode full-duplex dans une topologie étoile avec un commutateur.


Nous soulignons que dans ce type de topologie, le point sensible est l’élément central car s’il venait à ne plus fonctionner, cela affecterait l’ensemble du réseau.

5 Couche application : « les bus logiciels »

Les middlewares Dans les métiers de l’ingénierie des logiciels, une abstraction de l’aspect matériel est faite, ce sont les logiciels/services qui communiquent entre eux grâce aux protocoles des couches applicatives. Certains logiciels ont pour rôle d’interconnecter d’autres logiciels : Nous employons le terme d’« intergiciel », ou « middleware » en anglais pour qualifier ces logiciels.

Ils peuvent avoir plusieurs fonctions :

Echange/transformation de messages

Appel de procédure à distance

Manipulation d’objets

Gestion des transactions

Voici un schéma de plusieurs applications interconnectées par le biais d’un middleware :

Application 1 Application 3Middleware

Application 4

Application 2

Figure 10 : Middleware Hub and Spoke


Quand plusieurs applications sont interconnectées par un middleware centralisé, comme par exemple dans les solutions EAI (Entreprise Application Intégration), il s’agit d’une topologie en étoile (Hub and Spoke). Le middleware est installé sur un serveur et les applications dialoguent par l’intermédiaire de ce middleware. Dans ce type de solution, si le serveur hébergeant le middleware venait à être injoignable, toutes les applications seraient alors isolées.

Les ESB (Entreprise Service Bus) Un middleware peut aussi avoir une architecture en bus, dans ce cas là il n’est pas installé sur un serveur central, mais est totalement distribué. C'est-à-dire qu’il est constitué de points de terminaisons logiciels (endpoints) installés sur les équipements terminaux (ordinateurs) sous formes de libraires ou « frameworks » de communication. Les points de terminaisons sont interconnectés par des protocoles de la couches application du modèle OSI, par exemple http, FTP, MSMQ, JMS, propriétaire, …, on parle alors de bus logiciel. Chaque point de terminaison sur le bus dispose d’une adresse unique, cela peut être par exemple une adresse URI (Uniform Resource Identifier). Les applications utilisent alors les points de terminaisons de la même façon qu’elles utilisent une librairie d’objet, ce qui rend la communication transparente pour celles-ci.

Les middlewares en bus sont appelés ESB (Entreprise Services Bus). Il n’existe pas de standards qui définissent exactement ce concept, ainsi ce terme apparut à peu près en 2003 est parfois mal utilisé. Il est devenu synonyme de « SOA » (Service Oriented Architecture) et a parfois été redéfini par les éditeurs de solutions pour qu’il convienne à leur produit.

Ci-dessous, un schéma représentant le concept général d’un Entreprise Services Bus :

Figure 11 : ESB – Middleware distribué


L’ESB fonctionne selon le principe suivant :

Le service métier est placé dans un conteneur, qui peut être soit une application à part entière, soir un serveur d’applications.

Le service est exposé sur le réseau au travers d’un point de terminaison, qui l’encapsule dans un protocole de la couche applicative (couche 7 du modèle OSI).

Le service est référencé par le client et est alors exposé sous forme de référence objet.

Le client invoque le service sur l’ESB en utilisant sa propre technologie.

L’appel est transformé et véhiculé au bon point de terminaison en utilisant le protocole de communication défini dans l’ESB.

L’appel est routé et transporté sur le réseau, grâce à l’adresse du service appelé.

L’ESB invoque le vrai service par sa propre technologie.

Un ESB sert donc à interconnecter des applications en faisant abstraction de tous protocoles de communications de la couche applications. En effet les applications utilisent leur propre technologies pour se connecter à l’ESB, et donc pour s’interconnecter. Deux logiciels distants peuvent alors communiquer en faisant de simples appels de procédures tout en étant très faiblement couplés. Le consommateur ne connait que l’ESB, et ne connaît ni les formats ni les protocoles d’échanges utilisés par le fournisseur du service.

Un des gros avantage des ESB en dehors de cette flexibilité, est qu’ils fonctionnent en architecture « Network Centric », contrairement aux solutions d’EAI « Hub and spoke ». Ils ne s’appuient pas sur un composant centralisé, et permettent ainsi d’avoir une architecture limitant les points uniques de défaillances.


6 Bibliographie

Livre blanc : “Bus de services -ESB- Nouvelle technologie pour l’intégration” Adrien LOUIS, Novembre 2008 http://petals.ow2.org/docs/Livre-Blanc-ESB-fr.pdf Ce livre blanc est particulièrement intéressant, il expose le concept fonctionnel d’un ESB en le comparant aux solutions d’EAI (Enterprise Application Integration). Les deux technologies ont le même but, mais s’appuient sur des architectures différentes. L’une étant centralisée, l’autre distribuée. Je recommande particulièrement la lecture de ce document car il introduit très bien le sujet, et je partage pleinement l’idée principale qui en ressort : Les ESB révolutionnent les communications d’applications, mais ne sont pas aboutis, pas formalisés.

Article : “Enterprise Service Bus (ESB): tendance de fond ou nouveau "buzzword"?” Nicolas Farges, Mars 2003 http://www.zdnet.fr/actualites/enterprise-service-bus-esb-tendance-de-fond-ou-nouveau-buzzword-2132625.htm Cet article présente les principaux défauts des solutions EAI, et introduit les motivations qui ont poussés les concepts ESB à faire leur apparition. Il expose également les problèmes d’urbanisations dues à la multiplicité des organismes de normalisations et d’éditeurs de solutions. La lecture de cet article m’a permis de consolider la thèse suivante : Il est nécessaire de standardiser un minimum le terme ESB, qui ne doit pas devenir une marque ou tout autre mot commercial utilisé à tort. Ce qui freinerait l’évolution des vrais ESB, c’est-à-dire ceux qui respectent des principes précis, décrits au travers de l’Etat de l’Art de ce mémoire.

Article : “RS 232” Wikipedia http://fr.wikipedia.org/wiki/RS-232 L’article de Wikipédia sur les bus RS-232 présente les concepts des liaisons séries. Il met en évidence qu’un réseau d’équipement peut avoir une topologie « bus » en s’appuyant sur plusieurs liaisons séries point à point. Une telle topologie utilise alors des équipements de communication (DCE), et des

http://petals.ow2.org/docs/Livre-Blanc-ESB-fr.pdf

http://www.zdnet.fr/actualites/enterprise-service-bus-esb-tendance-de-fond-ou-nouveau-buzzword-2132625.htm

http://www.zdnet.fr/actualites/enterprise-service-bus-esb-tendance-de-fond-ou-nouveau-buzzword-2132625.htm

http://fr.wikipedia.org/wiki/RS-232


équipements de terminaison (DTE). On retrouve les mêmes concepts sur Ethernet, ou encore sur une technologie plus abstraite : Internet.

Discussion de professionnels Développez.net http://www.developpez.net/forums/d260220/java/serveurs-conteneurs-java-ee/java-ee/ca-marche/ Cette discussion m’a fait sourire lorsque je recherchais des informations techniques sur les ESB, car cela fait plusieurs années que beaucoup se demandent quelle est la signification réelle du terme, et aujourd’hui en 2012, mes recherches démontrent que le problème n’a pas avancé. Cet article cite également le « Livre blanc sur les ESB » présenté ci-avant, document populaire sur lequel s’appuient ceux qui cherchent des réponses sur cette thématique.

http://www.developpez.net/forums/d260220/java/serveurs-conteneurs-java-ee/java-ee/ca-marche/

http://www.developpez.net/forums/d260220/java/serveurs-conteneurs-java-ee/java-ee/ca-marche/


Problématique

7 Quels sont les concepts clés ? Les différents éditeurs de d’ESB proposent des panels de fonctionnalité différents les uns des autres, plus ou moins étendus, parfois s’appuyant sur des technologies propriétaires, des concepts clés sont quand même communs à la plupart d’entre eux.

Déploiement sur un serveur d’application Une application souhaitant exposer ses services sur le réseau peut être déployée dans un serveur d’application, profitant ainsi de son intégration et sa qualité de service. Les fonctionnalités des services exposés sont alors mappées par les mécanismes de l’ESB avec des points de terminaisons du serveur d’application, sous forme d’URI, souvent grâce à des fichiers de configuration. Les serveurs d’applications les plus rependus sont :

Apache Tomcat

IBM WebSphere App Server

JBoss Application Server

BEA WebLogic

Glassfish

Microsoft IIS

… L’utilisation d’un tel conteneur n’est pas indispensable, les solutions ESB proposant parfois d’intégrer un micro-serveur à l’intérieur même de nos applications, mais elle comporte des avantages, comme rendre homogène les méthodes d’intégration, ou de maintenance. Il s’agit souvent d’un serveur d’application web (protocole http), mais les applications utilisent parfois d’autres protocoles applicatifs, tels que des protocoles de messagerie, JMS (Java Message Service), MSMQ (Microsoft Message Queuing), FTP (File Transfer Prorocol), …

Contrat de service Les services exposés par un ESB à un point de terminaison sont décrit au travers d’un « contrat de service », décrivant les types de messages, les sens de communications et leur mode (synchrone ou asynchrone). Ces contrats de services peuvent êtres standardisés sous plusieurs formes : IDL (Interface Definition Language), interface objet, structure XML, WSDL, …


IDL (Interface Definition Language) L’IDL est un langage de spécification pour décrire le comportement d’un composant logiciel servant d’interface avec d’autres composants, de façon neutre et homogène. C'est-à-dire que deux applications développées dans des langages différents peuvent dialoguer en utilisant les méthodes et types de données décrites par l’IDL sous forme générique. Ce langage a été créé par l’OMG (Object Management Group) dans un but d’interopérabilité dans les applications comportant plusieurs langages.

Ci-dessous, l’exemple d’un contrat IDL spécifiant les interactions sur un répertoire de personnes :

module annuaire {

typedef string Nom; // Nom d’une personne

typedef sequence<Nom> DesNoms; // Ensemble de noms

struct Personne { // Description d’une personne

Nom nom; // - son nom

string telephone; // - numéro de téléphone

string email; // - adresse e-mail

};

interface Repertoire { // Description de l’interface

// Exceptions possibles

exception ExisteDeja (Nom nom; );

exception Inconnu (Nom nom; );

// Appels possibles

void ajouterPersonne (in Personne personne)

raises ExisteDeja ;

void retirerPersonne(in Nom nom)

raises Inconnu ;

void modifierPersonne(in Nom nom, in Personne personne)

raises Inconnu;

Personne obtenirPersonne (in Nom nom)

raises Inconnu ;

DesNoms listerNoms ();

};

};

Ce langage expose par exemple les fonctionnalités des services CORBA (Common Object Request Broker Architecture).

WSDL (Web Services Description Language)

Le Web Service Description Language est un langage basé sur une syntaxe XML, utilisé pour décrire les fonctionnalités d’un Web Service. Il décrit l’emplacement web du service (URL), les opérations proposées par le service, les types de données en entrée, et en sortie.


Ci-dessous un extrait d’un contrat de service WSDL généré par MS Visual Studio, proposant les opérations Addition et Soustraction.

<wsdl:definitions targetNamespace="http://tempuri.org/"> <wsdl:service name="OperationService"> <wsdl:port name="OperationServiceSoap" binding="tns:OperationServiceSoap"> <soap:address location="http://localhost:1500/WebSite1/OperationService.asmx"/> </wsdl:port> <wsdl:port name="OperationServiceSoap12" binding="tns:OperationServiceSoap12"> <soap12:address location="http://localhost:1500/WebSite1/OperationService.asmx"/> </wsdl:port> </wsdl:service <wsdl:types> <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/"> <s:element name="Addition"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="x" type="s:int"/> <s:element minOccurs="1" maxOccurs="1" name="y" type="s:int"/> </s:sequence> </s:complexType> </s:element> <s:element name="AdditionResponse"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="AdditionResult" type="s:int"/> </s:sequence> </s:complexType> </s:element> <s:element name="Soustraction"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="x" type="s:int"/> <s:element minOccurs="1" maxOccurs="1" name="y" type="s:int"/> </s:sequence> </s:complexType> </s:element> <s:element name="SoustractionResponse"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="SoustractionResult" type="s:int"/> </s:sequence> </s:complexType> </s:element> </s:schema> </wsdl:types> <wsdl:service name="OperationService"> <wsdl:port name="OperationServiceSoap" binding="tns:OperationServiceSoap"> <soap:address location="http://localhost:1500/WebSite1/OperationService.asmx"/> </wsdl:port> <wsdl:port name="OperationServiceSoap12" binding="tns:OperationServiceSoap12"> <soap12:address location="http://localhost:1500/WebSite1/OperationService.asmx"/> </wsdl:port> </wsdl:service> [ … ] </wsdl:definitions>


Transformation des messages Toutes les applications ne disposent pas d’une technologie leur permettant de s’interconnecter avec n’importe quelle autre application. Les ESB supportent donc de nombreux protocoles de communication, leur permettant ainsi de s’interconnecter nativement avec la plupart des applications métiers existante comprenant ces moyens de communication. Ils proposent ainsi des fonctionnalités de transformations de messages, soit de conversion de protocole.

Application Service exposé

ESBAdapteur XML

Adapteur Fichier

Messages XML Fichier

Transformation

Figure 12 : Transformation des messages

Le schéma ci-dessus présente un service attendant en entrée un fichier plat formaté. Le service est consommé par une application envoyant des messages XML (Java Message Service) transformés par l’ESB pour convenir au bon format. Ce concept se rapproche des concepts de transformations que proposent les solutions d’EAI. Dans les différents types de messages possibles nous trouvons par exemple les messages SOAP (Simple Object Access Protocol) dérivés de XML, les messages JMS pour les environnements Java, Fichiers formatés, e-mail, …

Transformation des données Les données d’une application sont typées en fonctions des différentes valeurs qu’elles peuvent recevoir, les différents types de données utilisables sont fortement liés à la technologie utilisée. Dans un environnement .NET par exemple nous retrouvons les types primitifs suivant : Byte, Boolean, Decimal, Float, Int32, Int64, …, alors qu’un environnement J2EE proposera les types byte, boolean, double, float, int, …


Un ESB transforme les données qu’il reçoit en un format pivot afin de rendre homogène les conversions de types de données d’une technologie à l’autre. Dans le cas des ESB s’appuyant sur des normes XML, les types pivots, appelés aussi types canoniques, sont normalisé au travers de schémas XSD (XML Schema Definition) définis par W3C. Ci après, une liste non exhaustive de différents types simples disponibles en XML :

Type XSD Description xs:string Chaine de caractères xs:normalizedString Suite de blancs compactée xs:decimal Nombre décimaux xs:float Nombre reel simple xs:double Nombre reel double xs:time Heure HH:MM:SS.sss xs:date Date YYYY-MM-DD xs:dateTime dateTtime xs:integer Entier xs:positiveInteger Entier positif xs:negativeInteger Entier négatif …

Une description plus complète de ces types est disponible sur le site de W3C à l’adresse suivante : http://www.w3.org/TR/xmlschema-2/ Pour les ESB s’appuyant sur le langage IDL, comme c’est le cas pour CORBA par exemple, les types pivots sont normalisés par l’OMG. Une description complète est disponible dans la norme IDL version 3.5, chapitre 5.11 : http://www.omg.org/cgi-bin/doc?mars/2011-09-08.pdf, en voici une courte énumération avec leur équivalent en C++, puis en Java :

IDL C++ Java

short CORBA::Short short

unsigned short CORBA::UShort short

long CORBA::Long int

unsigned long CORBA::ULong int

long long CORBA::LongLong long

unsigned long long CORBA::ULongLong long

float CORBA::Float float

double CORBA::Double double

long double CORBA::LongDouble Non défini

http://www.w3.org/TR/xmlschema-2/

http://www.omg.org/cgi-bin/doc?mars/2011-09-08.pdf

http://www.omg.org/cgi-bin/doc?mars/2011-09-08.pdf


boolean CORBA::Boolean boolean

octet CORBA::Octet byte

char CORBA::Char char

wchar CORBA::WChar char

string CORBA::String String

wstring CORBA::WString String

fixed CORBA::Fixed java.math.BigDecimal

Protocole de transport standard Au-delà de la transformation des messages, destiné à rendre interopérable différents systèmes s’appuyant sur leur propre technologie, un ESB peu fournir plusieurs protocoles de transport afin de véhiculer ces messages d’un point de terminaison à un autre. Cela apporte une couche d’abstraction supplémentaire, rendant l’intégration transparente, puisque les développeurs de services ou d’applications consommant ces services, n’ont pas à se soucier de quelle façons un point de terminaison communique avec un autre. Certaines solutions ESB proposent des mécanismes de configuration, appelés « binding », destinés à choisir au moment de l’intégration, quels protocoles utiliser pour véhiculer les messages d’un point à un autre. Autrement dit, quel que soit le format de messages à transmettre, un sous-système les encapsule afin de les transmettre au travers du réseau. Ainsi un message formaté selon la norme SOAP peut être véhiculé aussi bien en http, qu’en un protocole plus bas niveau tel que TCP. Parmi ces standards de transport, nous trouvons par exemple :

HTTP Requêtes et réponses http

Mail Envoie et Réception d’e-mails

WS-* Protocoles de la famille des WebServices

JMS Java Message System

MSMQ Microsoft Message Queuing

TCP Requêtes TCP

XMPP Envois/Ecoute de messages sur réseaux XMPP

FTP File Transfer Protocol

GIOP Général Inter Orb Protocol (CORBA)

…


Application Service exposé

ESBAdapteur

XMLAdapteur

Fichier

Messages XML Fichier

Transport HTTP, Mail, TCP, JMS, ...

Figure 13 : Transport des messages

Routage intelligent Un ESB doit être capable de déterminer la destination d’un message, soit en fonction de son contenu, soit en fonction de règles pré établies. En effet dans une architecture orienté services, les différents services du SI sont répartis physiquement, c'est-à-dire qu’ils sont déployés dans des machines différentes, et sont connectés au « bus » par l’intermédiaires de point de terminaisons (endpoints). Les développeurs de services, ou d’applications consommant ces services, ne savent pas à l’avance dans quel environnement seront déployés les services qu’ils développent, ils se contentent d’implémenter la liaison entre les fonctionnalités qu’ils développent et le point de terminaison du bus, en déclarant dans celui-ci les contrats de services exposés. Les fonctionnalités de routage intelligent permettent les pratiques suivantes :

Router les messages vers une adresse URL qui correspond à un service exposé. L’URL représente alors l’emplacement physique du service.


ESB

Service A Service B

Service CApplication

Message

Http://serveur1:5555/endpoint1 Http://serveur1:5555/endpoint2

Http://serveur2:5555/endpoint1

Figure 14 : Routage vers une URL

Router les messages vers un autre service assurant la même fonction, dans le cas ou le service initial serait indisponible (Haute disponibilité).

ESB

Service A Service B


Message



Reroutage

Figure 15 : Routage Haute Disponibilité

Router des messages en fonction de leur contenu.

Router des messages simultanément vers plusieurs services. (multicast).


ESB

Service A Service B


Message



Figure 16 : Routage vers plusieurs destinataires (multicast)

Masquer l’architecture du SI à une application en lui proposant un point d’entrée unique, servant alors de façade.

ESB Interne

Service « Facade » Service AApplication

Externe

Message



Internet

Service B

Figure 17 : Routage par un point d’entrée unique.

Utiliser des protocoles différents pour un même service en proposant plusieurs points d’entrées.

ESB ServiceApplication

Message


Tcp://serveur1:5555/endpoint2

Ftp://serveur1:5555/endpoint3

Figure 18 : Liaison à plusieurs points de terminaisons


Architecture « Network Centric »

« Network Centric » est un type d’architecture décentralisé, soit type « bus », en opposition avec les architectures « Hub and Spoke » présentés précédemment, ou la charge est répartie entre les différents processeurs du réseau, le composant central étant le réseau lui-même. Fondamentalement une intégration de deux applications communicantes est distribuée puisque les applications sont la plupart du temps hébergées dans des machines différentes, parfois appartenant à des domaines de responsabilités différents. Cet aspect de distribution est plus évident pour les applications B2B puisque les centres de données appartiennent à des entités différentes. Les solutions d’EAI classiques sont conçues selon un modèle architectural « Hub and Spoke », c'est-à-dire qu’elles placent un élément actif au centre du réseau, servant à orchestrer touts les échanges. Ce type d’architecture peut être valable pour une intégration départementale, mais elle n’est pas adaptée à l’échelle de l’entreprise, et encore moins aux réseaux B2B.

EAI

Service BApplication

Message

Service A

Figure 19 : Solution EAI centralisée

Les principaux problèmes rencontrés sont à la fois technique et organisationnel : D’un point de vue technique, le principal problème est que le point central de l’architecture est un SPOF (Single Point Of Failure). Ainsi, il devient un goulot d’étranglement et doit être pris en charge par des techniques couteuse de clustering pour assurer sa haute disponibilité et sa répartition des charges. Dans certains cas, l’architecture « Hub and Spoke » ne peut pas supporter tout les flux de données de l’entreprise, l’élément central peut donc être divisé en plusieurs éléments interconnectés, la gestion et le suivit d’une telle topologie devient vite un cauchemar pour les administrateurs.


D’un point de vue organisationnel, dans une telle architecture, l’élément central devient critique en termes de responsabilités. Dans l’entreprise, la création d’un centre de compétences en intégration responsable du « hub » (point central) peut être une solution, mais il semble que dans de nombreux cas, les propriétaires d’applications métiers retissent à déléguer tant de responsabilité à un composant central. Pour le B2B, il faut noter que le modèle « Hub and Spoke » ne correspond pas bien. Pour les raisons organisationnelles cités ci-dessus, le modèle distribué peer to peer correspond mieux, nous parlons donc de modèle architectural type « bus », ou encore « Network Centric ». Le « bus » de l’ESB devient alors virtuel puisqu’il s’agit des différents moyens de communications reliant les différents points de terminaisons entre eux.

ESB

Service BApplication

Message

Service A

ESB

ESB

Figure 20 : Solution ESB distribuée

Source : http://petals.ow2.org/why-is-distribution-important-in-petals-esb.html

http://petals.ow2.org/why-is-distribution-important-in-petals-esb.html


8 Différentes technologies

CORBA CORBA est l’acronyme de « Common Object Request Broker Architecture », c’est un standard défini par l’OMG (Object Management Group) en 1992, dont l’objectif est de fournir un environnement de développement et d’exécution portable aux applications réparties. C'est-à-dire qu’il est indépendant des langages de programmation utilisés, ou encore des protocoles de communications. Les environnements dont les composants communiquent par l’intermédiaire de CORBA ont une topologie type BUS puisque cette technologie est décentralisée. L’ORB (Object Request Broker) est le composant de CORBA servant à exposer les objets, il est souvent désigné comme « Bus d’objet répartis ». Les composants CORBA communiquent par messages, dont la syntaxe est formalisée par le protocole GIOP (General Inter-ORB Protocol). Nous retrouvons dans la norme CORBA la notion de contrat de service, les fonctionnalités d’un service exposé sont décrites au travers d’un fichier IDL (Interface Definition Language). La plupart des concepts exposés précédemment sont présent dans la technologie CORBA, ce qui nous permet de pouvoir classer cette technologie dans la famille des ESB.


DCE DCE, acronyme de « Distributed Computing Environment », est une technologie un peu plus âgée que CORBA, offrant des mécanismes d’appels de procédures à distance (RPC) pour le développement d’application distribués. Il s’agit d’un middleware stable, disposant de fonctionnalités avancées telles que l’authentification et le chiffrage en utilisant des systèmes Kerberos, mais il n’est plus beaucoup utilisé. Bien que l’architecture des systèmes utilisant DCE soit centralisée, et que la technologie s’appuis sur le langage IDL pour l’interopérabilité des services exposés, cela n’en fait pas une solution ESB puisqu’elle s’appuie sur des sous-systèmes propriétaires, et n’utilise que très peu, voir pas de standards.

DCOM DCOM (Distributed Component Object Model) est une solution propriétaire de Microsoft basée sur COM+. Elle permet d’appeler à distance des objets COM. Cette solution a longtemps été un important concurrent à CORBA, bien qu’elle ne soit pas portable, en effet elle ne s’appuie pas sur un protocole de transfert standard tel que le fait CORBA avec GIOP, mais réalise des appels de procédures distantes par échanges binaires (ORPC). Le transport se fait en HTTP, et la description de services ce fait en un langage intermédiaire appelé IDL, mais il s’agit d’une version remaniée par Microsoft de la norme et non pas celle de l’OMG.

Les environnements utilisant DCOM pour communiquer sont également répartis. Cette technologie respecte certain concepts des ESB, très proche de l’architecture CORBA, elle ne permet cependant pas une interopérabilité optimale avec les technologies non-Microsoft. Je pense que nous ne pouvons pas affirmer que DCOM est un ESB au même titre que CORBA.

Source : http://windows.developpez.com/faq/dcom/

http://windows.developpez.com/faq/dcom/


WCF WCF (Windows Communication Foundation) est la réponse Microsoft à la problématique ESB. Il s’agit d’un Framework permettant d’unifier différents moyens de communications et permettant par son niveau d’abstraction une redistribution des rôles : Le développeur conçoit et développe son service, l’intégrateur définit le protocole de communication et sécurise le service. Par default les messages sont formalisés en SOAP, mais plusieurs moyens de communications paramétrables (bindings) sont possibles : MSMQ, TCP, WS-*, … Les développeurs utilisant la technologie WCF ne se soucient pas des communications réseaux. En effet une application distante peut exposer ses fonctionnalités, dites « services », pour les rendre consommable de la même façon qu’on utilise une libraire. Le framework à pour rôle de transformer et router les appels, de façon synchrone ou asynchrone. Cette technologie, apparue dans le .NET Framework en 2006, apporte une nouveauté dans les environnements Microsoft : La possibilité aisée, grâce à l’utilisation de standards, de s’interconnecter avec des applications non Microsoft, contrairement aux technologies précédentes proposés par l’éditeur (DCOM, MSRPC). Dans sa configuration optimale c'est-à-dire dans une liaison entre plusieurs applications .NET, les contrats de services WCF sont sous forme d’une interface objet partagée, et les messages sont sous forme binaire, mais les systèmes de configurations très poussés de la technologie lui permettent d’exposer ses services en générant des contrats WSDL, et de transporter les messages par plusieurs moyens (http, Msmq, Tcp, Mail, …). WCF propose également des fonctionnalités d’authentification, de gestion des sessions, de gestion des transactions, ce Framework très large en fonctionnalités s’accorde avec les principes ESB exposés dans ce mémoire.


OpenESB / GlassfishESB OpenESB est développé par une communauté open source dirigée initialement par Sun Microsystems. Il s’agit d’une solution d’intégration dont le but et d’orchestrer les communications entre plusieurs applications par le biais de processus BPEL (Business Process Execution Language) et de connecteurs spécifiques. Dans un tel système, des modèles de workflow sont définis dans un serveur d’application (JBoss, Websphere, Tomcat, …), et les applications métiers utilisent leurs technologies respectives pour interagir avec le moteur d’orchestration par le biais de connecteurs. Nous pouvons noter que les principes d’architecture totalement distribuées type « bus » introduites dans ce mémoire ne sont que partiellement respectés, puisque deux applications souhaitant communiquer par l’intermédiaire de cette solutions, doivent passer par un composant central : Le serveur d’application hébergeant OpenESB. Si nous admettons les concepts exposés précédemment, le terme « ESB » dans OpenESB n’est qu’un argument commercial. Il s’agit en réalité d’une solution EAI centralisée, qu’il est possible de déployer en cluster afin de profiter de mécanismes de haute disponibilité.


Petals ESB

Petals ESB est une solution ESB open source destinée aux larges architectures SOA. Il s’agit d’une technologie distribuée s’appuyant sur des standards tels que JBI, SCA, WSDL, ou encore WS-*. Petals ESB est développé par Petals Link, et propose plusieurs des mécanismes ESB présentés ci-avant, comme par exemple le routage intelligent, l’interconnexion par l’intermédiaire de standards, ou encore la transformation des messages. Nous soulignons l’absence de « single point of failure » dans un environnement Petals ESB, puisque chaque applications du SI procède une partie du bus (point de terminaisons). Le respect de tout ces concepts, ainsi que sa topologie « Network Centric », classent la solution dans la famille des ESB.

Figure 21 : Le bus Petals ESB

Source de l’image :

http://www.petalslink.com/sites/default/files/rsc/docs/products/petals_esb-fr.pdf

http://www.petalslink.com/sites/default/files/rsc/docs/products/petals_esb-fr.pdf


9 Normalisations Comme présenté précédemment, il n’existe pas de norme « ESB ». Il s’agit d’une tendance s’appuyant sur des concepts clés, ou encore sur un modèle architectural (Design Pattern) type « bus ». Durant mon étude j’ai découvert deux familles de spécifications dont je n’avais pas connaissance, sur lesquels s’appuient les éditeurs de solutions ESB : SCA et JBI.

SCA (Service Component Architecture) SCA est une spécification issue du consortium OpenSOA regroupant différents éditeurs logiciels (IBM, SAP, Oracle, Iona, Zend …). Elle a pour objectif de simplifier et harmoniser la conception d’architectures orientées services (SOA) en proposant un modèle d’architecture unique, basé sur le principe de composants réutilisables, et en s’appuyant sur des technologies existantes et des standards ouverts :

Langages de description de services (Contrat de services) : WSDL, Interfaces objets, IDL, …)

Langage de programmation de composants : Java, C++, C#, BPEL, …

Protocoles de communication : SOAP, http, JMS, RMI, … SCA est en cours de normalisation par OASIS (Organization for the Advancement of Structured Information Standards), tous les grands éditeurs annoncent que cette spécification est au cœur de leurs offres ESB. Cette spécification soutient un large panel de mécanismes d’accès utilisés pour invoquer les services, il s’agit notamment des WebServices SOAP, des systèmes de transferts de messages (JMS, MSMQ, …), ou encore CORBA IIOP. Selon SCA, un service est une application qui comporte les caractéristiques suivantes :

Large granularité : Les opérations exposées par un service encapsulent plusieurs fonctions, en opposition avec un composant technique n’assurant qu’une seule fonction.

Interfaçage : Un service peut implémenter plusieurs interfaces, et inversement, une interface peut être implémentée par plusieurs services.

Localisable : Pour appeler un service, il faut au préalablement connaitre son emplacement, soit « le trouver ».


Couplage faible : L’exposition d’un service doit se faire selon des standards, comme par exemple XML dans le cas des WebServices.

La spécification SCA se décline en trois grandes parties :

1) Faciliter la réutilisation : l’Assemblage

Dans le vocabulaire de SCA, un « composite » est un groupe de composants accomplissant une tâche particulière. Cette notion simplifie la réutilisation puisque un composant n’est pas lié à une fonctionnalité métier, et peut donc être réutilisé à souhait. Un exemple de composant est par exemple un composant servant à chiffrer les communications, ou encore à assurer une authentification, … SCA défini comment lier les composants avec les composites, et permet de définir les propriétés pour un service sans changer l’implémentation de son code.

2) Faciliter l’interconnexion Deux modèles d’interconnexions sont précisés : l’interconnexion d’applications s’appuyant sur la même technologie (CORBA, WCF, …), et l’interconnexion d’applications utilisant des technologies différentes. Dans le premier cas, les développeurs ont seulement une interface objet à connaitre. Ils peuvent l’implémenter, et l’appeler dans la technologie de leur choix à condition que celle-ci soit compatible SCA. Ce procédé est utilisé par exemple dans le cas de deux applications WCF communiquant ensembles. Dans le second cas, les services doivent pouvoir être invoqués en utilisant des protocoles de communications ouverts, tels que SOAP, JMS, EJB, …, Dans ces deux solutions, c’est l’environnement, qui lie les services métiers avec les moyens de communications. En définissant ces méthodes d’accès en dehors du code, par exemple dans des fichiers de configurations XML, elles peuvent être modifiées ou remplacées sans impact sur le code. Cela s’appelle le « Binding ».

3) Fiabiliser les communications Dans un cadre SCA il est possible de définir des politiques de sécurité, d’authentification, et de qualité de service, conformes aux standards ouverts WS-Policy et WS-Security. Un administrateur peut paramétrer un service pour activer des mécanismes de cryptage ou encore d’authentification, sans toucher au code du service. Nous notons une séparation des rôles entre développeurs et intégrateurs.

Sources :

Livre blanc SCA : http://www.obeo.fr/resources/Obeo%20-%20Livre%20Blanc%20-%20SCA.pdf

http://www.obeo.fr/resources/Obeo%20-%20Livre%20Blanc%20-%20SCA.pdf



Ci-dessous, un schéma illustrant le modèle topologique de SCA. Nous remarquons que les services SCA sont interconnectés par l’intermédiaire de point de terminaisons, et qu’une application non-SCA peut aussi communiquer avec les services exposés grâce à un « binding standard », soit un point de terminaisons encapsulant les services selon un moyen de communication standard (SOAP, http, JMS, …).

Figure 22 : Modèle SCA

Source de l’image : http://www.obeo.fr/resources/Obeo%20-%20Livre%20Blanc%20-

%20SCA.pdf




JBI (Java Business Integration) La norme JBI a été éditée en 2005 par JCP (Java Community Process), organisation crée par Sun Microsystems dans le but de maintenir les technologies liées à Java. Plusieurs solutions ESB du marché sont dites « conformes JBI » par leurs éditeurs, certains articles que j’ai pu lire expliquent également que JBI est un standard pour les ESB. Cependant il n’est spécifié à aucun endroit dans la norme, que ce standard traite le sujet des ESB. Au contraire dans l’introduction de celle-ci, il est expliqué que le but est de rationnaliser l’intégration des solutions EAI, en proposant un environnement d’orchestration s’appuyant sur des conteneurs et des connecteurs standardisés. Dans ce même sens, les concepts présentés par JBI se rapprochent plus à des concepts d’architecture « Hub and Spoke », qu’a des topologies « Network Centric » type « bus ». « JBI, as currently defined, is not distributed » (Norme JBI 1.0 page 205) Il est donc, à mon avis, faux d’affirmer qu’implémenter la norme JBI suffis à avoir une solution ESB.

Norme JBI Final Release : http://download.oracle.com/otn-pub/jcp/jbi-1.0-fr-oth-JSpec/jbi-1_0-fr-spec.pdf

« JBI est un standard basé sur Java, qui définit une architecture pour permettre l’interopérabilité d’applications avec un système d’échanges de messages. Les messages entre les composants sont échangés à travers un composant médiateur.»

Citation : http://bertrand.guiral.free.fr/jee/soa-jbi.html

http://download.oracle.com/otn-pub/jcp/jbi-1.0-fr-oth-JSpec/jbi-1_0-fr-spec.pdf

http://download.oracle.com/otn-pub/jcp/jbi-1.0-fr-oth-JSpec/jbi-1_0-fr-spec.pdf

http://bertrand.guiral.free.fr/jee/soa-jbi.html


Pratique Travaillant beaucoup avec la technologie WCF (Windows Communication Fundation), notamment lors de mon emploie de développeur, je trouve beaucoup de similitudes entre celle-ci, et les standards SCA. Nous allons voir comment grâce à ces concepts, nous pouvons rendre interopérable un service développé en .NET, avec une application J2EE, en passant par un fichier de configuration déclarant un binding (moyen de communication) standard : SOAP. Les codes sources présentés ont été développé dans le cadre d’un projet réel, par conséquent je n’en présenterai que des extraits, et n’exposerai pas les fonctionnalités métiers du client. Première étape : Déclaration du contrat de service. Le contrat de service en WCF, comme spécifié dans SCA, est sous forme d’une interface objet. Dans le cas où nous souhaitons invoquer ce service depuis une autre application WCF, cette interface sera copiée dans celle-ci, et par l’intermédiaire des mécanismes de « binding » proposés par la technologie, nous pourrons utiliser l’interface dans notre application, et voir son implémentation s’exécuter dans notre service. Interface C# : [ServiceContract] public interface IMusteringClient { [OperationContract] bool setServerName(String serverName); }

Implémentation de l’interface dans le service C# : [ServiceBehavior] public class MusteringClientService : IMusteringClient { /// <summary> /// Set ServerName /// </summary> /// <param name="serverName"></param> /// <returns></returns> public bool setServerName(string serverName) { //Implémentation // […] return true; } }


Deuxième étape : Nous souhaitons utiliser notre service depuis une application utilisant une autre technologie. La deuxième étape consiste donc à configurer notre service en déclarant un « binding » standard : SOAP Extrait du fichier de configuration XML : <endpoint address="http://localhost:8000/MusteringClientService" binding="basicHttpBinding" contract="AltairMustering.IMusteringClient" bindingConfiguration="higherMessageSize"> </endpoint>

Trois informations sont indiquées dans les configurations :

L’URL qui sert de point d’entrée pour les appels de notre service : ici http://localhost:8000/MusteringClientService

le « binding » à utiliser, ici basicHttpBinding signifie que le service sera exposé en SOAP.

Le contrat de service à exposer : L’interface décrivant les fonctionnalités disponibles.

A cette étape, si nous interrogeons l’URL déclarée par le biais d’un navigateur internet, nous obtenons un contrat WSDL généré par la plateforme. Troisième étape : Appel du Web Service qui encapsule la fonctionnalité souhaitée. J’ai utilisé la librairie Axis2 de la fondation Apache. Après avoir référencé le Web Service dans l’environnement de développement, la librairie a généré des objets (Les « stubs ») permettant d’invoquer les fonctionnalités souhaitées. Invocation du service en Java grâce aux objets générés : MusteringClientServiceStub client = new MusteringClientServiceStub("http://10.27.84.50:8000/MusteringClientService"); MusteringClientServiceStub.SetServerName server = new MusteringClientServiceStub.SetServerName(); server.setServerName("Nom du serveur"); client.setServerName(server); client.cleanup();

Nous venons de déclarer une fonction dans un environnement C# .NET, et avons utilisé cette fonction depuis un environnement Java, sans se soucier dans le code source, de quel moyen de communications sera utilisés pour véhiculer l’information.


Conclusion

L’objectif de cette étude était de répondre à la nécessité de normalisation des « Entreprise Service Bus ». Ma première impression lorsque j’ai commencé mes recherches, était que chaque éditeurs avait sa définition du terme, et qu’aucun d’eux ne respectait les mêmes concepts. Aucune norme ne spécifie effectivement le terme ESB, pourtant très utilisé dans le milieu des architectures SOA (Service Oriented Architecture), cependant ces travaux ont étés réalisés sur les concepts que nous retrouvons dans la plupart des ESB du marché. Il s’agit des standards SCA de OASIS (Organization for the Advancement of Structured Information Standards), et JBI du Java Community Process. Ces deux standards ne sont pas des technologies, bien que JBI soit orientée Java, mais des pratique architecturale (Design Pattern) qu’il est possible d’implémenter par tout éditeurs de logiciels. Je pense que la meilleure définition que nous puissions trouver pour ESB est la spécification SCA., en effet bien que la norme n’aborde que très peu la notion de « bus », les concepts de « bus logiciels » présentés dans ce mémoire se rapprochent fortement de ce qu’elle spécifie. En conclusions, nous pouvons affirmer que les éditeurs de solutions ESB se distingues en deux écoles : Ceux qui font partie de OASIS, éditeurs de solutions propriétaires, et ceux qui font parti de JCA, souvent des éditeurs de logiciels open sources.


Lexique

Abréviations Description

B2B Business to Business

CORBA Common Object Request Broker Architecture

DCE Distributed Computing Environment

DCOM Distributed Component Object Model

EAI Entreprise Application Integration

ESB Entreprise Service Bus

FTP File Transfer Protocol

GIOP General Inter-ORB Protocol

http Hypertext Transfer Protocol

IDL Interface Definition Language

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IIOP Internet Inter-ORB Protocol

ISO International Organization for Standardization

JMS Java Message Service

MAC Media Access Control

MS Microsoft

MSMQ Microsoft Message Queuing

NTIC Nouvelles Technologies de l’Information et de la Communication

OMG Object Management Group

ORB Object Request Broker

ORPC Object Remote Procedure Call

OSI Open Systems Interconnection

RPC Remote Procedure Call

RS-232, 422 Recommended Standard …

SI Système d’Information

SMTP Simple Mail Transfer Protocol

SOAP Simple Object Access Protocol

SOF Start Of Frame

SPOF Single Point Of Failure

TCP Transmission Control Protocol

TIC Technologie de l’Information et de la Communication

URL Uniform Resource Locator

USB Universal Serial Bus

W3C World Wide Web Consortium

WCF Windows Communication Fundation

WS-* Normes de la familles des Web Services

WSDL Web Services Description Language

XML Extensible Markup Language

XSD XML Schema Definition

Documents

CAHIER DES CHARGES - spirit182.free.frspirit182.free.fr/These-ESB-Benjamin-LINIER-rev1.pdf · 3 Exia.Cesi Benjamin LINIER Introduction Etudiant en 5ème année Management et Architecture