Institut National de formation en Informatique
( ( I. I .N N. .I I) )
Thèse
Présentée pour l’obtention du diplôme de :
Magister
Spécialité : Systèmes d’Information et des Connaissances SIC
Titre de la thèse:
Collaboration des Processus Métiers dans les Echanges inter-entreprises (B2B)
basée sur le Web Service Resource Framework (WSRF) du Grid
Soutenance prévue devant le jury composé de :
Présidente Mme. Thouraya TEBIBEL Maître de Conférence, INI, Alger Directrice de Mémoire Mme. Habiba DRIAS Professeur, INI, Alger
Co-Directeur de Mémoire Mr. Youcef AKLOUF Chargé de Cours, USTHB, Alger Examinateur Mr. Amar BALLA Maître de Conférence, INI, Alger
Réalisé par : Mlle. KHELIFA Lydia Nadia
FEVRIER 2008 B.P 68 M Oued-Smar Alger, ALGERIE
Tél : 213 (21) 51.63.91 213 (21) 51.60.77 Fax : 213 (21) 51.61.56 Site Web : http://www.ini.dz Email : www.ini.dz/mail
REMERCIEMENTS
Je remercie Pr. Habiba DRIAS, pour m’avoir permis d’effectuer ce travail sans aucune contrainte et m’encouragé toujours et poussé à faire le meilleur de moi de même.
Je remercie également Dr. Aklouf Youcef pour avoir encadré ce travail.
Ses remarques de fonds ainsi que sa lecture attentive et critique de ce rapport a très clairement permis de modifier la version initiale. Je le remercie aussi pour m’avoir accordé toutes les facilités pour le bon déroulement de ce travail.
Mes remerciements s’adressent aussi aux membres du Jury pour m’avoir honoré en consentant à juger mon travail.
Je remercie mes collègues du CERIST, pour m’avoir soutenu et aider dans l’élaboration de ce travail.
Sommaire
Introduction générale ... 8
Chapitre I: Les échanges Business-to-Business (B2B) du e-commerce 1. Introduction ... 10
2. Les échanges B2B du e-commerce ... 10
2.1 L’intégration B2B (B2B integration: B2Bi) ... 11
2.1.1 Définition de l’intégration B2B ... 11
2.1.2 Le But de l’intégration ... 12
2.2 L’interaction B2B ... 12
2.2.1 Le modèle en couche du B2B ... 12
2.2.2 Les technologies de l’interaction B2B ... 13
2.2.2.1 Echange électronique des données (Electronique Data Interchange: EDI) .. 13
2.2.2.2 Workflow ... 15
2.2.3 Les standards du B2B ... 16
2.2.3.1 ebXML (Electronic Business XML) ... 16
2.2.3.2 RosettaNet ... 20
3. Conclusion ... 21
Chapitre II : La collaboration des Processus Métiers 1. Introduction ... 22
2. Définition des Processus Métiers ... 22
3. Le cycle de vie d’un Processus Métier ... 23
4. La gestion des Processus Métier (Business Process Management : BPM) ... 24
5. Les standards de modélisation des Processus Métiers ... 26
5.1 Business Process Modeling Notation (BPMN) ... 26
5.2 Unified Modeling Language (UML) ... 26
6. Les concepts de bases pour la description des Processus Métiers ... 27
7. Les standards de description des Processus Métiers ... 28
7.1 XLANG ... 28
7.2 Web Service Flow Language (WSFL) ... 29
7.3 Business Process Execution Language For Web Services (BPEL4WS) ... 29
7.4 Business Process Modeling Language (BPML) ... 30
7.5 Web Service Choreography Interface (WSCI) ... 30
7.6 Web Service Choreography Description Language (WS-CDL) ... 31
8. La collaboration des Processus Métiers ... 32
9. Les solutions de collaboration des Processus Métiers ... 33
10. Synthèse des solutions ... 43
11. Conclusion ... 45
Chapitre III : Les Processus Métiers et les concepts des Grids 1. Introduction ... 46
2. Définition du Grid ... 46
3. Les concepts du Grid ... 47
3.1 L’Organisation Virtuelle ... 47
3.2 Les Grid Services ... 48
3.2.1 Définition des Grid Services ... 48
3.2.2 Les principes des Grid Services ... 49
3.2.2.1 Les principes de l’Open Grid Service Architecture (OGSA) ... 50
3.2.2.2 Le WS-Resource Framework (WSRF) ... 52
4. Les Solutions combinant les Processus Métiers avec les concepts des Grids ... 57
4.1 Pourquoi combiner les Processus Métiers avec les concepts des Grids? ... 58
4.2 Les solutions combinant les Processus Métiers avec les concepts du Grid ... 59
5. Synthèse des solutions ... 67
6. Conclusion ... 67
Chapitre IV: Collaboration des Processus Métiers basée sur le Web Service Resource Framework (WSRF) 1. Introduction ... 69
2. Pourquoi utiliser les concepts du Grid dans la collaboration des Processus Métiers ? .... 69
3. Approche adoptée ... 71
4. Objectifs du modèle proposé ... 72
5. Schéma général ... 72
5.1 Architecture proposée ... 73
5.2 Description de chaque module ... 75
5.3 Fonctionnement de l’architecture ... 81
5.4 Implémentation proposée pour l’architecture ... 83
6 Conclusion ... 84
Conclusion Générale ... 85
Bibliographie ... 87
Glossaire ... 93
Annexes ... 95
Annexe A: Les Services Web ... 96
Annexe B : Le Grid computing ... 102
Annexe C : Open Grid Service Infrastructure (OGSI) ... 108
Annexe D : Exemple d’un Service Web à état dans le WSRF ... 114
Table des Figures
Figure 1: Example d’échange B2B [66]. --- 11
Figure 2:Intégration métier [46]. --- 11
Figure 3: Un framework pour l'interaction B2B [27]. --- 12
Figure 4: Les couches d'interaction B2B [27]. --- 13
Figure 5 : Architecture de l’EDI [34] --- 15
Figure 6: Architecture ebXML[31]. --- 18
Figure 7: Exemple d'un processus métier. --- 22
Figure 8: Cycle de vie d'un Processus Métier [46]. --- 23
Figure 9: Orchestration versus chorégraphie [78]. --- 28
Figure 10: Le modèle de médiation [60]. --- 36
Figure 11: Gestion P2P du processus collaboratif [61]. --- 38
Figure 12: Architecture du framework du Processus Métier [64]. --- 39
Figure 13: Relation entre OGSA, OGSI et WSRF. --- 49
Figure 14: Création d'une instance de service [13] --- 50
Figure 15: Publication de Grid Services [45] --- 51
Figure 16: Le mécanisme de notification [13] --- 51
Figure 17: Exemple d'un EPR [83]. --- 56
Figure 18: Message SOAP avec WS-Addressing [83] --- 56
Figure 19: Exemple de notification avec WS-Notification [83]. --- 57
Figure 20: Les quatre couches du système [75]. --- 60
Figure 21: L'architecture du BPMM [76]. --- 61
Figure 22: L’architecture proposée [77]. --- 63
Figure 23: Diagramme de séquence du service vendeur. --- 65
Figure 24 : Diagramme de séquence du marché pour un commerce directe. --- 66
Figure 25: Fondement de l’approche. --- 70
Figure 26: Relation entre les partenaires dans une OV. --- 73
Figure 27: Architecture de la collaboration. --- 73
Figure 28: Les Processus Métiers Publics. --- 74
Figure 29: Correspondance entre composants de l'architecture et les spécifications WSRF. - 76 Figure 30: Encapsulation des Processus Métiers Publics. --- 77
Figure 31: Invocation d’un Processus Métier Public encapsulé. --- 78
Figure 32: Enregistrement des Processus Métiers Publics encapsulés. --- 79
Figure 33: Synchronisation entre registre privé de l'entreprise et le registre de l'OV. --- 80
Figure 34:Détails de l’architecture proposée. --- 82
Figure 35 : Le fonctionnement des Web Services --- 97
Figure 36: Architecture en pile. --- 98
Figure 37 : La structure d’une enveloppe SOAP --- 98
Figure 38 : Les couches de l'architecture du Grid [1] --- 103
Figure 39 : Resolver un GSH [14].--- 110
Figure 40: L'invocation d'un Web Service Sans Etat. --- 114
Figure 41: L'invocation d'un web service à état. --- 115
Figure 42: L'approche de ressource pour l'état --- 115
Figure 43: WS-Resource. --- 116
Les Tableaux
Tableau 1: Exemple d'une architectutre Grid ... 105 Tableau 2: Tableau comparatif entre Grid Computing et P2P. ... 107 Tableau 3: Le mapping des concepts primaires de l’OGSI aux composants du WSRF [16] 112
Résumé
Les échanges intre-entreprises du e-commerce est un domaine en plein expansion. La collaboration inter entreprise représente un défi auquel les entreprises sont confrontées.
Cette collaboration tourne autour des processus métiers. Cependant, avec l’émergence de nouvelles spécifications résultant de la convergence des web services et des Grids, à savoir le Web Service Resource Framework (WSRF) ouvrent de nouveaux horizons pour la collaboration des processus métiers. Le WSRF décrit les web services à état. Le WSRF est un ensemble de spécifications pour spécifier une approche orientée WS-Resource pour la modélisation et la gestion de l’état dans un contexte web service. Le présent travail, a pour objectif de définir une collaboration qui se base sur le concept des grid à savoir les organisations virtuelles et le WSRF. Les web services à état sont utilisés pour encapsuler les processus métiers publics de chaque participant. En plus des spécifications du WSRF, le WS- Addressing est également utilisé pour l’adressage.
Mots clés: Collaboration des processus métier, Grid, WSRF.
Abstract
B2B e-commerce is an emergent area, which the profit of enterprises depend on its performance. The collaboration of Business Process is a challenge that the companies are facing to. However, the emergent specifications resulted form the convergence of web services and grid i-e Web Service Resource Framework (WSRF) open new horizon for the collaboration of business Processes. The WSRF specifies a WS-Resource approach to modeling and managing state in a Web services context. In this thesis, we present our vision of integrating the WSRF, its specifications and the WS-Addressing to the collaboration of Business Processes. The collaboration of Business Process is described through a collaborative Business Process defined by the whole participants. It’s composed of the public Business Processes of each participant. The Stateful Web Services is used to encapsulate the private Business Processes. Then, the choreography of the Stateful Web Services defined by WSRF result the collaborative Business Process. The WS-Notification is used to notify about the state changes for following the execution of the other participant’s Business Processes.
Keywords: Business Process Collaboration, Grid, WSRF.
Introduction générale
L’ère est à la mondialisation de l'ensemble des échanges économiques. Ces échanges concernent les services, les biens et aussi les facteurs de production, devenus plus mobiles.
Certains de ces échanges forment des marchés mondiaux.
Ainsi, dans un tel environnement qualifié de hautement compétitif, l’échange d’information et la collaboration efficace deviennent critiques. L’essence même de cet échange et de cette collaboration est le Processus Métier.
Le Processus Métier appelé également Business Process représente les interactions sous forme d'échanges d'information entre divers acteurs: humains, applications ou services et processus tiers. Dans la réalité, la collaboration entre les différents acteurs, qui définissent ces processus, est souvent difficile. Même si de nombreuses solutions logicielles ont déjà vu le jour, l’hétérogénéité des systèmes demeure une contrainte difficile à dépasser. Cette hétérogénéité peut être résolue avec le paradigme service web.
Seulement, la collaboration n’inclut pas uniquement l’hétérogénéité, elle nécessite d’autres notions telle que: la persistance de l’état contenu dans les processus métiers d’une manière générale et du processus métier collaboratif d’une manière particulière; la notification lors d’un changement d’état ; et finalement, la gestion du cycle de vie des processus métiers.
Toutefois, l’alignement des Services Web avec celles des technologies du Grid qui a donné naissance aux Grid Services ou encore des Services Web à Etat, a ouvert de nouvelles orientations quant à la collaboration des processus métiers.
Le Grid Service ou Web Service à Etat représente un concept du Grid qui a pour objectif de réaliser le partage flexible, sûr et coordonné de ressources ainsi que la résolution coopérative de problème au sein d’organisations.
Le Web Service à Etat est décrit avec des normes issues du Global Grid Forum (GGF) tel que le Web Service Resource Framework (WSRF) combiné à un autre concept des Grids à savoir les organisations virtuelles sont des candidats potentiels pour la définition d’une architecture de collaboration de processus métiers. Principalement, après le succès du Grid noté dans le domaine du e-science.
L’objectif de ce travail, est de présenter une architecture permettant la collaboration des processus métiers en se basant sur les concepts des Grids, notamment les Services Web à Etat décrit avec le Web Service Resource Framework.
Organisation du document
Le présent document se compose de quatre chapitres. Dans le premier chapitre, nous présentons le domaine de notre présente étude; les échanges B2B du e-commerce et les différentes technologies supportant ces échanges, afin d’introduire le concept processus métier qui représente le noyau de ces échanges. Le second chapitre, porte sur la collaboration des processus métiers en décrivant les processus métiers, et les différentes solutions de collaboration qui existent. Le troisième chapitre comprend les différentes solutions comportant la combinaison des processus métiers avec les concepts des Grids. Les concepts du Grid y sont également décrits. Le quatrième chapitre décrit notre contribution qui consiste en la définition de la collaboration des processus métiers sur les concepts du Grid à savoir l’organisation virtuelle et les Grid Services. Une conclusion générale ainsi qu’un ensemble de perspectives terminent ce mémoire.
.
Chapitre I: Les échanges Business-to-Business (B2B) du e- commerce
Résumé: Ce premier chapitre décrit le principe des échanges B2B et de ses différents concepts. Nous commencerons par la définition de l’intégration et de l’interaction. Ensuite, nous décrirons le modèle en couche et les standards de l’interaction inter-entreprises (B2B), afin d’introduire le concept des processus métiers.
1. Introduction
L’évolution du web a révolutionné la façon avec laquelle les entreprises interagissent avec leurs partenaires et clients (consommateurs). Cette révolution représente un défi pour l’interaction avec les applications hétérogènes internes et externes de l’entreprise pour le Business-to-Business (B2B). Ce dernier représente notre domaine d’étude. Ainsi, ce chapitre a pour objectif de présenter les concepts du Business-to-Business (B2B) du e-commerce, en présentant en premier l’intégration B2B, ensuite l’interaction B2B en décrivant son architecture, ses technologies et ses standards.
2. Les échanges B2B du e-commerce
Le e-commerce a été définit par le groupe Gartner1 comme étant un ensemble de produits et de services qui facilitent l’échange de produits, de services et d’information à travers des réseaux électroniques dans une entreprise, et entre les entreprises et leurs clients. Le e- commerce dans le B2B requiert l’intégration des systèmes partenaires. Cette intégration doit supporter l’interopérabilité entre ces systèmes partenaires avec lesquels ils doivent travailler.
Le Business-to-Business (B2B) [66] représente une des catégories du e-commerce. Il décrit toute activité se déroulant entre les entreprises, les spécialistes et les professionnels.
L’utilisation de transactions électroniques entre les entreprises permet de baisser le coût des achats, de réduire et d’optimiser les inventaires, d’accélérer la mise sur le marché de nouveaux produits, de diminuer les dépenses pour la vente et le marketing et d’ouvrir de nouveaux marchés.
La figure ci-dessous, est un exemple représentant un échange automatique entre deux entreprises dans un cas commercial. Cet échange concerne un ordre d’achat (PO) et d’une
1 Le group Gartner étant est une firme américaine de consulting et de recherche dans le domaine de la technologie. Ayant environ 10 000 clients, elle mène des recherches, fournit des services de consulting, tient à jour différentes statistiques et maintient un service de nouvelles spécialisées. http://www.gartner.com/
réponse d’ordre d’achat (POA). Une fois l’ordre d’achat envoyé par l’entreprise, un POA est systématiquement renvoyé du vendeur à l’acheteur en confirmant ou en rejetant cet ordre [66].
Figure 1: Example d’échange B2B [66].
Les concepts de l’intégration et de l’interaction du B2B sont très importants dans le cadre du e-commerce du B2B. Ces concepts seront détaillés dans les sections suivantes.
2.1 L’intégration B2B (B2B integration: B2Bi)
Les entreprises se rendent compte de plus en plus qu'elles font partie de réseaux physiques et de réseaux virtuels complexes d'affaires, dans lesquels les entreprises sont liées par le partage d'informations, les transactions interdépendantes et la collaboration des processus affaires.
Les entreprises tendent à intégrer leurs activités économiques pour plusieurs raisons, telle que la satisfaction de client, l’excellence opérationnelle, l’agilité (organisation virtuelle), la sécurité et la qualité du produit [47].
2.1.1 Définition de l’intégration B2B
Le concept intégration du B2B est très important dans le cadre du e-commerce. L’intégration métier est la création d’une coordination plus serrée parmi les activités métiers conduits par différents individus, groupes de travail ou organisations pour qu’un processus métier unifié se forme [47].
La figure 2 illustre un exemple d’intégration B2B entre deux entreprises et au niveau de l’entreprise elle-même [46].
Figure 2:Intégration métier [46].
2.1.2 Le But de l’intégration
L’intégration est la base de la collaboration entre partenaires et la collaboration est le but de l’intégration [75]. Le but de l’intégration selon [66] est de connecter des entreprises avec leurs partenaires commerciaux, afin de conduire des affaires. Cette connexion s’effectue à travers des échanges de données d’affaires.
2.2 L’interaction B2B
L'interaction est définie en tant que l'interopérabilité et l’intégration avec des applications internes et externes d'entreprise [73]. L’interaction dans le B2B offre un défi unique à cause des problèmes concernant le passage à l’échelle, l’autonomie et l’hétérogénéité. Le e- commerce dans le B2B requiert l’intégration et l’interopérabilité entre systèmes partenaires avec lesquels ils doivent travailler. L’interaction est aussi requise à un haut niveau de connexion tel que les applications front-end2 avec les applications back-end3 mais aussi les sources de données, les applications et le workflow [27]. La figure 3 illustre un exemple de framework pour une interaction B2B incluant deux partenaires.
Figure 3: Un framework pour l'interaction B2B [27].
2.2.1 Le modèle en couche du B2B
Les applications B2B se réfèrent à l’utilisation des systèmes informatiques, à savoir les serveurs web, les services réseaux et les bases de données, pour conduire des affaires tels que l’échange de document et l’achat de produits.
L’interaction du e-commerce dans le B2B se déroule à travers trois couches telles que définit par Medjahed et Al dans [27]: la couche communication, la couche contenu et la couche Business Process (processus métier). Ces couches sont représentées dans la figure ci-dessous et décrites en détail dans ce qui suit :
2 Front-end est une application avec laquelle l’utilisateur interagit directement (l’utilisateur peut être un humain ou un programme).
3 Back-end est une application ou un programme qui sert indirectement dans le support des services front-end.
Figure 4: Les couches d'interaction B2B [27].
¾ La couche communication : Fournit les protocoles qui permettent l’échange de message avec certains partenaires distants. Ces derniers peuvent utiliser différents protocoles de communication propriétaires ou standards (HTTP et SOAP). Les protocoles nécessitent l’utilisation de passerelle pour traduire les messages entre les protocoles hétérogènes.
¾ La couche contenu : Pour une bonne compréhension de l’information, cette couche fournit les langages et les modèles pour la décrire et l’organiser. Les interactions dans cette couche accomplissent une bonne intégration des formats de données, des modèles de données et des langages. Le contenu des interactions requiert que les systèmes inclus, comprennent la sémantique et les types des documents métiers.
¾ La couche Processus Métier : Concerne les interactions conversationnelles entre services. L’interaction dans cette couche permet aux partenaires autonomes et hétérogènes de publier leur vocabulaire et leurs capacités. Elle leur permet aussi de s’engager dans des interactions pair-a-pair avec n’importe quel partenaire.
L’interopérabilité dans cette couche, est un défi car elle requiert une compréhension de la sémantique des processus métiers des partenaires.
2.2.2 Les technologies de l’interaction B2B
Dans ce qui suit, nous détaillons certaines technologies qui supporte l’interaction B2B dans le e-commerce.
2.2.2.1 Echange électronique des données (Electronique Data Interchange: EDI)
L’Electronic Data Interchange (EDI) a émergé dans les années 60 lorsque les entreprises ont senti le besoin de partager leurs données d’une manière électronique. Il fut le premier standard pour l’échange électronique de l’information.
L’EDI a été défini comme le transfert des documents métiers d'application-à-application inter- organisationnel (par exemple, ordres d'achat, factures, notices d’expédition) entre les ordinateurs sous une forme compacte. Son but primaire est de réduire au minimum le coût, l'effort, et le temps de transfert des documents d'affaires [27]. Les documents EDI sont
structurés selon une norme (par exemple UN/EDIFACT4) et un format exploitable par machine.
L’interaction B2B dans une EDI nécessite : A. Des documents métiers.
B. Un Réseau à valeur rajoutée (Value Added Network:VAN): Réseau privé utilisé par une entreprise pour établir un lien de données dédié et servant de lien pour le transfert de données de type EDI ou d’autres services réseaux entre partenaires métiers. Avec la venue du World Wide Web, les entreprises ont de moins en moins recours au VAN pour l’acheminement des données.
C. Un translateur.
Comme illustré dans la figure 5: Le document est crée par l’application (système d’achat) de l’émetteur, le translateur est utilisé pour décrire la relation entre les éléments d’information dans une application et les standards de l’EDI et pour convertir le document EDI en un message EDI dans une enveloppe électronique qui contient un identifiant pour le receveur. La transmission de l’enveloppe électronique est réalisée par des logiciels de communications.
Ces logiciels conservent le numéro de téléphone du partenaire commercial pour dialoguer et échanger les opérations. Le logiciel de communication peut être une application séparée ou une partie du traducteur.
Le message EDI sera alors transmis via le VAN. Ce derniers, après lecture de l’identifiant se trouvant dans l’enveloppe, le place dans la boite électronique du récepteur et l’opération inverse est établie, pour interpréter le contenu de l’enveloppe.
Les standards EDI, fournissent une solution homogène pour l’interopérabilité du contenu Ils définissent également, un ensemble de type pour décrire les documents métiers.
Cependant, la conduite d’une transaction partenaire ayant des documents dont les paramètres ne sont pas inclus dans les documents EDI représente une limite pour l’EDI.
4 United Nation/Electronic Data Interchange for Administration, Commerce, and Transport.
Figure 5 : Architecture de l’EDI [34]
2.2.2.2 Workflow
Un Workflow est un flux d'informations au sein d'une organisation, comme par exemple la transmission automatique de documents entre des personnes. On appelle « workflow » la modélisation et la gestion informatique de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d'un processus métier. Ce dernier, consiste en une collection d’activité relatives aux données et au flux de contrôle. Une activité est réalisée par l‘exécution d’un programme ou encore par l’invocation d’autres processus métier.
Le Workflow est une technologie clé pour l’automatisation des processus métiers qui inclut l’accès à plusieurs applications. Ce qui rend le workflow une technologie candidate à l’intégration, l’automatisation et le monitoring des processus [27].
Le workflow [72] selon le WFMC5est « l’automatisation d’un processus métier dans sa globalité ou en partie, durant laquelle les taches sont transmises d’un participant à un autre pour agir suivant un ensemble de règles ». Cependant, il peut y avoir plusieurs workflows à gérer, de là, la nécessité d’un système de gestion des workflows (WFMS6). Ce système définit par le WFMC comme étant « un système qui définit, crée et gère l’exécution de workflows à travers l’utilisation de logiciels, qui s’exécutent sur un ou plusieurs moteurs workflows, ce dernier est capable d’interpréter la définition du processus, d’interagir avec les participants du workflow, où est requis d’invoquer l’utilisation des outils et des applications IT ». Lotus Note, Ultimus, Action Works Metro, sont des exemples de produits de gestion de workflow.
5 WFMC: Workflow Management Coalition.
6 WFMS: Workflow Management System.
Document sous format EDI Conversion au format interne Conversion
Document au format interne
VAN Système d’achat
Document convertit sous format EDI EDI translateur
Système de commande
Document au format Interne
EDI translateur
EDI Messaging EDI Messaging
Les systèmes de workflow [51] peuvent être de type collaboratif. Ce dernier est principalement caractérisé par le nombre de participant inclus et les interactions entre eux.
Des projets existent qui étendent les technologies workflow tel que CrossFlow [74].
2.2.3 Les standards du B2B
Plusieurs standards ont été apportés pour décrire les interactions B2B tels qu’ebXML et RosettaNet qui reste les plus référencés dans la littérature.
2.2.3.1 ebXML (Electronic Business XML)
L’ebXML [44] est une initiative lancée en novembre 1999 dont l’objectif était de définir un cadre de travail global pour le commerce électronique. Cette initiative est issue de l’expérience de praticiens de l’EDI et des connaissances des différents secteurs industriels où l’échange de données électroniques s’applique depuis longtemps avec succès. En effet, les promoteurs d’ebXML sont UN/CEFACT7 (qui a utilisé EDI pendant plus de 20 ans) et OASIS8 (qui a une grande expérience en XML).
L’ebXML ne s’occupe pas de documents échangés lors de transactions commerciales mais de la formalisation du processus métier. Il s’agit d’une chorégraphie d’activités d’une entreprise qui inclut une interaction entre participants sous la forme d’échange d’informations.
Les Processus Métiers ebXML sont définis dans la norme ebPSS (electronic business Process Specification Schema). Cette définition consiste en une séquence d’opérations représentées par des échanges de messages entre parties prenantes au processus.
L’initiative ebXML a réuni un consensus autour des composants essentiels au commerce électronique qui sont: des services d’annuaire, des Services de Messagerie, des protocoles, des contrats de collaboration et un schéma de spécification des processus métiers. Le détail de chacun de ces composants sera présenté dans ce qui suit :
¾ Des Services d’annuaire (Registry/Repository): Le service d’annuaire proposé par ebXML est similaire à UDDI. Le registre ebXML (ebRIM : ebXML Registry Information Model) offre une série de services qui favorisent l’échange d’information entre parties intéressées, de façon à permettre l’intégration d’un processus d’affaires entre ces mêmes parties en fonction des spécifications ebXML. L’information ainsi partagée est conservée sous la forme d’objets dans un référentiel et gérée par les services du registre ebXML. Un Registre ebXML fournit un ensemble de services destinés à partager l’information entre des Partenaires Commerciaux. L’accès au Registre ebXML est fourni par des Interfaces (APIs) publiées par les services du Registre.
7 UN/CEFACT: United Nations/Centre for Trade Facilitation and Electronic Business.
8 OASIS: Organization for the Advancement of Structured Information Standards.
¾ Des Services De Messagerie (Messaging service): initialement, le service de messagerie a été construit sur MIME9. Depuis février 2001, SOAP y a également été intégré. Ce service de messagerie est un standard OASIS (5 septembre 2002). Il est utilisé dans les échanges de messages lors de transactions de commerce électronique et dans les demandes et requêtes au registre.
¾ Les Protocoles et Les Contrats de Collaboration: il s’agit de Collaboration Protocol Profile (CPP) et Collaboration Protocol Agreement (CPA) que nous détaillons dans ce qui suit :
Collaboration Protocol Profile (CPP) décrit les capacités supportées par un partenaire commercial et les spécifications des Interfaces de Service. Ces dernières ont besoin d’être
« accordées » avant de pouvoir procéder à l’échange de documents d’affaires avec le partenaire commercial. Le CPP contient des informations essentielles au sujet du Partenaire Business, incluant de manière non limitative : des informations sur les coordonnées de contact, la classification par secteur d’activité, les Processus Business supportés, les spécifications fonctionnelles d’Interface et de Service de Messagerie. Les CPP peuvent également contenir des précisions sur la sécurité et des détails d'implémentation.
Collaboration Protocol Agreement (CPA) : est un document qui représente l'intersection entre deux CPP et qui est l’objet d’un accord mutuel entre deux Partenaires Commerciaux quand ils prévoient d’exécuter des opérations de Commerce Electronique en utilisant ebXML. Un CPA décrit le Service de Messagerie et les spécifications des procesus métiers qui sont agréés par deux ou plusieurs Partenaires Commerciaux. Un CPA contient les spécifications des besoins de l’Interface de Service de Messagerie aussi bien que les détails d'implémentation relatifs aux processus métiers que les deux Partenaires Commerciaux conviennent d’utiliser pour conduire leurs activités du e- commerce dans le B2B.
La figure 6 illustre une architecture ebXML pour deux partenaires.
9 MIME: Multipurpose Internet Mail Extensions.
Figure 6: Architecture ebXML[31].
¾ Un schéma de spécification des Processus Métiers (BPSS Business Process Specifications) permet de convertir les modèles de processus construits en UML en documents XML. En effet, la norme ebXML recommande l’emploi de la notation graphique UML10 et de la méthodologie des cas d’utilisation pour représenter le processus métier. Cette spécification est à la version 2.04 et a été renommée ebBP (ebXML Business Process) et a été approuvé comme un standard par OASIS le 21 décembre 2006.
Dans ebXML, un processus métier possède trois types de vues: les vues métiers, les vues fonctionnelles et les vues d’implémentation. Les vues métiers et fonctionnelles sont des documents texte qui contiennent souvent des diagrammes UML.
1. La vue métier (Business Operational View : BOV) contient le scénario général des différentes interactions entre les acteurs lors des transactions. La BOV est avant tout un moyen pour homogénéiser les points de vues de différents acteurs industriels d’un secteur donné. Elle est réutilisée par d’autres acteurs d’un secteur industriel voisin.
Les spécifications produites par la vue métier sont stockées dans les registres ebXML et sont transformées d’une manière semi-automatique en des documents XML. De ces documents sont extraits les protocoles et les contrats de collaboration sous la forme de DTDs. Ces derniers donnent la structure aux transactions effectuées lors de la phase d’implémentation du processus métier.
2. La vue fonctionnelle (Functional Service View : FSV) précise les interactions et les besoins fonctionnels nécessaires à l’implémentation pratique de BOV. La FSV
10 Unified Markup Language: http://www.UML.org.
Spécification des
Processus Métiers Spécification des Composants
Documents affaires
Service de messagerie Service de messagerie
Applications Business Services
Applications Business Services
CPA
CPP CPP
Répertoire/
Registre Interface
Service Business
Interface Service Business
Partenaire A Partenaire B
exploite toutes les informations relatives aux processus métiers stockés dans les registres ebXML.
3. Les vues d’implémentation sont décrites sous la forme de DTDs11 afin de permette un usage immédiat dans l’infrastructure XML des Web Services. Les processus métiers sont publiés dans les registres ebXML suivant le principe de séparation de ces vues.
¾ Les Collaborations des Processus Métiers dans l’ebXML
Une collaboration d’affaire est un ensemble de rôles collaborant les uns avec les autres par l’intermédiaire de transactions chorégraphiées lesquelles sont elles-mêmes constituées d’échanges de Documents d’Affaires. Une collaboration se compose de plusieurs activités.
Une activité est celle d’une transaction d’affaire (par exemple : émission d’une commande), ou d’une autre collaboration binaire (par exemple: négociation d’un accord).
La collaboration constitue le premier engagement sur la définition de capacités. Cet engagement peut être déclaré par des Partenaires Commerciaux ebXML. Cette « déclaration de capacités » est facilitée par un profil distinct spécialement destiné à être publié ou référencé, dans un service d’annuaire, comme un Registre ebXML, ou un tout autre service disponible. Les spécifications CPA - CPP incluent des annexes non normatives qui traitent de la négociation et de la composition d’un CPA et présentent des recommandations pour la mise en œuvre des procédures de composition et de négociation.
Les participants dans les transactions ebXML (trading partners) décrivent les processus métiers et le type de collaboration auxquels ils peuvent participer. Ceci est formalisé en utilisant le CPP qui est publié dans les annuaires ebXML.
Le CPP permet de définir : 1. l’identité du participant ;
2. les protocoles de transport et de sécurité requis et offerts ; 3. et les liens vers les schémas de processus métier.
La recherche dans les annuaires permet de découvrir les profils appropriés à une transaction dans un processus métier. Ceci est fait de façon automatique par les moteurs de recherche, qui font partie des registres ebXML, en comparant les différents attributs des CPP. De ces comparaisons résulte un « dénominateur commun » entre les différentes contraintes des participants, comme par exemple, les protocoles à utiliser, les besoins en sécurité et la composition des messages.
11 DTD: Document Type Definition.
Le résultat de l’analyse des profils est ensuite représenté en utilisant le CPA stocké par le programme Client et le Serveur qui règle l’exécution des processus métiers correspondants.
¾ UMM UN/CEFACT Unified Modelling Methodology
UMM [84] est une extension d’UML12. C’est un profile UML utilisé pour décrire les composants UMM pour spécifier les stéréotypes spécifiques au domaine métier, qui supporte un processus métier complet, et la définition de l’information pour décrire et analyser les processus métiers individuels. UMM est une approche pour définir les processus métiers inter-organisationnel. Il est utilisé pour modéliser la chorégraphie et l’échange de données.
Il peut être employé par les analystes métiers pour définir des frameworks de collaboration métier externe et interne. Il peut également être utilisé pour définir un framework de collaboration implémenté avec deux ou plusieurs parties. Le résultat final d’une utilisation intégrée d’UMM est la définition d’un framework de collaboration métier.
UMM a une compréhension des processus métiers et un méta-modèle de l’information métiers aussi bien qu’une méthodologie d’analyse de processus. Il fournit une méthodologie et des composants qui supportent la capture des connaissances des processus métiers
2.2.3.2 RosettaNet
RosettaNet [35] a été créé en 1998 pour formaliser en XML tous les éléments nécessaires à l'automatisation des services sur le Web dans les secteurs de l'électronique, des semi- conducteurs et de l'informatique. Cet organisme a pour objet de formaliser le dialogue entre partenaires lors de transactions commerciales. Il vise à simplifier la mise en place et la gestion des processus métiers dans les secteurs industriels qu’il regroupe.
Pour que le dialogue entre partenaires ait lieu, l'architecture technique de RosettaNet définit trois notions :
• Des dictionnaires et des codes définissant le vocabulaire commercial employé dans les documents RosettaNet transitant sur le Web.
• Un modèle de processus métier appelé Partner Interface Process (PIP) : PIP est un catalogue le plus complet possible de processus préfabriqués qui est mis à la disposition des utilisateurs de RosettaNet (PIP Directory).
• Un cadre d'implémentation RosettaNet Implementation Framework (RNIF) : RNIF définit les choix techniques du consortium pour le format et l'échange des messages RosettaNet.
12 UML: Unified Modeling Language.
L’intérêt se porte principalement sur les dictionnaires qui constituent des descriptions sémantiques des objets d’un domaine.
RosettaNet a recours, pour la codification des sociétés et des produits, à des codes existants, également employés dans l'univers EDI. Il offre deux dictionnaires :
• RosettaNet Technical Dictionnary (RNTD) qui articule les descriptions des propriétés techniques et de relations en vue de faciliter la création de catalogues, la création de documents de spécifications, et l'alimentation de bases de données.
• RosettaNet Business Dictionnary (RNBD) qui contient des descriptions d'objets métier communs aux différents processus PIP (bons de commande, facture, etc.)
La création et le traitement de l'information commerciale mettent en jeu les dictionnaires et les codes RosettaNet pour assurer un partage et une compréhension des documents échangés.
Les échanges de messages RosettaNet sont pilotés par le PIP qui dirige la transaction entre partenaires RosettaNet.
Même si les processus métiers représentés dans RosettaNet s'inspirent des méthodes de production et de distribution en informatique et en électronique, un certain nombre de notions trouve un champ d'application plus vaste dans le domaine du commerce électronique en général. Ceci explique les rapprochements entre RosettaNet et ebXML pour l'harmonisation des définitions et du vocabulaire XML.
3. Conclusion
Ce chapitre s’est porté sur le B2B du e-commerce, en décrivant ces concepts de base, à savoir l’intégration et l’interaction B2B. En dénotant l’architecture, quelques technologies et les standards permettant l’interaction B2B. Notre intérêt va s’orienter vers les processus métiers qui représentent la composante clé de la couche externe de l’échange inter-entreprise (B2B).
Ainsi, le chapitre suivant va porter sur les Processus Métiers et plus précisément leur collaboration qui représente un défi dans le e-commerce du B2B.
Chapitre II : La collaboration des Processus Métiers
Résumé: Ce chapitre décrit la collaboration des Processus Métiers. Nous commencerons par la définition des Processus Métiers, ensuite nous décrirons les différents standards permettant sa définition. Finalement, nous décrirons les différentes solutions existantes de collaborations de Processus Métiers.
1. Introduction
Aujourd’hui plus que jamais, les organisations de toute taille se développent dans le monde entier: fournisseurs dans un pays, clients dans un autre. C’est la raison pour laquelle, il est devenu vital de faire collaborer et d’intégrer tous ces partenaires dans un environnement métier. Nous nous intéressons dans ce qui suit à la collaboration des processus métiers. Ce chapitre va donc porter en premier lieu sur la définition des processus métiers et les différents langages les décrivant. Ensuite, les différentes solutions et propositions faites par des chercheurs et industriel pour permettre une collaboration métier efficace.
2. Définition des Processus Métiers
Définition 1 : Un Business Process ou Processus Métier ou encore processus affaire est un ensemble de règles métiers (business), de définitions d’activités et d’événements déclencheurs qui fournissent un contexte d’échange d’information [42].
Réservation d’une chambre d’hôtel (comme illustré dans la figure 7) est un exemple de processus métier. L’élément déclencheur est représenté par l’individu, {réserver une chambre d’hôtel, débiter de la carte de crédit et la notification au client} représente les activités et les règles métiers sont désignés par la disponibilité ou non d’une chambre d’hôtel.
Figure 7: Exemple d'un processus métier.
Définition 2 : Un Processus Métier selon [59] est une unité persistante d’un travail pouvant avoir jusqu’à 100 transactions IT13. Il est déclenché par un événement métier tel que
13 IT : Information Technology.
Oui Réserver une Non chambre d’hôtel
Débiter de la carte de crédit
Notifier au client
Fin
Résultat Demande
l’invocation, requête pour proposition ou une requête pour un transfert de fonds. Le processus est conduit par des règles métiers qui déclenchent les tâches et les sous-processus, avec chaque transition d’état exécutée dans une transaction et auditée pour des raisons métiers. Les tâches et les sous-processus sont assignés à des ressources qui sont des unités organisationnelles capables et autorisés à jouer des rôles spécifiques dans le processus. La définition des règles, des tâches, des sous-processus, et des stratégies de ressources constitue une description de processus. L’exécution d’un processus métier consiste en l’invocation des services métiers existants, qui peuvent résider n’importe où.
Définition 3 : Un Processus Métier selon R.Gong [33] est un ensemble d’activités conçues pour produire des outputs spécifiques pour un marché ou un client particulier. Il peut être définie sur la base de trois dimensions :
1. Entités : les processus prennent place entre les entités organisationnelles. Il peut être inter-organisationnels, inter-fonctionnel ou encore entre personnes.
2. Objets : les processus sont le résultat d’une manipulation d’objet. Ces objets peuvent être physiques ou informationnels. Notifier au client (figure 7) est un exemple d’objet.
3. Activités : les processus peuvent impliquer deux types d’activités : les activités opérationnels et les activités de gestion.
3. Le cycle de vie d’un Processus Métier
Intalio14 [46], a présenté les quatre étapes constituants le cycle de vie d’un processus métier.
Ces étapes sont illustrées dans la figure ci-dessous.
Figure 8: Cycle de vie d'un Processus Métier [46].
¾ Première phase: phase de modélisation du processus métier. Elle représente la phase où l’importation des définitions des processus métiers dans les outils
14 Intalio: Acteur spécialisé dans les solutions Open Source de gestion des processus métier et acteur historique sur la scène de la gestion des processus d'entreprise
Modélisation
Déploiement
Interaction Exécution
techniques est possible, afin d’ajouter le lien avec les applications du SI15. Les capacités de modélisation des outils devraient permettre de déployer directement les processus modélisés sans passer par une phase d’implémentation.
¾ Seconde phase : Déploiement du code réalisé durant la phase précédente.
¾ Troisième phase : consiste en l’exécution des applications existantes de l’entreprise.
¾ Quatrième phase : consiste en l’interaction des utilisateurs avec ce processus. Une fois le processus déployé, la phase d’interaction permet de l’optimiser. Cette phase permet d’identifier les modifications à effectuer. Pour les réaliser, on entre alors dans une autre phase de modélisation, et ce cycle se répète. Généralement, après trois itérations, il est plus simple de re-développer l’application hébergeant le processus que d’en modifier l’implémentation.
4. La gestion des Processus Métier (Business Process Management : BPM)
Généralement, les systèmes d’affaire qui supportent des activités d’affaires importantes comprennent des processus métiers. Ces processus métiers nécessitent une gestion et une intégration rigoureuse avec les nouveaux systèmes des partenaires.
Pour Gartner, le Business Process Management ou encore le système de gestion de processus (BPM) est devenu une véritable discipline de management qui considère les processus métiers comme des actifs de l’entreprise à concevoir, à re-définir ou à exploiter afin d’en améliorer l’agilité et la performance opérationnelle. Le BPM inclut la capacité de découvrir, de concevoir, de déployer, d’exécuter, d’interagir avec, d’optimiser et d’analyser les processus métiers [50]. Il vise également à formaliser, à organiser et à contrôler les activités d'une entreprise. Lorsque les processus sont suffisamment bien définis et modélisés.
Le gestionnaire des processus (BPM) [59] gère l’état du processus métier et route les requêtes parmi les applications participantes. Le plus souvent, la séquence des étapes à être traversée dans l’exécution d’un processus métier est définie avant que l’instance du processus ne soit initiée. Durant l’exécution, un événement déclenche le système de gestion des processus pour créer une instance de processus, le système de gestion des processus ainsi coordonne les étapes d’exécution, surveille et enregistre l’historique.
Selon [27] et [48], la gestion inter-entreprise des processus métiers comporte deux types de processus métiers : les processus métiers publics et les processus métiers privés.
15 SI : Système d’Information.
1. Un processus public définit un échange de messages d’une organisation avec ses partenaires à travers un protocole d’échange.
2. Un processus privé décrit des exécutions d’activités interne supportées par les processus privés. Il peut également interagir avec des applications « back-end » (Back- end est une application ou un programme qui sert indirectement dans le support des services front-end. Ce dernier est une application avec laquelle l’utilisateur interagit directement) à travers des adaptateurs d’applications.
Ces deux processus métiers (privé et public), agissent à travers des traducteurs (wrappers) qui consistent en des activités prédéfinies dans les processus métiers privés pour envoyer /recevoir des messages provenant/destinés aux processus métiers publics.
La séparation entre les composants d’une application B2B (à savoir : les processus métiers privé et publics, les règles métiers et les systèmes « back-end ») contribue au passage à l’échelle de la collaboration. Et la séparation entre un processus métiers public et un processus métiers privé fournit un plus grand degré d’autonomie.
Cependant, les changements s’effectuent de la façon suivante [36] :
- Les changements relatifs aux interactions (exemple : changement de format des messages entrants et sortants) entre un processus publique (ou application « back- end ») et un processus privé peut requérir la modification de certains traducteurs.
- Le support d’un nouveau protocole d’interaction nécessite seulement la création de nouveau processus publique et de nouveaux traducteurs de processus (wrappers).
- Le support de nouvelles applications « back-end » nécessite la création de nouveaux adaptateurs d’applications.
- La création d’une nouvelle relation avec de nouveaux partenaires peut nécessiter de nouveaux ajustements.
- Si le partenaire ne se conforme pas à un protocole d’interaction déjà supporté, alors un nouveau processus public doit être créé pour supporter le protocole utilisé par le nouveau partenaire.
Yphise16 nomme TIBCO17 meilleur éditeur de solution BPM (en Novembre 2006) dans un comparatif certifié ISO 9001:2000 réalisé par le cabinet de conseil. Ainsi, TIBCO iProcess Suite devance les solutions développées par les autres grands éditeurs.
16 La société Yphise est certifiée ISO 9001 dans l’évaluation de progiciels. Cette norme internationale de la qualité garantit l'indépendance et le centrage sur les préoccupations des grandes entreprises. Le métier d'Yphise est d'identifier et d’évaluer les progiciels qui méritent un investissement en grande entreprise. Ses publications font référence dans le monde. Yphise évalue 150 progiciels par an depuis 1985.
5. Les standards de modélisation des Processus Métiers
Des standards et des langages pour la modélisation des processus métiers existent tel que : 5.1 Business Process Modeling Notation (BPMN)
Le BPMI18 issue d'un regroupement d'entreprises, a développé le standard Business Process Modeling Notation (BPMN) [71]. Ce dernier a pour objectif primaire de fournir une notation compréhensible par tous les utilisateurs métiers; des analystes métiers qui créent des drafts initiaux de processus, aux développeurs techniques responsables de l’implémentation de la technologie qui exécute ces processus, et finalement, aux gestionnaires et ceux qui surveillent ces processus. Ainsi, le BPMN crée un lien standardisé entre la conception et l’implémentation des processus.
Un autre objectif, mais qui n’est pas moins important, est d’assurer que les langages XML conçus pour l’exécution des processus affaires, tels que le BPEL (qui sera définit dans la section suivante), puissent être visualisés avec une notation orientée métier. La modélisation des processus métiers est utilisée pour communiquer une large variété d’information à une large variété d’audience. BPMN est conçu pour couvrir plusieurs types de modélisation est de permettre la création des processus métiers de bout en bout (end-to-end). Les éléments structurels du BPMN permettent aux observateurs d’être capable de différencier facilement entre les sections d’un diagramme BPMN. Il y a trois types basiques de sous modèles dans un modèle BPMN bout en bout, à savoir, les processus métiers privés, les processus publics et la collaboration des processus. Cependant, le BPMN ne prend pas en considération dans la modélisation les règles métiers, la stratégie, les modèles de données et d’information et les ressources et structures organisationnelles.
5.2 Unified Modeling Language (UML)19
Unified Modeling Language est un langage de représentation d’un modèle, d’une structure, appliqué à la programmation orientée objet. UML comporte différents diagrammes tel que les diagrammes de séquence et les diagrammes d’activités.
17 TIBCO Software Inc. (NASDAQ:TIBX) est un éditeur de logiciels d'intégration et de gestion des processus métier dans le domaine de l'information en temps réel. L'activité en temps réel permet aux entreprises de saisir sur-le-champ les changements et les opportunités dès leur détection. http://www.tibco.com.
18 Business Process Management Initiative.
19 UML. http://www.uml.org.
6. Les concepts de bases pour la description des Processus Métiers
Dans ce qui suit, nous présenterons brièvement deux concepts sur lesquels reposent la description des processus métiers à savoir XML et les web services.
1. XML (eXtensible Markup Language) : modèle de données semi-structuré, dont le premier draft a été publié en 2000 par le W3C20. il se base sur HTML et le SGML. Il représente un format d’échange universel.
2. Web Services: sont décrits grâce à des fichiers WSDL (Web Service Definition Language) enregistrés dans un répertoire UDDI (Universal Description, Discovery, and Integration) et communiquent grâce au protocole SOAP. (Annexe A).
o L’orchestration et la chorégraphie des Web Services:
Les termes orchestration et chorégraphie décrivent deux aspects de création de processus métiers à partir des web services composites [78]. L’orchestration et la chorégraphie sont utilisées dans les processus métiers et les systèmes de gestion de processus métiers [50] :
1. L’orchestration: décrit l’interaction entre web services, en incluant la logique affaire (business) et l’ordre d’exécution des interactions. Ces interactions peuvent traverser des applications ou/et des organisations, et résulte dans un modèle de processus à multi étapes transactionnel et de longue durée [81]. Les orchestrations sont définies par le consortium W3C comme étant « le modèle des interactions que doit respecter un agent Service Web pour atteindre son but ».
2. La chorégraphie: trace la séquence des messages qui peuvent impliquer de multiples parties et de multiples sources, en incluant les clients, fournisseurs et partenaires. La chorégraphie est typiquement associée à l’échange de messages publics qui se produisent entre de multiples web services plutôt qu’à un processus métier spécifique qui est exécuté par une seule partie [81].
La figure ci-dessous, décrit l’orchestration et la chorégraphie. L’orchestration se réfère à un processus exécutable. Par contre, la chorégraphie trace les séquences de messages entre parties et ressources [78].
20 W3C: World Wide Web Consortium
Figure 9: Orchestration versus chorégraphie [78].
La différence entre la chorégraphie et l’orchestration a été soulignée dans [81].
L'orchestration se rapporte à un processus exécutable d'affaires qui peut agir l'un sur l'autre avec des services Web internes et externes. Pour l'orchestration, le processus est toujours commandé par la perspective d'une des parties d'affaires. La chorégraphie est plus collaborative par nature, dans laquelle chaque partie concernée dans le processus décrit le rôle qu'elle joue dans l'interaction.
7. Les standards de description des Processus Métiers
Cette section comportera les différents standards de description des processus métiers, les plus référencés dans la littérature tel que : XLANG, WSFL, BPEL4WS, BPML, WSCI.
7.1 XLANG
C’est un format proposé par Microsoft, en 2001, pour représenter en XML l’orchestration d’activités qui constituent un processus métiers. XLANG est le format intermédiaire de stockage de l’environnement BizTalk server21. Ces documents XLANG, ou encore appelé schedules : sont exécutés par le serveur BizTalk en phase de production. XLANG s’appuie sur WSDL en réutilisant un certain nombre de ses concepts [38].
Le document XLANG [37] comprend :
1. Les actions XLANG : elles sont au nombre de quatre. Elles peuvent être élémentaires dans la représentation du workflow entre participants. Citons comme exemple : l’action raise pour signaler les défaillances, ou encore, Operation pour l’échange de message référençant le port d’un service donné.
2. Le contrôle XLANG : consiste en des commandes de contrôle de l’enchaînement de l’exécution des actions. Par exemple : la commande sequence permet l’exécution séquentielle d’une ou de plusieurs actions.
21 Microsoft BizTalk Server http://www.microsoft.com/biztalk/default.mspx
3. Les corrélations de messages : il est possible d’associer des champs d’information supplémentaires à un message d’une opération. Ces champs qu’ils soient simples ou complexes sont utilisés pour corréler des messages entre eux.
4. Le contexte : le contexte est un élément XLANG qui permet de définir des variables locales et des transactions liant les actions ou les combinaisons d’actions. Les variables locales sont constituées des définitions des corrélations et des références aux ports WSDL qui sont utilisées dans les actions.
5. Les transactions XLANG : une transaction préserve l’intégrité des données qu’elle manipule. Dans le cas de transactions dites longues, où les suspensions et les reprises d’exécution peuvent être beaucoup plus espacées dans le temps, les états même partiels doivent être sauvegardés pour éviter que leur verrouillage durable n’affecte d’autres transactions.
6. Les contrats : précisent comment lier deux ports différents des service XLANG. Pris ensemble avec les définitions des comportements XLANG, les contrats constituent la définition complète du workflow entre les différents services. La définition d’un contrat XLANG en XML consiste en général à importer la définition XLANG des deux services à relier et à spécifier comment les opérations de sortie de l’un aboutissent aux opérations d’entrée de l’autre.
7.2 Web Service Flow Language (WSFL)
Proposé par IBM, le WFSL [40] est un langage de description de combinaison des Web Services de façon utile. Deux façons de combiner les services sont définies :
1- Des modèles de circuit (Flow Model), où un circuit représente une séquence à exécuter pour qu'un processus métiers puisse être réalisé ;
2- Des modèles globaux (Global Model), où la perspective est celle des régularités dans l'interaction entre les Web Services dans le contexte de collections de services typiques. Ces interactions sont réglées par des liens entre des services, avec un lien pour chaque opération possible entre deux services dans une collection. Ce réglage peut être adapté soit à des interactions dans des hiérarchies, soit à des interactions collaboratives entre pairs.
7.3 Business Process Execution Language For Web Services (BPEL4WS)
En 2003, la spécification BPEL4WS1.1 [36] a émergé après la convergence de deux spécifications à savoir le WSFL et le XLANG.
Le Business Process Execution Language for Web Services (BPEL4WS) fournit une notation XML et une sémantique pour la spécification du comportement des processus métiers basés sur les Web Services. Un processus BPEL4WS est défini en terme de ses interactions avec
ces partenaires. Un partenaire peut fournir des services au processus, nécessiter des services des processus, ou encore, participer à l’interaction avec le processus[39].
Le modèle BPEL4WS permet la description des processus métiers en deux aspects :
¾ Un processus exécutable : qui décrit le comportement actuel d’un participant dans une interaction métier.
¾ Un processus abstrait : un processus métiers abstrait comprend des descriptions pour les protocoles métiers pour définir les messages échangés sans révéler le comportement interne.
Remarque : Une nouvelle version du BPEL, a été publiée le 31 Janvier 2007, appelé WS- BPEL v2.022.
7.4 Business Process Modeling Language (BPML)
Développé par BPMI23 , la spécification BPML fournit un modèle abstrait pour l’expression des processus métiers et des entités supportées. BPML [69] définit un modèle formel pour l’expression des processus métiers abstraits et exécutables qu’adresse tous les aspects des entreprises des processus métiers, incluant les activités de complexités variées, des transactions de leur compensations, gestion des données, concurrent, gestion des exceptions et les sémantiques opérationnelles. BPML peut aussi fournir une grammaire sous forme de Schéma XML pour permettre la persistance des échanges et des définitions à travers les systèmes hétérogènes et les outils de modélisations.
7.5 Web Service Choreography Interface (WSCI)
Web Service Choregraphy Interface (WSCI) [80], co-développé par BEA, Intalio, SAP et Sun. WSCI décrit comment les opérations des services web (tel que ceux définissent par WSDL) peuvent être chorégraphiés dans le contexte d’échange de message dans lequel les web services y participent. Les interactions entre services (soit dans un contexte métier ou pas) suivent toujours et implémentent l’échange chorégraphié de message (processus). WSCI est la première étape permettant le mapping des services comme composants réalisant ces processus. WSCI décrit aussi comment la chorégraphie de ces opérations doit exposer les informations pertinentes, tel que la corrélation de message, la gestion des exceptions, la description des transactions et les capacités de la participation dynamique. Il ne suppose pas que les web services soient de différentes entreprises, comme dans le B2B ; il peut être
22 OASIS. Web Services Business Process Execution Language Version 2.0. OASIS Standard. 11 April 2007 http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html
23 Business Process Modeling Initiative (BPMI): est un consortium de standardisation. La branche BPM a fusionné avec celle de l'Object Management Group (OMG) en juin 2005 pour former Business Modeling &
Integration (BMI) Domain Task Force (DTF).
également utilisé pour décrire les interfaces des composants que représentent les unités organisationnelles internes ou d’autres applications dans une entreprise. WSCI n’adresse pas la définition de la conduite de l’échange de message ou la définition du comportement interne de chaque web service. WSCI décrit les inter-dépendences parmi les opérations des web services pour que n’importe quel client puisse:
¾ Comprendre comment interagir avec un tel service dans le contexte du processus donné.
¾ D’anticiper les comportements attendus d’un tel service à n’importe quel point dans le cycle de vie du processus.
Être capable de décrire l’interface dynamique d’un service dans le contexte d’un processus particulier qui permet de développer une forme abstraite de l’implémentation et de se focaliser sur le rôle joué des web service dans un tel processus [80].
Cependant, comme souligné par Dario Wiser, responsable du marketing produit chez Sun Microsystems « WSCI permet d'utiliser les services web au sein de processus complexes.
Pourtant, WSCI n'est pas un concurrent des dialectes existants» [80].
7.6 Web Service Choreography Description Language (WS-CDL)
En 2004, la convergence de WSCI24 et le WSCL25 a donné lieu au Web Services Choreography Description Language (WS-CDL) [49]. WS-CDL est un langage de description de la chorégraphie de web services qui se base sur le langage XML. Ce dernier, décrit la collaboration des web service à travers les entreprises participantes. Cette collaboration définit le comportement observable commun des entreprises participantes, dont l’échange de message est ordonné et synchronisé résulte dans l’alignement de leur information partagée. Le contrat entre plusieurs participants est décrit par la chorégraphie. Cette dernière décrit la composition d’une perspective globale. WS-CDL a pour objectif d’aboutir à la composition des collaborations interopérable entre n’importe quel type de participant, sans considérer la plateforme ou le modèle de développement utilisé.
Remarque : Une comparaison entre les différents formats d’échange de BPM comprenant des langages de description des processus métiers, a été présentée dans [52] mettant en exergue les points forts et les points faibles de chacun selon des critères tels que le contrôle de flux, les rôles, les événements, les transactions, les exceptions, et les données statistiques que les auteurs ont définit.
24 WSCI: Web Service Choreography Interface.
25 WSCL: Web Service Choreography Language.
Une synthèse des standards émergeant qui illustrent la chorégraphie à travers le BPEL et WSCI est présentée dans [81].
8. La collaboration des Processus Métiers
Le développement d’une collaboration réussie nécessite de suivre des exigences chorégraphiques pour assurer la cohérence parmi les processus métiers individuels à travers des organisations. Il nécessite aussi de rencontrer les exigences organisationnelles pour assurer que chacun des processus métiers des organisations s’exécute selon des règles métiers et se conforme à ce qui est spécifié du point de vue de la collaboration [63].
Une collaboration entre entreprises requiert un mécanisme qui permet aux entreprises participantes d’approuver la description du processus métier commun et des données à être échangées durant l’exécution du processus [59].
La collaboration entre entreprises au niveau processus métier se définit en trois étapes ([55], [61], [60], [63] et [64]):
1ère étape : Définition d’un processus métier collaboratif approuvé par tous les participants.
La définition de ce dernier a été a été avancée dans [61] en apportant des extensions à la définition de base du processus :
- Un processus collaboratif comporte une liste de rôle de processus qui indique la logique des participants.
- Un nœud de travail qui représente une tache associée à une activité, i-e une partie du travail qui contribue à l’accomplissement du processus, doit correspondre à un rôle dans le processus. Une activité a également un rôle appelé rôle de l’activité. Cette notion de rôle d’activité existe dans les spécifications des processus métiers.
2ième étape : Identification des processus métiers publics dans le processus collaboratif au niveau de chaque participant.
3ième étape : Mise en correspondance des processus publics avec les processus privés de chaque participant.
Différentes topologies de la collaboration métier ont été présenté par Paul Grefren [62]:
1. Collaboration Horizontale : une collaboration de nature pair-to-pair (P2P), qui est représentée par la formation d’une coopération dynamique de réseaux métiers dans lesquels les partenaires implémentent les fonctions centrales des affaires.
2. Collaboration Verticale : se base sur le paradigme d’ « Outsourcing » ou d’externalisation, des processus métiers, en délégant des activités métiers secondaires à des fournisseurs de services qui sont spécialistes.
