Centres de compétences TIC
Région wallonne, BE
___
Rapport de veille technologique
Architectures Orientées Services
SOA / ESB
___
[Page blanche pour impression recto-verso]
PROJECT IDENTIFICATION
CONTRACT NUMBER PROGRAM
Veille technologique N/A
CUSTOMER CONTRACTUAL
Centres de compétences TIC Yes
Name, Function Date Signature
Written by:
Pierre Halin IT Consultant R&D manager
23-Sep-05
Checked by:
Saïd Eloudrhiri IT Consultant Solution manager
21-Oct-05
Approved by:
Vivien Monti IT Consultant Executive Manager
04-Nov-05
SUMMARY: KEYWORDS:
SOA ESB
DOCUMENT CHARACTERISTICS
Number of pages Number of figures Language Recipient name
25 4 FR N/A
Versions
Ed. Rév. Date Description Action(*) Paragraphes
0 01 05.09.2005 Création du document I Tous
0 02 20.09.2005 Revue interne M Tous
0 03 23.09.2005 Soumise pour commentaires M 3-6
1 00 28.10.2005 Soumise pour approbation Q Tous
1 01 04.11.2005 Modification du formatage Q Tous
(*) Action: I = Insertion, R = Remplacement, M = Mise à jour, S = Suppression, Q = Revue Qualité
Table des matières
1 GLOSSAIRE 6
2 INTRODUCTION 7
3 ARCHITECTURES DE DEVELOPPEMENT 8
3.1ARCHITECTURE TRADITIONNELLE OU ORIENTEE SERVICES 8
3.2ARCHITECTURE ORIENTEE SERVICES ET BUS DES SERVICES D’ENTREPRISE (SOA/ESB) 10
4 ARCHITECTURE SOA/ESB 12
4.1GESTION DES PROCESSUS METIERS (BPM) 12
4.2ARCHITECTURE ORIENTEE SERVICES (SOA) 13
4.3SERVICES WEB 14
4.4BUS DES SERVICES D’ENTREPRISE (ESB) 15
4.4.1 DEFINITION 15
4.4.2 COUCHES 16
4.4.3 ARCHITECTURE 17
5 IMPACT METIER 19
5.1RESPONSABLES PROJET 19
5.2ARCHITECTES FONCTIONNELS 19
5.3ARCHITECTES TECHNIQUES 19
5.4DEVELOPPEURS 20
5.5ADMINISTRATEURS 20
6 PROJETS OPEN SOURCE 21
6.1MULE 21
6.2SERVICEMIX 22
6.3JBOSS GROUP 22
6.4OBJECTWEB 23
6.5CELTIX (IONA) 23
1 Glossaire
BPEL Business Process Execution Language B2B Business to Business
B2C Business to Consumer
BPM Business Process Management
CORBA Common Object Request Broker Architecture DCOM Distributed Component Object Model EAI Enterprise application integration
EPO European Patent Office
ERP Enterprise resource planning
ESB Enterprise Service Bus
FTP File Transfer Protocol
HTTP HyperText Transfer Protocol
J2EE Java 2 Enterprise Edition JBI Java Business Integration
JMS Java Message Service
MOM Message Oriented Middleware
OASIS Organization for the Advancement of Structured Information Standards
OSS Open Source Software
PME Petites et Moyennes Entreprises POJO Plain Old Java Object
QoS Quality of Service
RPC Remote Procedure Call
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
UDDI Universal Description, Discovery and Integration UML Unified Modelling Language
WS Web Service
WSDL Web Service Definition Language
XML Extensible Markup Language
XSL eXtensible Stylesheet Language
XSLT eXtensible Stylesheet Language Transformation
2 Introduction
Membres du réseau des Centres de Compétences de la Région Wallonne, les centres Technifutur (Liège - http://www.technifutur.be/), Technofutur3 (Charleroi - http://www.technofutur3.be/) et Technocité (Mons - http://www.technocite.be/) 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 (http://www.vivansa.com/) 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).
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 :
Approche traditionnelle Architecture orientée services
Technologie Favorise la création d’applications centralisées, conçues en un seul bloc subdivisé en plusieurs modules fortement interconnectés.
Favorise la création de plusieurs applications distribuées qui
s’interconnectent de façon très souple.
Cycle de développement
Nécessite des cycles de
développement très longs et favorise peu la réutilisation du code existant dans les versions ultérieures.
Présente un cycle de développement plus court et plus itératif.
Durée de vie La modification d’applications
traditionnelles étant souvent complexe et coûteuse, elles doivent être conçues pour durer.
Apporte des applications conçues pour s’adapter continuellement aux
processus métiers.
Coûts 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.).
La réutilisation des composants est l’un des concepts clés de l’architecture SOA qui offre une réduction de coûts.
Environnement Nécessite des environnements homogènes et rendent l’entreprise plus dépendante de ses fournisseurs.
Permet de sélectionner
l’environnement le mieux adapté à chaque processus métier.
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.
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 multi- plateformes (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 Q4-2006 et intégration complète des outils pour 2007 (présentation aux collaborateurs JBoss).
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.
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 ?
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
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, multi- plateforme et multi-processus. Le lien manquant est fourni par le bus ESB présenté ci-dessous.
4.4 Bus des services d’entreprise (ESB)
4.4.1 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.
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.
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
• 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.
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.
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 entre- autres 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.
6 Projets Open Source
A l’heure actuelle, plusieurs produits commerciaux existent. Ils offrent des outils, généralement multi- plateformes et graphiques, pour concevoir, tester, déployer et monitorer de telles infrastructures. Mais dans le cadre de ce rapport de veille, nous nous concentrons sur les projets Open Source soutenant l’approche SOA/ESB, à savoir :
• Mule
• ServiceMix
• JBoss Group
• ObjectWeb
• Celtix (IONA)
• SUN Java ESB
6.1 Mule
Home page... Site principal : http://mule.codehaus.org
Le projet se trouve aussi sur http://sourceforge.net/projects/mule/ mais les informations y sont actuellement moins récentes que sur le site principal.
Version... Version stable 1.0 (18 avril 2005), version actuelle 1.1
Licence... Redistribution et utilisation des sources et des binaires permises, avec ou sans modification, en incluant le copyright suivant :
Copyright (c) 2003-2005 SymphonySoft Limited. All rights reserved.
http://www.symphonysoft.com
Description... Mule est le premier grand projet d'ESB en Open Source. Mule est une plate- forme de messaging ESB basée sur l'architecture SEDA (Staged Event- Driven Architecture). Mule peut envoyer et recevoir des messages en utilisant trois modèles : asynchrone, synchrone et requête/réponse.
Mule fournit un container de services qui peuvent être routés via différents transports tels que JMS, SMTP, JDBC, TCP, http, fichier, etc.
6.2 ServiceMix
Home page... http://www.servicemix.org
Version... Version stable 1.0.1 (18 août 2005)
Licence... Licence Apache 2.0 (http://www.apache.org/licenses/LICENSE-2.0) Copyright 2005 LogicBlaze, Inc.
Description... ServiceMix est un projet Open Source SOA/ESB. Il est construit à partir des de la spécification JSR 208 définissant le Java Business Integration (JBI).
6.3 JBoss Group
Home page... http://www.jboss.org
http://www.jboss.com/company/customers/aviva
Version... N/A Licence... N/A
Description... A ce jour, il n’y a pas encore d’annonce officielle de la part de JBoss Group concernant la sortie prochaine d’une infrastructure SOA/ESB Open Source.
Toutefois, nous pouvons estimer que cela ne saurait tarder car le numéro 1 des logiciels Open Source a pratiquement tous les ingrédients pour bâtir une architecture SOA/ESB robuste et standard. Ces solutions sont regroupées sous la bannière des produits JEMS (JBoss Entreprise Middleware System) : http://www.jboss.com/products/index.
Par exemple, la solution JBPM (JBoss Process Modelling) est prévu de supporter sous peu le standard d’orchestration de services BPEL. Ainsi, JBoss sera très bien positionné pour offrir une infrastructure ESB:
• JBossMQ: L’implémentation de l’API JMS pour le support des messages de type « queue » et « topic » (publish/subscribe).
• JBPM: Le moteur d’ orchestration de service qui supportera très prochainement le standard BPEL.
• Et bien-sûr, le support des standards “Web Services” et Java/J2EE.
6.4 ObjectWeb
Home page... http://www.objectweb.org https://wiki.objectweb.org/ESBi/
Version... Pas de planning pour la première version Licence... Inconnue
Description... En octobre 2004, le consortium ObjectWeb a lancé une initiative ESB visant à stimuler la réutilisation du middleware d’ObjectWeb en vue d’offrir une solution d’intégration d’application de type ESB.
Durant la première réunion du consortium
(http://www.objectweb.org/phorum/download.php/25,103/ESBKickOff-final- en.pdf), les composants ObjectWeb suivants ont été choisi comme base :
• JonAS: Serveur d’application Java certifié compatible J2EE 1.4
• MOBE (MidOffice BPEL Engine): outil d’orchestration BPEL
• Bonita, Shark, JaWE: Moteurs de workflow et outils associés
• JORAM: middleware de messagerie basée sur l’implémentation de l’API JMS
• JOTM: Gestionnaire de transaction distribué
• Xquark: outil d’intégration et de transformation XML/XQuery
• ActiveXML: framework pour encapsuler des appels de services dans des documents XML
• Enhydra Octopus: Un outil d’extraction et de transformation de données de type ETL (Extract/Transform/Load).
6.5 Celtix (IONA)
Home page... http://www.iona.com
https://wiki.objectweb.org/ESBi/
de lancer le projet Open Source Celtix qui sera hébergé par le consortium ObjectWeb (http://www.iona.com/pressroom/2005/20050620.htm).
Le code du projet Celtix sera entièrement neuf mais s’appuiera sur l’architecture de leur produit ESB commercial Artix ESB
(http://www.iona.com/products/artix/welcome.htm).
La première version de Celtix supportera :
• Standard WSDL pour la définition des contrats de service.
• Standards de transport WS-RM (WS-ReliableMessaging), JMS et HTTP.
• Outils d’administration et de configuration basés sur Eclipse.
• Support de base de la sécurité.
6.6 SUN Java ESB
Home page... http://www.sun.com/smi/Press/sunflash/2005-06/sunflash.20050627.1.html Version... Première version attendue dans les mois qui viennent.
Licence... Common Development and Distribution License (CDDL).
Description... Lors de la conférence « JavaOne Developer » du 27 juin 2005, SUN a annoncé son intention d’ouvrir les sources de son produit Sun Java
Enterprise Service Bus, conçu autour de la spécification JSR 208 définissant le Java Business Integration (JBI) et défini par le Java Community Process (JCP).
7 Conclusion
Nous avons vu que, dans le cadre du développement d’applications à l‘échelle d’une entreprise, l’approche orientée services (SOA) couplée à l’utilisation d’un bus de services (ESB) est en passe de devenir incontournable.
Partant des besoins de l’entreprise, elle permet l’adaptation rapide de l’architecture informatique, apportant un gain appréciable en réactivité et donc en compétitivité.
Basé sur des standards ouverts et largement acceptés tant par le monde propriétaire que par le monde OpenSource, le bus de services d’entreprise permet d’intégrer en douceur les applications existantes et/ou propriétaires avec des services Web par essence plus légers et dynamiques.
Cette nouvelle approche nécessite de compléter la formation de tous les intervenants dans la chaîne de développement, depuis les analystes fonctionnels jusqu’aux développeurs et testeurs. Aussi, nous conseillons aux centres TIC de la Région Wallonne d’enrichir leur offre de formation en couvrant mieux les aspects suivants :
• Approche SOA / ESB (BPM, SOA, Services Web et ESB)
• Standards ouverts (UML, BPEL, WSDL, UDDI, XML, XSLT, XPATH, SOAP, WSDL, UDDI)
• Java 2 Enterprise Edition (J2EE)
• Solutions JBoss
En outre, en parallèle aux rapports de veille semestriels, nous proposons l’utilisation d’un espace web dynamique permettant la publication de notes de recherches complémentaires sur les sujets traités dans les rapports précédents.
