Rapport de veille technologique

Transcription

1 Centres de compétences TIC Région wallonne, BE Rapport de veille technologique Architectures Orientées Services SOA / ESB Réalisé par Vivansa s.p.r.l. ( Simply because you need results.

2 [Page blanche pour impression recto-verso] Réalisé par : Vivansa ( 04-Nov-2005 Page: 2 of 25

3 PROJECT IDENTIFICATION CONTRACT NUMBER Veille technologique CUSTOMER Centres de compétences TIC PROGRAM N/A CONTRACTUAL Yes Written by: Checked by: Approved by: Name, Function Date Signature Pierre Halin IT Consultant R&D manager Saïd Eloudrhiri IT Consultant Solution manager Vivien Monti IT Consultant Executive Manager 23-Sep Oct Nov-05 SUMMARY: KEYWORDS: SOA ESB DOCUMENT CHARACTERISTICS Number of pages Number of figures Language Recipient name 25 4 FR N/A Réalisé par : Vivansa ( 04-Nov-2005 Page: 3 of 25

4 Versions Ed. Rév. Date Description Action(*) Paragraphes Création du document I Tous Revue interne M Tous Soumise pour commentaires M Soumise pour approbation Q Tous Modification du formatage Q Tous (*) Action: I = Insertion, R = Remplacement, M = Mise à jour, S = Suppression, Q = Revue Qualité Réalisé par : Vivansa ( 04-Nov-2005 Page: 4 of 25

5 Table des matières 1 GLOSSAIRE 6 2 INTRODUCTION 7 3 ARCHITECTURES DE DEVELOPPEMENT ARCHITECTURE TRADITIONNELLE OU ORIENTEE SERVICES ARCHITECTURE ORIENTEE SERVICES ET BUS DES SERVICES D ENTREPRISE (SOA/ESB) 10 4 ARCHITECTURE SOA/ESB GESTION DES PROCESSUS METIERS (BPM) ARCHITECTURE ORIENTEE SERVICES (SOA) SERVICES WEB BUS DES SERVICES D ENTREPRISE (ESB) DEFINITION COUCHES ARCHITECTURE 17 5 IMPACT METIER RESPONSABLES PROJET ARCHITECTES FONCTIONNELS ARCHITECTES TECHNIQUES DEVELOPPEURS ADMINISTRATEURS 20 6 PROJETS OPEN SOURCE MULE SERVICEMIX JBOSS GROUP OBJECTWEB CELTIX (IONA) SUN JAVA ESB 24 7 CONCLUSION 25 Réalisé par : Vivansa ( 04-Nov-2005 Page: 5 of 25

6 1 Glossaire BPEL B2B B2C BPM CORBA DCOM EAI EPO ERP ESB FTP HTTP J2EE JBI JMS MOM OASIS OSS PME POJO QoS RPC SMTP SNMP SOA SOAP UDDI UML WS WSDL XML XSL XSLT Business Process Execution Language Business to Business Business to Consumer Business Process Management Common Object Request Broker Architecture Distributed Component Object Model Enterprise application integration European Patent Office Enterprise resource planning Enterprise Service Bus File Transfer Protocol HyperText Transfer Protocol Java 2 Enterprise Edition Java Business Integration Java Message Service Message Oriented Middleware Organization for the Advancement of Structured Information Standards Open Source Software Petites et Moyennes Entreprises Plain Old Java Object Quality of Service Remote Procedure Call Simple Mail Transfer Protocol Simple Network Management Protocol Service-Oriented Architecture Simple Object Access Protocol Universal Description, Discovery and Integration Unified Modelling Language Web Service Web Service Definition Language Extensible Markup Language extensible Stylesheet Language extensible Stylesheet Language Transformation Réalisé par : Vivansa ( 04-Nov-2005 Page: 6 of 25

7 2 Introduction Membres du réseau des Centres de Compétences de la Région Wallonne, les centres Technifutur (Liège - Technofutur3 (Charleroi - et Technocité (Mons - sont chargés de la mise en œuvre d un projet de sensibilisation, d information et de formation de haut niveau dans le domaine des Technologies de l Information et des Télécommunications (TIC). Dans ce cadre, ils conduisent une activité de veille technologique ciblée sur l évolution des métiers et des qualifications dans ce secteur. Depuis 2002, ces trois centres fédèrent leurs moyens afin de mener cette démarche de veille de façon commune et en réseau. En particulier, ils ont demandé en juin 2005 à la société Vivansa ( de participer, par l intermédiaire de son unité recherche et développement, à l animation continue de cette veille et à la rédaction d un rapport bi-annuel. Afin d utiliser les ressources disponibles de façon optimale, cette veille se concentre sur un thème choisi conjointement. La période de veille pour le second rapport 2005 étant réduite par les circonstances, le thème a été choisi au cœur du métier de Vivansa : les architectures de développement orientées services. En premier lieu, nous comparerons l architecture de développement traditionnelle à celle orientée services (section 3). Ensuite, nous présenterons les briques technologiques sous-jacentes à l architecture SOA/ESB (section 4). Ensuite, nous étudierons les qualifications-métiers nécessaires pour soutenir l émergence de cette architecture (section 5). Enfin, nous présenterons les principaux projets Open Source actifs dans le domaine (section 6). Réalisé par : Vivansa ( 04-Nov-2005 Page: 7 of 25

8 3 Architectures de développement Tous les acteurs économiques sont confrontés à des besoins croissants en terme d informatisation. Qu il s agisse de soutenir et d intégrer les processus métiers au sein de divers départements ou qu il s agisse d ouvrir vers l extérieur les systèmes d information, les départements informatiques doivent analyser avec soin les besoins de leurs utilisateurs et leur offrir des solutions. Pour être adoptées par les utilisateurs, ces solutions doivent répondre à de nombreuses contraintes : garantir la sécurité, la pertinence et l intégrité des données, être efficaces et faciles d emploi. De plus, quand ces solutions sont destinées à des tiers professionnels (B2B) ou au grand public (B2C), elles doivent offrir une interface intuitive et se baser sur des technologies accessibles par tous. 3.1 Architecture traditionnelle ou orientée services Depuis de longues années, deux approches sous-tendent ces développements. La première, dite traditionnelle, part des technologies existantes et se rapproche autant que possible des besoins exprimés. La seconde, dite orientée services, part des besoins et sélectionne les technologies qui fonctionnent le mieux pour rencontrer ces besoins. Cette différence d approche se répercute sur divers aspects : Technologie Cycle de développement Durée de vie Coûts Environnement Approche traditionnelle Favorise la création d applications centralisées, conçues en un seul bloc subdivisé en plusieurs modules fortement interconnectés. Nécessite des cycles de développement très longs et favorise peu la réutilisation du code existant dans les versions ultérieures. La modification d applications traditionnelles étant souvent complexe et coûteuse, elles doivent être conçues pour durer. Les coûts directs de développement dans l approche traditionnelle sont souvent plus élevés. De plus, le manque d adaptabilité et la moins bonne adéquation entre les systèmes d informations et les processus métiers génère des coûts indirects trop souvent cachés ou négligés (manque à gagner, pertes de productivité, etc.). Nécessite des environnements homogènes et rendent l entreprise plus dépendante de ses fournisseurs. Architecture orientée services Favorise la création de plusieurs applications distribuées qui s interconnectent de façon très souple. Présente un cycle de développement plus court et plus itératif. Apporte des applications conçues pour s adapter continuellement aux processus métiers. La réutilisation des composants est l un des concepts clés de l architecture SOA qui offre une réduction de coûts. Permet de sélectionner l environnement le mieux adapté à chaque processus métier. Réalisé par : Vivansa ( 04-Nov-2005 Page: 8 of 25

9 Comme illustration de ces différences, nous pouvons citer un article récent traitant de l utilisation d ERP dans les PME (Dries Van Damme, Data News, 16 septembre 2005, page 8-9). L administrateur d une PME y parle des modifications qu ils apportent actuellement à l ERP installé quatre ans auparavant : Il y a quatre ans, nous ne pouvions pas prévoir où nous en serions aujourd hui [ ] nous avons produit de nombreuses nouveautés pour lesquelles le système a besoin d autres données [ ] adapter est loin d être une sinécure [ ] l objectif est de pouvoir repartir à nouveau quelques années. Nous y retrouvons la nécessité pour tout système d information de pouvoir s adapter. Mais à cause des coûts énormes des modifications, l architecture classique entraîne cette société à n avoir un outil réellement adapté que tous les quatre ans. Nous avons ainsi montré qu en théorie, l approche orientée services est supérieure à l approche traditionnelle pour soutenir le développement des entreprises : partant des objectifs à atteindre et trouvant les moyens d y arriver, elle est parfaitement adaptée au monde économique actuel, conçue pour évoluer et s adapter rapidement aux mutations. Elle a donc fait naître des espoirs importants dans les sociétés et de nombreux directeurs informatiques ont lancé d ambitieux projets EAI (Enterprise Application Integration). Malheureusement, 35% de ces projets (chiffre Forrester Research) ne se sont pas achevés en respectant les délais et les budgets. Plusieurs facteurs expliquent cet échec de l EAI : Solutions et protocoles propriétaires : la majorité des solutions EAI et des protocoles utilisés sont propriétaires, ce qui limite fortement les capacités d interconnexion des différentes solutions, en B2B par exemple. Manque d intégration des applications propriétaires : les solutions étant propriétaires, les développeurs de solutions traditionnelles n ont pas développé les passerelles nécessaires et le passage vers une solution EAI nécessite le remplacement des solutions existantes en une seule fois (effet big-bang). Coûts : les principaux éditeurs, se basant sur les qualités potentielles des solutions EAI, appliquent des coûts de licence excessifs. Le terme EAI est donc devenu un terme banni et à l heure actuelle, la majorité des entreprises utilisent une solution unique, propriétaire, soutenue par un grand nom du marché (SAP, PeopleSoft, Microsoft, etc.), quitte à devoir adapter leurs processus métiers en fonction de ce que cette technologie est capable de faire. Toutefois, de nombreux signes montrent que la tendance change et pourrait s inverser très rapidement. Réalisé par : Vivansa ( 04-Nov-2005 Page: 9 of 25

10 3.2 Architecture orientée services et bus des services d entreprise (SOA/ESB) Plusieurs facteurs expliquent ce changement de tendance : Emergence de standards : confrontées aux énormes problèmes d interopérabilité des standards propriétaires, le marché privilégie de plus en plus les standards ouverts et/ou multiplateformes (JAVA, XML, HTTP, UML, etc.). Mouvement Open Source : l émergence de ces standards rend possible le développement de solutions Open Source qui rivalisent avec les solutions propriétaires en terme de stabilité, de souplesse et même de fonctionnalités. Par leur caractère ouvert, ces applications s interconnectent beaucoup plus facilement et permettent une meilleure intégration. Services Web : utilisant une interface XML, les services web offrent des services à valeur ajoutée tout en dispensant l utilisateur de connaître les détails d implémentation. Extrêmement souples, ils permettent à l infrastructure globale d évoluer très facilement. Bus des services d entreprise : l ESB (Enterprise Service Bus - section 4.4) offre une infrastructure ouverte de services permettant d intégrer toutes les applications d une entreprise, y compris les applications propriétaires. Ce bus ouvert étant accepté par tous les éditeurs d applications traditionnelles sont ouverts à développer les passerelles nécessaires. La combinaison de ces facteurs permet à l approche orientée services (SOA) de revenir au premier plan. Elle ouvre la perspective d un système d information modulaire entièrement intégré : Chaque processus métier est servi par une application dédiée qui partage les informations et les services avec les autres processus au moyen du bus ESB. Les anciennes applications sont intégrées à ce bus au moyen de connecteurs dédicacés, évitant le big-bang qui accompagne trop souvent à l heure actuelle les changements de technologies. Les nouvelles applications sont gérées par des services web. Par leur souplesse, ils offrent une très grande réactivité aux besoins du marché. Ce retour au premier plan s est d abord traduit par l apparition de plusieurs solutions propriétaires (CapeClear, IONA, TIBCO, SONIC, IBM et BEA), disponibles depuis quelques années. Par-contre, dans le monde de l Open Source, les projets sont plus récents. A l heure actuelle, les projets Mule (section 6.1) et ServicesMix (section 6.2) sont très intéressants mais ils ne sont pas encore adoptées par les principaux acteurs du marché. En parallèle, de nouvelles initiatives venant de JBoss (section 6.3), ObjectWeb (section 6.4), Iona (section 6.5) et SUN (section 6.6) ont vu le jour et devraient offrir courant 2006 une alternative sérieuse aux solutions propriétaires. En particulier, le planning interne pour JBoss est le suivant : JBoss Web services sera disponible en Q4-2005, JBoss ESB en Q2-2006, JEMS SOA en Q et intégration complète des outils pour 2007 (présentation aux collaborateurs JBoss). Réalisé par : Vivansa ( 04-Nov-2005 Page: 10 of 25

11 En outre, les informations se recoupent pour annoncer l adoption rapide de cette approche par le marché : D ici 2008, SOA sera une pratique majeure dans le développement d applications, mettant fin à 40 ans de domination des architectures monolithiques (probabilité 0.7) (Gartner Group). Il est à noter que cette prédiction du Gartner Group date de 2003 et que le mouvement s accélère. Aujourd hui, plusieurs fournisseurs se disputent la domination du marché ESB et la lutte risque de durer encore deux bonnes années. A l issue de cette confrontation, seuls resteront trois ou quatre lauréats. A ce moment, il y a fort à parier que l ESB sera élevé au rang de commodity comme ce fut le cas pour les serveurs d applications. Il n est pas exclu non plus que les ESB soient, à terme, fournis d origine avec les systèmes d exploitation. (Rick F. van der Lans, Data News, 9 septembre 2005, page 43) De même, notre expérience de terrain montre que les mentalités évoluent très rapidement. Les instances de la Commission Européenne évaluent les nouveaux développements à l aune de cette approche. Et l office européen des brevets (EPO Riswijk, NL) a récemment commandé au consortium Siemens/Vivansa une étude de prototypage d une solution de reengineering de ses flux d information en utilisant SOA/ESB avec une solution Open Source, considérant qu il vaut mieux reculer l implémentation de deux ans pour avoir une solution plus souple encore. Aussi, nous pensons que les centres de compétence de la région wallonne doivent compléter leur offre de formation pour préparer les professionnels dont le marché aura besoin rapidement. La présentation des technologies sous-jacentes nous permettra de découvrir les axes de formation pertinents. Réalisé par : Vivansa ( 04-Nov-2005 Page: 11 of 25

12 4 Architecture SOA/ESB L architecture SOA/ESB de développement se présente selon quatre couches (Figure 1) : la gestion des processus métiers (BPM), l architecture orientée services (SOA), les services Web (WS) et le bus des services d entreprise (ESB). Figure 1 : Architecture 4.1 Gestion des processus métiers (BPM) Dans l exercice de son métier, toute entreprise met en place de nombreux processus visant à garantir la qualité et la reproductibilité de ses produits. Ces processus couvrent tous les départements et toutes les disciplines. Gérés par différentes personnes et modifiés de façon continue, il est généralement très difficile d en avoir une vue exhaustive. Parmi ces processus métiers, un grand nombre est soutenu par différentes applications informatiques, souvent incompatibles par le fait de leurs évolutions indépendantes l une de l autre. Cette hétérogénéité amène les responsables à rechercher une standardisation des échanges entre ces applications pour éviter les redondances tout en maintenant les applications fonctionnelles. C est dans ce contexte que le BPM joue un rôle important. En interviewant les acteurs clés et en rassemblant tous les éléments disponibles, l analyste se concentre en premier lieu sur la récolte des informations suivantes : besoins : quel sont les différents processus métiers et quels sont leurs besoins pour fonctionner? services : quelles sont les applications qui couvrent ces différents besoins et quelles informations peuvent-elles fournir à l extérieur? Réalisé par : Vivansa ( 04-Nov-2005 Page: 12 of 25

13 Sur base de ces informations, il est alors possible de modéliser, au moyen de langages de description formelle, les services existants, ceux à développer et le flux d information entre eux. Cette étape étant faite, il est alors possible de définir une architecture permettant l orchestration de ces différents services. 4.2 Architecture orientée services (SOA) SOA est un modèle visant à construire des systèmes distribués formés de composants indépendants (services) offrant des fonctionnalités, soit à des applications finales soit à d autres services, au travers d interfaces indépendantes des plateformes et des langages de programmation. De cette façon, ces services ne forment plus des systèmes isolés mais s intègrent dans une architecture formée de boîtes noires pouvant être réutilisées sans modification. Cette architecture est formée des rôles suivants (Figure 2) : Fournisseur : le fournisseur de service publie un contrat exposant son comportement. Il décrit aussi l interface de communication qu il offre, les entrées et les sorties devenant des messages envoyés au travers du réseau. Registre : le registre des services centralise les contrats disponibles sur le réseau Client : le client consulte le registre des services pour sélectionner le service adéquat et pour connaître la localisation de son fournisseur sur le réseau Figure 2 : Rôles dans une architecture SOA Le succès des SOA vient du fait qu elles sont orientées vers les métiers plutôt que vers les technologies. L identification et l organisation des services sont organisées en fonction des processus existants et pas en fonction des contraintes technologiques. De plus, le couplage entre les différents services est conçu de la façon la plus souple possible pour éviter que le client doive connaître les détails d implémentation du fournisseur. Réalisé par : Vivansa ( 04-Nov-2005 Page: 13 of 25

14 Un concept important dans cette architecture est celui d orchestration des services. Il permet de définir la façon dont les services doivent s agencer en fonction de leur durée d exécution et de leur interaction avec d autres services (exécution synchrone ou asynchrone). La spécification utilisée pour décrire cette orchestration est le langage BPEL (Business Process Extraction Language). Basé sur XML, il apporte la puissance d une description sémantique pour définir les processus, offrant ainsi la possibilité de réaliser des couplages souples entre les différents services et applications. Bien entendu, ce concept de fournisseur et de client n est pas neuf (présent par exemple dans CORBA, DCOM ou RPC). Mais la nouveauté provient vient du couplage lâche («loosely coupled») qui permet une meilleure interopérabilité et réutilisation des composants. De plus, SOA permet une adaptation incrémentale des systèmes d informations complexes. Au lieu du traditionnel big-bang, il intègre au fur et à mesure les applications existantes dans un cadre nouveau. Bien que les Services Web ne soient pas indispensables à la création d une architecture SOA, nous verrons dans la section suivante comment leur interface standard offre plus de puissance et de flexibilité à une telle architecture. 4.3 Services web Un service web est un service offert à des utilisateurs web ou à d autres services web au travers d un serveur web. Cette technologie constitue un maître-choix pour la mise en place d une infrastructure SOA bâtie sur des standards et des protocoles qui soient ouverts et indépendants des plateformes : XML est un langage sémantique devenu le standard pour la représentation de textes structurés sous format textuel. Les fournisseurs et les clients communiquent au moyen du protocole d accès SOAP (Simple Object Access Protocol), basé sur XML et véhiculé par HTTP. Les services Web exposent leur interface au moyen du langage de définition WSDL (Web Service Definition Language), lui aussi basé sur XML. La localisation des services par le registre peut se faire au moyen du protocole UDDI (Universal Description, Discovery and Integration). Sur base de cet ensemble de standards stables, plusieurs organisations (OASIS, W3C, etc.) et sociétés commerciales (IBM, BEA, Microsoft, etc.) ont défini un ensemble de spécifications pour tous les services d entreprises. Toutefois, la définition des processus métiers, d une architecture orientée services et de services Web ne suffit pas à implémenter de façon effective un système d information multi-organisationnel, multiplateforme et multi-processus. Le lien manquant est fourni par le bus ESB présenté ci-dessous. Réalisé par : Vivansa ( 04-Nov-2005 Page: 14 of 25

15 4.4 Bus des services d entreprise (ESB) Définition Défini pour la première fois par le Gartner Group, l ESB (Enterprise Service Bus) est une plateforme d intégration située à l intersection des architectures orientées services (SOA), de la modélisation des processus métiers (BPM) et de l intégration des applications. Cette solution middleware fournit une colonne vertébrale à une architecture SOA événementielle et faiblement couplée. Au travers de ce bus, les services échangent des messages leur permettant de fonctionner dans une architecture hautement distribuée. Ces échanges se font de façon synchrone (question/réponse) ou asynchrone (envoi/réception) en utilisant de multiples protocoles (SOAP, HTTP, HTTPS, SMTP, SNMP, FTP, etc.). Les capacités d une telle infrastructure peuvent être résumées comme suit : Dorsale pour les messages : la taille du bus s adapte en fonction du nombre d applications et de services qu il accueille et du volume de messages qu il traite. Il est compatible avec la spécification JMS (Java Message Service) et est basé sur des plateformes OpenSource orientées messages (Message-Oriented Middleware - MOM) comme JBossMS, Joram ou ActiveMQ. Cette dorsale offre une haute disponibilité, une grande sécurité et flexibilité, est facile à déployer et supporte bien entendu les services web (transformation SOAP/HTTP vers SOAP/JMS et vice-versa). Plateforme d intégration : l ESB est conçu pour connecter et enchaîner des applications, des données et des systèmes au travers du réseau au moyen d un couplage souple. Pour ce faire, il intègre de nouveaux services créant des passerelles vers des applications propriétaires existantes. Protocoles de communication : l ESB n est pas limité à SOAP sur HTTP mais permet d autres protocoles d échange comme SMTP ou JMS. Il permet même de recevoir des messages au travers d autres protocoles comme FTP. Services à valeur ajoutée : le but d une infrastructure ESB est aussi de fournir des services à valeur ajoutée facilitant le développement et le déploiement d applications. Ainsi, il est recommandé de lui confier certaines tâches comme la gestion de la sécurité, la validation de fichiers XML ou la transformation de messages entre applications. Flexibilité : la souplesse et l adaptabilité du bus ESB est intrinsèquement fournie par son caractère faiblement couplé et indépendant des plateformes. Indépendance : n étant lié à aucun vendeur de produits et s appuyant sur des standards ouverts, l ESB possède en son sein la garantie de sa pérennité. Réalisé par : Vivansa ( 04-Nov-2005 Page: 15 of 25

16 4.4.2 Couches L ESB s architecture en plusieurs couches (Figure 3) : Figure 3 : Architecture en couches Infrastructure : cette couche contient tous les composants existants dans l entreprise (DB2, Oracle, SAP, applications, ). Ces composants doivent être adaptés pour offrir une interface de type service web avant de se connecter à l ESB. De nombreux vendeurs développent actuellement une telle interface afin d offrir plus de pérennité à leurs applications. ESB : Le bus ESB offre un certain nombre de capacités communes (routage, registre de services, outils de transformation, orchestration, sécurité, enregistrement, gestion, etc.) et facilite leur association aux services web disponibles sur le bus multi-protocoles. Services métiers : Un certain nombre de services placés au-dessus de l ESB permettent d offrir une qualité de service (QoS) prédéfinie aux clients. Applications tierces : un certain nombre d applications externes peuvent aussi être présentes qui fournissent des informations par l intermédiaire de connecteurs externes. Processus métiers : la couche supérieure veille à la bonne orchestration des différentes composantes telles que définies par le BPM. Réalisé par : Vivansa ( 04-Nov-2005 Page: 16 of 25

17 4.4.3 Architecture La figure suivante présente une architecture typique de bus ESB : Figure 4 : Architecture typique Passerelle : l ESB supporte plusieurs protocoles synchrones et asynchrones de transport (HTTP, HTTPS, SOAP, JMS, FTP, SMTP, ). La passerelle est le point de contact de cette infrastructure avec le réseau. Routage: Ce service détermine la destination des messages sur le réseau. Ces décisions de routage peuvent être statiques mais peuvent aussi intégrer des informations de contexte (Context Based Routing CBR) contenues dans l entête du message. Transformation : Ce service se charge de toutes les transformations de message vers des formats non-xml, les transformations XML étant opérées au moyen de traitement XSLT appliqué à des feuilles de style XSL. Sécurité : Ce service contrôle les échanges entre les clients et les fournisseurs en fournissant les notions d autorisation, d accréditation et d encryption. Réalisé par : Vivansa ( 04-Nov-2005 Page: 17 of 25

18 Adapteurs: Les adapteurs sont utilisés pour connecter les applications externes au bus d entreprise. Certains connecteurs sont standards (J2EE Connector Architecture, SOAP, JMS, etc.) d autres doivent être développés en utilisant les boîtes à outils. Les principaux vendeurs de solutions propriétaires (SAP, Peoplesoft, etc.) développent leurs propres connecteurs. Finalement, il est aussi possible de développer des connecteurs «fichiers plats» vis-à-vis de la quasi-totalité des applications existantes. Réalisé par : Vivansa ( 04-Nov-2005 Page: 18 of 25

19 5 Impact métier Nous avons vu à la section 3 que l émergence de l approche SOA/ESB était en grande partie due à l adoption de standards communs par les différents acteurs. Cette convergence devrait entraîner les acteurs de la formation à préparer les professionnels de l informatique à l usage de ces standards. En particulier, il est nécessaire de compléter la formation des architectes, des développeurs et des administrateurs pour qu ils soient prêts lorsque les infrastructures ESB Open Source commenceront à être déployées. 5.1 Responsables projet Les responsables projet incluent aussi bien les directeurs informatiques que les chefs de projet. Ces métiers doivent évoluer afin de saisir l importance et les enjeux des architectures d intégration d applications de type SOA/ESB. Bien que ces personnes soient pour la plupart déjà familiarisées avec les architectures EAI, une formation adéquate aura pour intérêt de montrer et de prouver aux décideurs de l intérêt technique, stratégique et financier d une approche SOA/ESB. 5.2 Architectes fonctionnels L introduction d une architecture SOA/ESB a un impact très important sur le travail de l architecte d applications. Avec l inversion du rapport hiérarchique entre processus métier et technologie, la part de modélisation du métier augmente. Son intervention dans un projet suit les étapes suivantes : Identification et modélisation des processus métiers. Identification des services nécessaires pour soutenir ces processus. Analyse des services existants en vue de leur (ré)utilisation. Analyse des services manquants en vue de leur développement. Ecriture/modification des scripts BPEL pour l intégration de ces services sur le bus d entreprise. Pour soutenir ces étapes, il doit développer les compétences suivantes : Maîtrise des concepts sous-jacents aux quatre couches de l approche SOA/ESB (section 4) : BPM, SOA, Services Web et ESB. Connaissance active des standards UML, BPEL, WSDL, UDDI, XML et des outils associés sans oublier les aspects de sécurité. Connaissance passive des standards utilisés par les équipes de développement (section 5.4). Capacités d interroger et d écouter les gens pour identifier et modéliser les processus métiers. 5.3 Architectes techniques Les architectures SOA/ESB OpenSource sont mises en œuvre au travers d une plateforme J2EE. Réalisé par : Vivansa ( 04-Nov-2005 Page: 19 of 25

20 L architecte technique a pour mission d accompagner les clients dans leurs choix d architecture, de qualifier le socle technique et d assurer la conduite du changement. Tour comme l architecte fonctionnel (section 5.2), l architecte technique doit remettre à niveau ses connaissances en privilégiant les domaines suivants : Connaissance des concepts sous-jacents aux quatre couches de l approche SOA/ESB (section 4) : BPM, SOA, Services Web et ESB. Connaissance active des standards XML, XSLT, XPATH, SOAP, WSDL, UDDI. Connaissance active d une plateforme de développement, J2EE par exemple. 5.4 Développeurs L introduction d une architecture SOA/ESB valorise aussi le travail du développeur. Au lieu de développer un module perdu au milieu d une application tentaculaire, il devient responsable d une application complète offrant un service publié sur le bus d entreprise. Pour ce faire, il doit développer les compétences suivantes : Connaissance active des standards XML, XSLT, XPATH, SOAP, WSDL, UDDI. Connaissance active d une plateforme de développement, J2EE par exemple tel que JBoss. Connaissance active d outils de tests unitaires OpenSource tels que JUnit, Cactus. Connaissance actives d outils tels que Hibernate (persistance des données), JMX (Java Management extension), BPEL engine. Connaissance active d environnement de développement Open Source : Eclipse, CVS, SubVersion. 5.5 Administrateurs L administrateur informatique garde un rôle crucial dans l entreprise car son expertise sera très sollicitée en matière d installation, de configuration, de déploiement et d administration de l infrastructure SOA/ESB. Les connaissances requises par notre administrateur doivent couvrir entreautres les concepts suivants : Gestion des annuaires: UDDI, JDDI, LDAP. Administration de services via des consoles JMX. Maîtrise de plate-forme J2EE OpenSource tels que JBoss. Réalisé par : Vivansa ( 04-Nov-2005 Page: 20 of 25