Exia.Cesi Année Des bus de terrains, aux bus logiciels : Les «Entreprise Services Bus» (ESB) THESE. Écrit par :

Dimension: px
Commencer à balayer dès la page:

Download "Exia.Cesi Année 2011-2012. Des bus de terrains, aux bus logiciels : Les «Entreprise Services Bus» (ESB) THESE. Écrit par :"

Transcription

1 Exia.Cesi Année Des bus de terrains, aux bus logiciels : Les «Entreprise Services Bus» (ESB) THESE Écrit par : Né le 9 avril 1986 À PAU

2 Sommaire SOMMAIRE... 2 INTRODUCTION... 3 ÉTAT DE L ART PERIMETRE UN SYSTEME EN COUCHES : LE MODELE OSI COUCHE PHYSIQUE : «LES BUS MATERIELS»... 7 CARACTERISTIQUES D UN BUS... 7 EXEMPLES DE BUS TOPOLOGIE DES RESEAUX TOPOLOGIE EN BUS TOPOLOGIE EN ETOILE (HUB AND SPOKE) COUCHE APPLICATION : «LES BUS LOGICIELS» LES MIDDLEWARES LES ESB (ENTREPRISE SERVICE BUS) BIBLIOGRAPHIE PROBLEMATIQUE QUELS SONT LES CONCEPTS CLES? DEPLOIEMENT SUR UN SERVEUR D APPLICATION CONTRAT DE SERVICE TRANSFORMATION DES MESSAGES TRANSFORMATION DES DONNEES PROTOCOLE DE TRANSPORT STANDARD ROUTAGE INTELLIGENT ARCHITECTURE «NETWORK CENTRIC» DIFFERENTES TECHNOLOGIES CORBA DCE DCOM WCF OPENESB / GLASSFISHESB PETALS ESB NORMALISATIONS SCA (SERVICE COMPONENT ARCHITECTURE) JBI (JAVA BUSINESS INTEGRATION) PRATIQUE CONCLUSION LEXIQUE Exia.Cesi

3 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? 3 Exia.Cesi

4 É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. 4 Exia.Cesi

5 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. 5 Exia.Cesi

6 Ci-dessous un schéma qui représente les sept couches du modèle OSI : Application Application Interface couche 7/6 Interface couche 7/6 Présentation Présentation Interface couche 6/5 Interface couche 6/5 Session Session Interface couche 5/4 Interface couche 5/4 Transport Transport Interface couche 4/3 Interface couche 4/3 Réseau Réseau Interface couche 3/2 Interface couche 3/2 Liaison Liaison Interface couche 2/1 Interface couche 2/1 Physique Physique Figure 1 : Modèle OSI 6 Exia.Cesi

7 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écepteur Figure 2 : liaison série Schématisation d une liaison parallèle transmettant la même donnée sur 8 fils : Émetteur Récepteur Figure 3 : liaison parallèle 7 Exia.Cesi

8 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. Equipement 1 Equipement 2 Emission Réception Réception Emission 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. 8 Exia.Cesi

9 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 : Voici les quatre fils schématisés, d une liaison USB : Longueur max : 5m Equipement 1 VBus D + Equipement 2 D - GND 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. 9 Exia.Cesi

10 Ci-dessous, une illustration du site internet 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 fullduplex. 10 Exia.Cesi

11 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 11 Exia.Cesi

12 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 ceuxci 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 Checksum 2 (32bits). Figure 8 : Trame Ethernet Source de l image : Wikipedia - 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. 12 Exia.Cesi

13 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 : Bus 10 BASE-T ou 100 BASE-TX Commutateur 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. 13 Exia.Cesi

14 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 2 Application 1 Middleware Application 3 Application 4 Figure 10 : Middleware Hub and Spoke 14 Exia.Cesi

15 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é 15 Exia.Cesi

16 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. 16 Exia.Cesi

17 6 Bibliographie Livre blanc : Bus de services -ESB- Nouvelle technologie pour l intégration Adrien LOUIS, Novembre 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 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 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 17 Exia.Cesi

18 é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 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. 18 Exia.Cesi

19 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, 19 Exia.Cesi

20 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; typedef sequence<nom> DesNoms; // Nom d une personne // Ensemble de noms struct Personne { Nom nom; string telephone; string ; }; interface Repertoire { // Description d une personne // - son nom // - numéro de téléphone // - adresse // 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. 20 Exia.Cesi

21 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> 21 Exia.Cesi

22 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é Messages XML Fichier Adapteur XML ESB Transformation Adapteur Fichier 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, , 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, 22 Exia.Cesi

23 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 : 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 : 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 23 Exia.Cesi

24 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 Mail WS-* JMS MSMQ TCP XMPP FTP GIOP Requêtes et réponses http Envoie et Réception d s Protocoles de la famille des WebServices Java Message System Microsoft Message Queuing Requêtes TCP Envois/Ecoute de messages sur réseaux XMPP File Transfer Protocol Général Inter Orb Protocol (CORBA) 24 Exia.Cesi

25 Application Service exposé Messages XML Fichier Adapteur XML ESB Adapteur 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. 25 Exia.Cesi

26 Service A Service B ESB Message Application Service C 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é). Service A Service B ESB Reroutage Message Application Service C Figure 15 : Routage Haute Disponibilité Router des messages en fonction de leur contenu. Router des messages simultanément vers plusieurs services. (multicast). 26 Exia.Cesi

27 Service A Service B ESB Message Application Service C 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. Application Externe Internet Service «Facade» Service A Message ESB Interne Figure 17 : Routage par un point d entrée unique. Service B Utiliser des protocoles différents pour un même service en proposant plusieurs points d entrées. Application Message ESB Tcp://serveur1:5555/endpoint2 Ftp://serveur1:5555/endpoint3 Service Figure 18 : Liaison à plusieurs points de terminaisons 27 Exia.Cesi

28 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. Service A EAI Message Application Service B 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. 28 Exia.Cesi

29 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. Service A ESB ESB Application Message ESB Service B Figure 20 : Solution ESB distribuée Source : 29 Exia.Cesi

30 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. 30 Exia.Cesi

31 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 : 31 Exia.Cesi

32 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. 32 Exia.Cesi

33 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é. 33 Exia.Cesi

34 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 : 34 Exia.Cesi

35 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». 35 Exia.Cesi

36 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 : %20SCA.pdf 36 Exia.Cesi

37 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 : %20SCA.pdf 37 Exia.Cesi

38 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 : 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 : 38 Exia.Cesi

39 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; } } 39 Exia.Cesi

40 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 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:// :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. 40 Exia.Cesi

41 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. 41 Exia.Cesi

42 Lexique Abréviations B2B CORBA DCE DCOM EAI ESB FTP GIOP http IDL IEEE IETF IIOP ISO JMS MAC MS MSMQ NTIC OMG ORB ORPC OSI RPC RS-232, 422 SI SMTP SOAP SOF SPOF TCP TIC URL USB W3C WCF WS-* WSDL XML XSD Description Business to Business Common Object Request Broker Architecture Distributed Computing Environment Distributed Component Object Model Entreprise Application Integration Entreprise Service Bus File Transfer Protocol General Inter-ORB Protocol Hypertext Transfer Protocol Interface Definition Language Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Inter-ORB Protocol International Organization for Standardization Java Message Service Media Access Control Microsoft Microsoft Message Queuing Nouvelles Technologies de l Information et de la Communication Object Management Group Object Request Broker Object Remote Procedure Call Open Systems Interconnection Remote Procedure Call Recommended Standard Système d Information Simple Mail Transfer Protocol Simple Object Access Protocol Start Of Frame Single Point Of Failure Transmission Control Protocol Technologie de l Information et de la Communication Uniform Resource Locator Universal Serial Bus World Wide Web Consortium Windows Communication Fundation Normes de la familles des Web Services Web Services Description Language Extensible Markup Language XML Schema Definition 42 Exia.Cesi

Urbanisme du Système d Information et EAI

Urbanisme du Système d Information et EAI Urbanisme du Système d Information et EAI 1 Sommaire Les besoins des entreprises Élément de solution : l urbanisme EAI : des outils au service de l urbanisme 2 Les besoins des entreprises 3 Le constat

Plus en détail

Figure 1-1. Plateformes compatibles avec WCF

Figure 1-1. Plateformes compatibles avec WCF 1 Bonjour Indigo Windows Communication Foundation (WCF), auparavant connu sous le nom de code «Indigo», est une nouvelle plateforme de messages distribués. Il fait partie du Framework.NET 3.0 livré avec

Plus en détail

Nouvelles technologies pour l intégration : les ESB

Nouvelles technologies pour l intégration : les ESB 10, avenue de l Europe Parc Technologique du Canal 31520 Ramonville st Agne 05.61.28.56.20 05.61.28.56.00 www.ebmwebsourcing.com Nouvelles technologies pour l intégration : les ESB EBM Websourcing Sommaire

Plus en détail

Les Architectures Orientées Services (SOA)

Les Architectures Orientées Services (SOA) Les Architectures Orientées Services (SOA) Ulrich Duvent Guillaume Ansel Université du Littoral Côte d Opale 50, Rue Ferdinand Buisson BP 699 62228 Calais Cedex Téléphone (33) 03.21.46.36.92 Télécopie

Plus en détail

Programmation d applications distribuées

Programmation d applications distribuées Programmation d applications distribuées François Charoy Université Henri Poincaré 8 octobre 2007 Première partie I Développement d applications distribuées Objectifs du cours Comprendre ce qu est une

Plus en détail

Introduction aux «Services Web»

Introduction aux «Services Web» Introduction aux «Services Web» Sana Sellami sana.sellami@univ-amu.fr 2014-2015 Modalité de contrôle de connaissances Note de contrôle de continu Note projet Evaluation du projet la semaine du 17 novembre

Plus en détail

Cours Master Recherche RI 7 Extraction et Intégration d'information du Web «Services Web»

Cours Master Recherche RI 7 Extraction et Intégration d'information du Web «Services Web» Cours Master Recherche RI 7 Extraction et Intégration d'information du Web «Services Web» Sana Sellami sana.sellami@lsis.org 2014-2015 Plan Partie 1: Introduction aux Services Web (SW) Partie 2: Vers une

Plus en détail

DIFF DE BASE. Serendip serendip@via.ecp.fr. Samy samy@via.ecp.fr

DIFF DE BASE. Serendip serendip@via.ecp.fr. Samy samy@via.ecp.fr DIFF DE BASE Serendip serendip@via.ecp.fr Samy samy@via.ecp.fr I. INTRODUCTION AU RÉSEAU RÉSEAU : /ʁE.ZO/ N.M. DÉR., AU MOYEN DU SUFF. -EAU, DE L'A. FR. REIZ, REZ «FILET» (RETS); RÉSEAU A ÉTÉ EN CONCURRENCE

Plus en détail

NFP111 Systèmes et Applications Réparties

NFP111 Systèmes et Applications Réparties NFP111 Systèmes et Applications Réparties 1 de 46 NFP111 Systèmes et Applications Réparties Cours 2 - Les appels de procédure distants (Partie 1) Claude Duvallet Université du Havre UFR Sciences et Techniques

Plus en détail

Introduction aux Systèmes Distribués. Introduction générale

Introduction aux Systèmes Distribués. Introduction générale Introduction aux Systèmes Distribués Licence Informatique 3 ème année Introduction générale Eric Cariou Université de Pau et des Pays de l'adour Département Informatique Eric.Cariou@univ-pau.fr 1 Plan

Plus en détail

Urbanisation des Systèmes d'information

Urbanisation des Systèmes d'information Urbanisation des Systèmes d'information Des composants technologiques disponibles Urbanisation des Systèmes d'information - Henry Boccon-Gibod 1 Plan de l'exposé Technologies à la mode disponibles. Bus

Plus en détail

Administration des ressources informatiques

Administration des ressources informatiques 1 2 Cours réseau Supports de transmission Les câbles Coaxial Ethernet RJ45 Fibre optique Supports de transmission 3 Les câbles Ethernet RJ45 Supports de transmission 4 Les câbles Coaxial Type BNC Cours

Plus en détail

CHAPITRE 1. Introduction aux web services. 1.1 Définition. Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C#

CHAPITRE 1. Introduction aux web services. 1.1 Définition. Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C# CHAPITRE 1 Introduction aux web services Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C# NetBeans JavaScript Eclipse Objective C Xcode PHP HTML Objectifs du chapitre : Ce

Plus en détail

Cours CCNA 1. Exercices

Cours CCNA 1. Exercices Cours CCNA 1 TD3 Exercices Exercice 1 Enumérez les sept étapes du processus consistant à convertir les communications de l utilisateur en données. 1. L utilisateur entre les données via une interface matérielle.

Plus en détail

Urbanisation des SI. Des composants technologiques disponibles. Urbanisation des Systèmes d'information Henry Boccon Gibod 1

Urbanisation des SI. Des composants technologiques disponibles. Urbanisation des Systèmes d'information Henry Boccon Gibod 1 Urbanisation des SI Des composants technologiques disponibles Urbanisation des Systèmes d'information Henry Boccon Gibod 1 Plan de l'exposé Technologies à la mode disponibles. Bus de données, ETL et EAI

Plus en détail

BPEL Orchestration de Web Services

BPEL Orchestration de Web Services Orchestration de Web Services Grégory Le Bonniec gregory.lebonniec@zenika.com 26 novembre 2009 1 Zenika Conseil / Développement / Formation Localisation : Paris et Rennes Nos partenaires Mon expérience

Plus en détail

OpenESB Libre, standard, outillé, documenté et supporté

OpenESB Libre, standard, outillé, documenté et supporté OpenESB Libre, standard, outillé, documenté et supporté Alexis Moussine-Pouchkine Sun Microsystems, Inc. Constat Les projets d'intégration sont mono-éditeur Est-ce viable à long terme? Quel(s) Standard(s)

Plus en détail

Ch2 La modélisation théorique du réseau : OSI Dernière maj : jeudi 12 juillet 2007

Ch2 La modélisation théorique du réseau : OSI Dernière maj : jeudi 12 juillet 2007 Ch2 La modélisation théorique du réseau : OSI Dernière maj : jeudi 12 juillet 2007 I. LA NORMALISATION... 1 A. NORMES... 1 B. PROTOCOLES... 2 C. TECHNOLOGIES RESEAU... 2 II. LES ORGANISMES DE NORMALISATION...

Plus en détail

CORBA. (Common Request Broker Architecture)

CORBA. (Common Request Broker Architecture) CORBA (Common Request Broker Architecture) Projet MIAGe Toulouse Groupe 2 1 CORBA, introduction (1/4) Les systèmes répartis permettent de créer des applications basées sur des composants auto-gérables,

Plus en détail

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base SOA et Services Web 23 octobre 2011 1 SOA: Concepts de base 2 Du client serveur à la SOA N est Nest pas une démarche entièrement nouvelle: années 1990 avec les solutions C/S Besoins d ouverture et d interopérabilité

Plus en détail

LA COMMUNICATION DE L INFORMATION EN RESEAUX

LA COMMUNICATION DE L INFORMATION EN RESEAUX LA COMMUNICATION DE L INFORMATION EN RESEAUX A LES RESEAUX Un réseau est un ensemble d objets connectés entre eux. Il permet de faire circuler un certain nombre d information entre ces objets selon des

Plus en détail

La démarche SOA et l interopérabilité applicative

La démarche SOA et l interopérabilité applicative La démarche SOA et l interopérabilité applicative Retour d'expérience des projets RITA / PRESTO de la Direction Générale de la Modernisation de l'état Abdelaziz Skalli Consultant Tél : +33.630.78.54.75

Plus en détail

NFP111 Systèmes et Applications Réparties

NFP111 Systèmes et Applications Réparties NFP111 Systèmes et Applications Réparties 1 de 34 NFP111 Systèmes et Applications Réparties Cours 7 - CORBA/Partie 1 Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon

Plus en détail

Chapitre VIII : Introduction aux réseaux. Motivations. Notion de système distribué. Motivations Différents types de SE

Chapitre VIII : Introduction aux réseaux. Motivations. Notion de système distribué. Motivations Différents types de SE Chapitre VIII : Introduction aux réseaux Eric.Leclercq@u-bourgogne.fr Département IEM http://ufrsciencestech.u-bourgogne.fr http://ludique.u-bourgogne.fr/~leclercq 4 mai 2006 1 Structures de Systèmes distribués

Plus en détail

Conception Exécution Interopérabilité. Déploiement. Conception du service. Définition du SLA. Suivi du service. Réception des mesures

Conception Exécution Interopérabilité. Déploiement. Conception du service. Définition du SLA. Suivi du service. Réception des mesures Software propose une offre d intégration unique, qui apporte l équilibre parfait entre investissements et performances pour les entreprises qui doivent sans cesse améliorer leurs processus. Des caractéristiques

Plus en détail

Cisco Certified Network Associate

Cisco Certified Network Associate Cisco Certified Network Associate Version 4 Notions de base sur les réseaux Chapitre 9 01 Convertissez le nombre binaire 10111010 en son équivalent hexadécimal. Sélectionnez la réponse correcte dans la

Plus en détail

1 Introduction aux réseaux Concepts généraux

1 Introduction aux réseaux Concepts généraux Plan 2/40 1 Introduction aux réseaux Concepts généraux Réseaux IUT de Villetaneuse Département Informatique, Formation Continue Année 2012 2013 http://www.lipn.univ-paris13.fr/~evangelista/cours/2012-2013/reseaux-fc

Plus en détail

Chapitre 5 CORBA (Common Object Request Broker Architecture)

Chapitre 5 CORBA (Common Object Request Broker Architecture) DÉVELOPPEMENT D APPLICATIONS RÉPARTIES CORBA (Common Object Request Broker Architecture) Amen Ben Hadj Ali amenbha@hotmail.com ISI-L3SIL 2011-2012 Plan 2 Architecture CORBA Le langage IDL CORBA en Java

Plus en détail

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free.

2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES. 2.2 Architecture fonctionnelle d un système communicant. http://robert.cireddu.free. 2. MAQUETTAGE DES SOLUTIONS CONSTRUCTIVES 2.2 Architecture fonctionnelle d un système communicant Page:1/11 http://robert.cireddu.free.fr/sin LES DÉFENSES Objectifs du COURS : Ce cours traitera essentiellement

Plus en détail

Plan du Travail. 2014/2015 Cours TIC - 1ère année MI 30

Plan du Travail. 2014/2015 Cours TIC - 1ère année MI 30 Plan du Travail Chapitre 1: Internet et le Web : Définitions et historique Chapitre 2: Principes d Internet Chapitre 3 : Principaux services d Internet Chapitre 4 : Introduction au langage HTML 2014/2015

Plus en détail

Introduction aux. services web 2 / 2

Introduction aux. services web 2 / 2 Introduction aux services web 2 / 2 1 Calendrier 2 x CM A 107 mercredi 7 janvier 2015, 08 h 00 10 h 00 : introduction sur la théorie des services web mercredi 28 janvier 2015, 08 h 00 10 h 00 : introduction

Plus en détail

Cours des réseaux Informatiques (2010-2011)

Cours des réseaux Informatiques (2010-2011) Cours des réseaux Informatiques (2010-2011) Rziza Mohammed rziza@fsr.ac.ma Supports Andrew Tanenbaum : Réseaux, cours et exercices. Pascal Nicolas : cours des réseaux Informatiques, université d Angers.

Plus en détail

NOTIONS DE RESEAUX INFORMATIQUES

NOTIONS DE RESEAUX INFORMATIQUES NOTIONS DE RESEAUX INFORMATIQUES GENERALITES Définition d'un réseau Un réseau informatique est un ensemble d'équipements reliés entre eux afin de partager des données, des ressources et d'échanger des

Plus en détail

Cisco Certified Network Associate

Cisco Certified Network Associate Cisco Certified Network Associate Version 4 Notions de base sur les réseaux Chapitre 3 01 Quel protocole de la couche application sert couramment à prendre en charge les transferts de fichiers entre un

Plus en détail

Master 2 MIAGE NTDP Nom : Le Prof! UE «Web Services et SOA», Prénom

Master 2 MIAGE NTDP Nom : Le Prof! UE «Web Services et SOA», Prénom Master 2 MIAGE NTDP Nom : Le Prof! UE «Web Services et SOA», Prénom Epreuve écrite individuelle 8 Décembre 2008, durée 45 mns Aucun document autorisé => Finalement, autorisés et semble-t-il utiles!!...

Plus en détail

Master d'informatique 1ère année Réseaux et protocoles. Couche physique

Master d'informatique 1ère année Réseaux et protocoles. Couche physique Master d'informatique 1ère année Réseaux et protocoles Couche physique Bureau S3-354 Mailto:Jean.Saquet@unicaen.fr http://saquet.users.greyc.fr/m1/rezopro Supports de communication Quelques exemples :

Plus en détail

Business & High Technology

Business & High Technology UNIVERSITE DE TUNIS INSTITUT SUPERIEUR DE GESTION DE TUNIS Département : Informatique Business & High Technology Chapitre 3 : Progiciels de Gestion Intégrés Sommaire Définition... 2 ERP... 2 Objectifs

Plus en détail

Informatique Générale. Partie 3 - TD Les réseaux. Travaux dirigés associés au CM 3. Informatique, G. KEMBELLEC

Informatique Générale. Partie 3 - TD Les réseaux. Travaux dirigés associés au CM 3. Informatique, G. KEMBELLEC Informatique Générale Partie 3 - TD Les réseaux Travaux dirigés associés au CM 3 1 Chef de projet en ingénierie documentaire Les réseaux et internet Travaux dirigés 2 Réseaux locaux, étendus, Internet

Plus en détail

Réalisation d un serveur CTI-CSTA sur TCP/IP

Réalisation d un serveur CTI-CSTA sur TCP/IP Alcôve http://www.alcove.fr 1/28 Réalisation d un serveur CTI-CSTA sur TCP/IP Julien Gaulmin Cette présentation est librement diffusable sous les termes de la GNU Free Documentation

Plus en détail

Intégration de systèmes

Intégration de systèmes Intégration de systèmes Préparé par: Marc Barassi, Michel Fraser, Louis Martin, Martin Simoneau Collaboration spéciale: François Boucher et Richard Boutin 3/18/14 Intégration de systèmes «L ensemble des

Plus en détail

Messagerie asynchrone et Services Web

Messagerie asynchrone et Services Web Article Messagerie asynchrone et Services Web 1 / 10 Messagerie asynchrone et Services Web SOAP, WSDL SONT DES STANDARDS EMERGEANT DES SERVICES WEB, LES IMPLEMENTATIONS DE CEUX-CI SONT ENCORE EN COURS

Plus en détail

1.Introduction - Modèle en couches - OSI TCP/IP

1.Introduction - Modèle en couches - OSI TCP/IP 1.Introduction - Modèle en couches - OSI TCP/IP 1.1 Introduction 1.2 Modèle en couches 1.3 Le modèle OSI 1.4 L architecture TCP/IP 1.1 Introduction Réseau Télécom - Téléinformatique? Réseau : Ensemble

Plus en détail

Mise en œuvre des serveurs d application

Mise en œuvre des serveurs d application Nancy-Université Mise en œuvre des serveurs d application UE 203d Master 1 IST-IE Printemps 2008 Master 1 IST-IE : Mise en œuvre des serveurs d application 1/54 Ces transparents, ainsi que les énoncés

Plus en détail

Chap.1: Introduction à la téléinformatique

Chap.1: Introduction à la téléinformatique Chap.1: Introduction à la téléinformatique 1. Présentation 2. les caractéristiques d un réseau 3. les types de communication 4. le modèle OSI (Open System Interconnection) 5. l architecture TCP/IP 6. l

Plus en détail

CORBA avec OpenORB. Samir Torki et Patrice Torguet

CORBA avec OpenORB. Samir Torki et Patrice Torguet CORBA avec OpenORB Samir Torki et Patrice Torguet 1 Présentation de CORBA CORBA (Common Object Request Broker Architecture) est un standard décrivant une architecture pour la mise en place d objets distribués.

Plus en détail

Référence Etnic Architecture des applications

Référence Etnic Architecture des applications Référence Etnic Architecture des applications Table des matières 1. Introduction... 2 2. Architecture... 2 2.1 Démarche générale... 2 2.2 Modèle d architecture... 3 2.3 Découpe d une architecture applicative...

Plus en détail

Services Web. Fabrice Rossi. http://apiacoa.org/contact.html. Université Paris-IX Dauphine. Services Web p.1/26

Services Web. Fabrice Rossi. http://apiacoa.org/contact.html. Université Paris-IX Dauphine. Services Web p.1/26 Services Web Fabrice Rossi http://apiacoa.org/contact.html. Université Paris-IX Dauphine Services Web p.1/26 Plan du cours 1. Introduction 2. SOAP 3. WSDL 4. UDDI Site du cours : http://apiacoa.org/teaching/webservices/

Plus en détail

Les Enterprise Service Bus. Amine Slimane

Les Enterprise Service Bus. Amine Slimane Les Enterprise Service Bus Amine Slimane 1 Plan de la présentation Principes de la SOA Principe d un ESB Fonctionnement interne d un ESB L intégration d un ESB au travers d un exemple concret Conclusion

Plus en détail

SOA et Services Web. 23 octobre 2011. Evolution des Systèmes d Information

SOA et Services Web. 23 octobre 2011. Evolution des Systèmes d Information SOA et Services Web 23 octobre 2011 1 Evolution des Systèmes d Information 2 Qu est ce qu une application répartie? Il s agit d une application découpée en plusieurs unités Chaque unité peut être placée

Plus en détail

Introduction aux Technologies de l Internet

Introduction aux Technologies de l Internet Introduction aux Technologies de l Internet Antoine Vernois Université Blaise Pascal Cours 2006/2007 Introduction aux Technologies de l Internet 1 Au programme... Généralités & Histoire Derrière Internet

Plus en détail

Les nouvelles architectures des SI : Etat de l Art

Les nouvelles architectures des SI : Etat de l Art Les nouvelles architectures des SI : Etat de l Art Objectif Mesurer concrètement les apports des nouvelles applications SI. Être capable d'évaluer l'accroissement de la complexité des applications. Prendre

Plus en détail

Business & High Technology

Business & High Technology UNIVERSITE DE TUNIS INSTITUT SUPERIEUR DE GESTION DE TUNIS Département : Informatique Business & High Technology Chapitre 4 : Web Service Sommaire Introduction... 1 Web Service... 1 Les technologies des

Plus en détail

Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui

Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui Formation PARTIE 1 : ARCHITECTURE APPLICATIVE DUREE : 5 h Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui automatisent les fonctions Définir une architecture

Plus en détail

ETUDE COMPARATIVE DES SERVICES DE RECHERCHE SUR PROPRIETES

ETUDE COMPARATIVE DES SERVICES DE RECHERCHE SUR PROPRIETES ETUDE COMPARATIVE DES SERVICES DE RECHERCHE SUR PROPRIETES Dhouha Ayed, Chantal Taconet et Guy Bernard GET / INT, CNRS Samovar 9 rue Charles Fourier, 91011 Évry, France {Dhouha.Ayed, Chantal.Taconet, Guy.Bernard}@int-evry.fr

Plus en détail

Principes. 2A-SI 3 Prog. réseau et systèmes distribués 3. 3 Programmation en CORBA. Programmation en Corba. Stéphane Vialle

Principes. 2A-SI 3 Prog. réseau et systèmes distribués 3. 3 Programmation en CORBA. Programmation en Corba. Stéphane Vialle 2A-SI 3 Prog. réseau et systèmes distribués 3. 3 Programmation en CORBA Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle 1 Principes 2 Architecture 3 4 Aperçu d utilisation

Plus en détail

Le cadre des Web Services Partie 1 : Introduction

Le cadre des Web Services Partie 1 : Introduction Sécurité en ingénierie du Logiciel Le cadre des Web Services Partie 1 : Introduction Alexandre Dulaunoy adulau@foo.be Sécurité en ingénierie du Logiciel p.1/21 Agenda (partie 1) 1/2 Introduction Services

Plus en détail

M2 MIAGE EVRY RAPPORT DE PROJET TECHNOLOGIE SCA

M2 MIAGE EVRY RAPPORT DE PROJET TECHNOLOGIE SCA M2 MIAGE EVRY RAPPORT DE PROJET TECHNOLOGIE SCA Matière : Architecture orientée service Enseignants : Boccon-Gibod, Godefroy Étudiants : DIALLO Amadou Tidiane GOLAB Barbara 1 IDENTIFICATION DU PROJET Projet

Plus en détail

Plan. Programmation Internet Cours 3. Organismes de standardisation

Plan. Programmation Internet Cours 3. Organismes de standardisation Plan Programmation Internet Cours 3 Kim Nguy ên http://www.lri.fr/~kn 1. Système d exploitation 2. Réseau et Internet 2.1 Principes des réseaux 2.2 TCP/IP 2.3 Adresses, routage, DNS 30 septembre 2013 1

Plus en détail

Institut Supérieur de Gestion. Cours pour 3 ème LFIG. Java Enterprise Edition Introduction Bayoudhi Chaouki

Institut Supérieur de Gestion. Cours pour 3 ème LFIG. Java Enterprise Edition Introduction Bayoudhi Chaouki Institut Supérieur de Gestion Cours pour 3 ème LFIG Java Enterprise Edition Introduction Bayoudhi Chaouki 1 Java EE - Objectifs Faciliter le développement de nouvelles applications à base de composants

Plus en détail

Réseaux et Télécommunication Interconnexion des Réseaux

Réseaux et Télécommunication Interconnexion des Réseaux Réseaux et Télécommunication Interconnexion des Réseaux 1 Concevoir un réseau Faire évoluer l existant Réfléchir à toutes les couches Utiliser les services des opérateurs (sous-traitance) Assemblage de

Plus en détail

Cisco Certified Network Associate, CCNA

Cisco Certified Network Associate, CCNA 1 Cisco Certified Network Associate, CCNA Céline OULMI ESGI AutoQoS Technical Presentation, 1/03 2002, Cisco Systems, Inc. All rights reserved. 2 CCNA Exploration Version4 Académie ESGI Paris 19/10/2012

Plus en détail

Chapitre VII : Principes des réseaux. Structure des réseaux Types de réseaux La communication Les protocoles de communication

Chapitre VII : Principes des réseaux. Structure des réseaux Types de réseaux La communication Les protocoles de communication Chapitre VII : Principes des réseaux Structure des réseaux Types de réseaux La communication Les protocoles de communication Introduction Un système réparti est une collection de processeurs (ou machines)

Plus en détail

Plan. 1. Introduction. 1.1 Notion de réseau. Réseau extrémité. Le cœur du réseau. Les Protocoles de Télécommunications Evolution Internet Cours de DEA

Plan. 1. Introduction. 1.1 Notion de réseau. Réseau extrémité. Le cœur du réseau. Les Protocoles de Télécommunications Evolution Internet Cours de DEA Plan Les Protocoles de Télécommunications Evolution Internet Cours de DEA Isabelle CHRISMENT ichris@loria.fr Introduction Routage dans l Internet IPv6 Communication de groupes et l Internet x sans fils,

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Modélisation des réseaux : Le modèle OSI et ses dérivés

Modélisation des réseaux : Le modèle OSI et ses dérivés Chapitre 1 1 Modélisation des réseaux : Le modèle OSI et ses dérivés Le modèle OSI de l ISO 2 Le modèle d'interconnexion des Systèmes Ouverts (Open Systems Interconnection) a été proposé par l'iso (International

Plus en détail

Présentation d un projet du CATI SICPA : Le projet GAniMed

Présentation d un projet du CATI SICPA : Le projet GAniMed Présentation d un projet du : Le projet GAniMed Thierry HEIRMAN / Introduction : Un manque de communication inter-si Le département GA dispose d une culture SI depuis de nombreuses années : SI Métier :

Plus en détail

4. Les réseaux locaux

4. Les réseaux locaux 4. Les réseaux locaux 4.1 Types des réseaux 4.2 Modèle en couches et réseaux locaux 4.3 Topologie et câblage 4.4 Méthodes d accès au médium CSMA/CD Anneau à jeton Caractéristiques «Réseau» Réseau : ensemble

Plus en détail

BAC PRO Système Electronique Numérique. Nom : Le routage Date : LE ROUTAGE

BAC PRO Système Electronique Numérique. Nom : Le routage Date : LE ROUTAGE 1. Sommaire LE ROUTAGE 1. Sommaire... 1 2. Un routeur, pour quoi faire?... 1 3. Principe de fonctionnement du routage.... 2 4. Interfaces du routeur... 3 4.1. Côté LAN.... 3 4.2. Côté WAN.... 3 5. Table

Plus en détail

Figure 1. Structure répartie

Figure 1. Structure répartie Chapitre I: Applications Réparties et Middleware 1. Définition d une application répartie Une application répartie est constituée d un ensemble de processus (d objets, d agents, d acteurs) s exécutant

Plus en détail

Architectures n tiers Intergiciels à objets et services web

Architectures n tiers Intergiciels à objets et services web UMIN406 : thèmes abordés Architectures n tiers Intergiciels à objets et services web Clémentine Nebut LIRMM / Université de Montpellier 2 LIRMM Clementine.nebut@lirmm.fr 1 Distribution d objets Java RMI,.net

Plus en détail

LES RÉSEAUX I/ INTRODUCTION - LIAISON ENTRE DEUX POSTES

LES RÉSEAUX I/ INTRODUCTION - LIAISON ENTRE DEUX POSTES Page 1 LES RÉSEAUX I/ INTRODUCTION - LIAISON ENTRE DEUX POSTES Dès l'apparition des structures de traitement programmés, s'est fait ressentir le besoin de transmettre des informations numériques de manière

Plus en détail

Business Process Execution Language

Business Process Execution Language Business Process Execution Language Rapport du projet de systèmes distribués d information Markus Lindström 6 mai 2009 Motivation personnelle Le sujet que j ai retenu et présenté dans le cadre du cours

Plus en détail

Les Services Web. Jean-Pierre BORG EFORT http://www.efort.com

Les Services Web. Jean-Pierre BORG EFORT http://www.efort.com Les Services Web Jean-Pierre BORG EFORT http://www.efort.com 1 Introduction Un "Service Web" est une application logicielle à laquelle on peut accéder à distance à partir de différents langages basés sur

Plus en détail

OFFRE DE FORMATION L.M.D.

OFFRE DE FORMATION L.M.D. REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE MINISTERE DE L ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE OFFRE DE FORMATION L.M.D. MASTER PROFESSIONNEL ET ACADEMIQUE Systèmes d Information

Plus en détail

Ethernet Industriel. Composants d une Infrastructure Ethernet

Ethernet Industriel. Composants d une Infrastructure Ethernet Ethernet Industriel Composants d une Infrastructure Ethernet Ethernet C est quoi Ethernet? Ethernet est une méthode de transmission d un signal entre deux appareils ou plus sur un média partagé. Cela ne

Plus en détail

La S O A O pen S ource avec. Démos / Outils PEtALS

La S O A O pen S ource avec. Démos / Outils PEtALS La S O A O pen S ource avec Démos / Outils PEtALS Sept. 2007 La route vers la SOA Un ESB (Enterprise Service Bus) basé sur les standards Java, JBI et Web Services est une bonne technologie pour instancier

Plus en détail

Architectures n-tiers Intergiciels à objets et services web

Architectures n-tiers Intergiciels à objets et services web Plan pour aujourd hui Architectures n-tiers Intergiciels à objets et services web Clémentine Nebut Nebut LIRMM / Université de Montpellier 2 Clementine.nebut@lirmm.fr Introduction Architectures classiques

Plus en détail

Architecture JEE. Objectifs attendus. Serveurs d applications JEE. Architectures JEE Normes JEE. Systèmes distribués

Architecture JEE. Objectifs attendus. Serveurs d applications JEE. Architectures JEE Normes JEE. Systèmes distribués Architecture JEE. Objectifs attendus Serveurs d applications JEE Systèmes distribués Architectures JEE Normes JEE couches logicielles, n-tiers framework JEE et design patterns 2007/02/28 Eric Hébert.eheb@yahoo.fr

Plus en détail

IFIPS 5 / Nouvelles Architectures Logicielles Projet : Bus de web services avec «moteur» BPEL

IFIPS 5 / Nouvelles Architectures Logicielles Projet : Bus de web services avec «moteur» BPEL IFIPS 5 / Nouvelles Architectures Logicielles Projet : Bus de web services avec «moteur» BPEL Un bus de services Un bus de services (ESB) permet d assembler des web services existants, le résultat de cet

Plus en détail

Composants Logiciels. Le modèle de composant de CORBA. Plan

Composants Logiciels. Le modèle de composant de CORBA. Plan Composants Logiciels Christian Pérez Le modèle de composant de CORBA Année 2010-11 1 Plan Un rapide tour d horizon de CORBA 2 Introduction au modèle de composant de CORBA Définition de composants CORBA

Plus en détail

18 TCP Les protocoles de domaines d applications

18 TCP Les protocoles de domaines d applications 18 TCP Les protocoles de domaines d applications Objectifs 18.1 Introduction Connaître les différentes catégories d applications et de protocoles de domaines d applications. Connaître les principaux protocoles

Plus en détail

Systèmes d'informations historique et mutations

Systèmes d'informations historique et mutations Systèmes d'informations historique et mutations Christophe Turbout SAIC-CERTIC Université de Caen Basse-Normandie Systèmes d'informations : Historique et mutations - Christophe Turbout SAIC-CERTIC UCBN

Plus en détail

Présentation du modèle OSI(Open Systems Interconnection)

Présentation du modèle OSI(Open Systems Interconnection) Présentation du modèle OSI(Open Systems Interconnection) Les couches hautes: Responsables du traitement de l'information relative à la gestion des échanges entre systèmes informatiques. Couches basses:

Plus en détail

XML, PMML, SOAP. Rapport. EPITA SCIA Promo 2004 16 janvier 2003. Julien Lemoine Alexandre Thibault Nicolas Wiest-Million

XML, PMML, SOAP. Rapport. EPITA SCIA Promo 2004 16 janvier 2003. Julien Lemoine Alexandre Thibault Nicolas Wiest-Million XML, PMML, SOAP Rapport EPITA SCIA Promo 2004 16 janvier 2003 Julien Lemoine Alexandre Thibault Nicolas Wiest-Million i TABLE DES MATIÈRES Table des matières 1 XML 1 1.1 Présentation de XML.................................

Plus en détail

Architectures Orientées Services Version 2.0

Architectures Orientées Services Version 2.0 Architectures Orientées Services Version 2.0 Principes de base et tour d horizon o Premières définitions et avantages o Enterprise Service Bus (ESB) o Standards (c) Leuville Objects. Tous droits de traduction,

Plus en détail

Hainaut P. 2013 - www.coursonline.be 1

Hainaut P. 2013 - www.coursonline.be 1 Ethernet 802.3 But de cette présentation Le protocole Ethernet est le protocole de couche 2 (du modèle OSI) le plus utilisé actuellement, dans les réseaux locaux Il repose sur l emploi de matériel «Ethernet»

Plus en détail

Le modèle client-serveur

Le modèle client-serveur Le modèle client-serveur Olivier Aubert 1/24 Sources http://www.info.uqam.ca/~obaid/inf4481/a01/plan.htm 2/24 Historique architecture centralisée terminaux passifs (un seul OS, systèmes propriétaires)

Plus en détail

Transmissions série et parallèle

Transmissions série et parallèle 1. Introduction : Un signal numérique transmet généralement plusieurs digits binaires. Exemple : 01000001 ( huit bits). Dans une transmission numérique on peut envisager deux modes : les envoyer tous en

Plus en détail

II/ Le modèle OSI II.1/ Présentation du modèle OSI(Open Systems Interconnection)

II/ Le modèle OSI II.1/ Présentation du modèle OSI(Open Systems Interconnection) II/ Le modèle OSI II.1/ Présentation du modèle OSI(Open Systems Interconnection) II.2/ Description des couches 1&2 La couche physique s'occupe de la transmission des bits de façon brute sur un canal de

Plus en détail

Réseaux - Cours 4. IP : introduction et adressage. Cyril Pain-Barre. version du 18/2/2013. IUT Informatique Aix-en-Provence

Réseaux - Cours 4. IP : introduction et adressage. Cyril Pain-Barre. version du 18/2/2013. IUT Informatique Aix-en-Provence Réseaux - Cours 4 : introduction et adressage Cyril Pain-Barre IUT Informatique Aix-en-Provence version du 18/2/2013 1/34 Cyril Pain-Barre : introduction et adressage 1/26 TCP/ l architecture d Internet

Plus en détail

Services OSI. if G.Beuchot. Services Application Services Présentation - Session Services Transport - Réseaux - Liaison de Données - Physique

Services OSI. if G.Beuchot. Services Application Services Présentation - Session Services Transport - Réseaux - Liaison de Données - Physique Services OSI Services Application Services Présentation - Session Services Transport - Réseaux - Liaison de Données - Physique 59 SERVICES "APPLICATION" Architecture spécifique : ALS (Application Layer

Plus en détail

Présentation de l architecture CORBA

Présentation de l architecture CORBA Présentation de l architecture CORBA Common Object Request Broker Architecture Yves LALOUM Conseil Audit de Systèmes d information CISA ylaloum@advisehr.com 29/04/2003 1 1.Introduction Depuis 1989, une

Plus en détail

4. SERVICES WEB REST 46

4. SERVICES WEB REST 46 4. SERVICES WEB REST 46 REST REST acronyme de REpresentational State Transfert Concept introduit en 2000 dans la thèse de Roy FIELDING Est un style d architecture inspiré de l architecture WEB En 2010,

Plus en détail

Solutions de gestion de la sécurité Livre blanc

Solutions de gestion de la sécurité Livre blanc Solutions de gestion de la sécurité Livre blanc L intégration de la gestion des identités et des accès avec l authentification unique Objectif : Renforcer la politique de sécurité et améliorer la productivité

Plus en détail

EPREUVE OPTIONNELLE d INFORMATIQUE

EPREUVE OPTIONNELLE d INFORMATIQUE EPREUVE OPTIONNELLE d INFORMATIQUE A) QCM Les réponses au QCM doivent être portées directement sur la feuille de sujet de QCM. Ne pas omettre de faire figurer votre numéro de candidat sur cette feuille

Plus en détail

Administration des ressources informatiques

Administration des ressources informatiques 1 2 La mise en réseau consiste à relier plusieurs ordinateurs en vue de partager des ressources logicielles, des ressources matérielles ou des données. Selon le nombre de systèmes interconnectés et les

Plus en détail

STACCINI Pascal UFR Médecine Nice Université Nice-Sophia Antipolis

STACCINI Pascal UFR Médecine Nice Université Nice-Sophia Antipolis 2.3 : Apprécier les normes et standards et les technologies permettant l interopérabilité et le travail en réseau Chapitre 2 : Travail collaboratif en santé Normes et technologies de l interopérabilité

Plus en détail

CORBA haute performance

CORBA haute performance CORBA haute performance «CORBA à 730Mb/s!» Alexandre DENIS PARIS/IRISA, Rennes Alexandre.Denis@irisa.fr Plan Motivations : concept de grille de calcul CORBA : concepts fondamentaux Vers un ORB haute performance

Plus en détail

Systèmes répartis : les Remote Procedure Calls p.1/25

Systèmes répartis : les Remote Procedure Calls p.1/25 Systèmes répartis : les Remote Procedure Calls Fabrice Rossi http://apiacoa.org/contact.html. Université Paris-IX Dauphine Systèmes répartis : les Remote Procedure Calls p.1/25 Les Remote Procedure Calls

Plus en détail