Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le








télécharger 75.86 Kb.
titreAnnuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le
date de publication24.10.2016
taille75.86 Kb.
typeAnnuaire
ar.21-bal.com > droit > Annuaire
. Architecture orientée service
1.1. Introduction

Les systèmes d’information ont besoin de supporter les changements dans la gestion de l’entreprise de façon rapide et efficace, et de s’adapter au développement rapide des technologies. La majorité des systèmes d’information d’entreprise sont hétérogènes, contiennent une gamme de différents systèmes, d’applications, de technologies, et d’architectures [01].

Pour gérer les problèmes liés aux changements des besoins, au développement technologique, et à l’intégration, différentes solutions ont été proposées et utilisées a travers le temps mais ces solutions ont plus ou moins échoué [01]. L’architecture SOA (Service Oriented Architecture) est venue combler certains vides laissés par ces technologies.

On va d’abord définir ce qu’est une architecture avant de définir ce qu’est SOA :

Une architecture logicielle décrit les composants du système et la manière dont ils interagissent [02].
1.2. Définition

SOA est un style architectural qui permet de construire des solutions d’entreprises basées sur les services [03].

Le service est une action exécutée par un fournisseur à l'attention d'un client, cependant l'interaction entre client et fournisseur est faite par le biais d'un médiateur (qui peut être un bus) responsable de la mise en relation des composants [04].

L’aspect le plus important de l’architecture SOA selon [02] est qu’elle permet de séparer l’implémentation du service de son interface.
1.3. Les composants de la SOA

Le paradigme "découvrir, interagir et exécuter" comme montré dans la figure 1.1, ce paradigme permet au consommateur du service (client) d’interroger un annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors il renvoie au client le contrat du service voulu ainsi que son adresse. SOA consiste en quatre entités configurées ensemble pour supporter le paradigme découvrir, interagir et exécuter [02].



Figure 1.1 Le paradigme "découvrir, interagir et exécuter" [02]
1.3.1. Le consommateur de service

Le consommateur de service est une application qui requière un service. C’est l’entité qui initie la localisation du service dans l’annuaire, interagit avec le service à travers un protocole et exécute la fonction exposée par le service [02].
1.3.2. Le fournisseur de service

Le fournisseur de service est une entité adressable via un réseau, il accepte et exécute les requêtes venant d’un client [02].

Le fournisseur de service publie le contrat de service dans l’annuaire pour qu’il puisse être accédé par les clients [02].
1.3.3. L’annuaire de service

L’annuaire de service est un annuaire qui contient les services disponibles. C’est une entité qui accepte et sauvegarde les contrats du fournisseur de service et présente ces contrats aux éventuels clients [02].
1.3.4. Le contrat de service

Le contrat spécifie la manière dont le client de service va interagir avec le fournisseur de service. Il spécifie le format de la requête et la réponse du service [02].

2. Les web services
2.1. Introduction

D’après la définition, SOA est une approche architecturale qui ne fait aucune hypothèse sur la technologie de mise en œuvre. En particulier, l’amalgame souvent faite entre SOA et les web services est une erreur [05].

Cependant, la conception des spécifications Web services a été menée dans l’objectif de répondre au mieux aux enjeux de l’architecture SOA [05]. Les web services fournissent les bases technologiques nécessaires pour réaliser l’interopérabilité entre les applications en utilisant différentes plateformes, différents systèmes d’exploitation et différents langages de programmation [06].
2.2. Définition

Un web service est une application logicielle identifiée par une URI, qui possède une interface publique définie en utilisant XML. Sa définition peut être découverte par d’autres systèmes. Ces systèmes peuvent interagir avec le web service selon la manière prescrite par sa définition, en utilisant des messages basés sur XML et portés par des protocoles internet [07].
2.3. Les standards des web services

L’objectif de cette section est le parcours des différentes spécifications des Web services. Ces spécifications pourront être mises en œuvre dans le cadre d’une architecture SOA basée sur les Web service [07].

On va présenter les spécifications de base des Web services : SOAP, WSDL, UDDI.
a- SOAP

SOAP est un protocole basé sur XML, qui permet aux applications d’échanger des informations à travers HTTP [07] :

  • SOAP est l’acronyme de Simple Object Access Protocol

  • SOAP est un protocole de communication

  • SOAP sert à la communication entre les applications (clients et services)

  • SOAP est un format d’envoi de messages

  • SOAP est conçu pour la communication à travers internet

  • SOAP est indépendant de toute plateforme

  • SOAP est indépendant de tout langage

  • SOAP est simple et extensible

  • SOAP permet d’éviter les difficultés causées par les pare-feux

  • SOAP est un standard du W3C



Objectifs de SOAP

Les applications actuelles communiquent en utilisant les appels aux procédures à distance (RPC) entre les objets comme DCOM ou CORBA, mais HTTP n’a pas été désigné pour cela. RPC représente un problème de compatibilité et de sécurité; les pare-feux et les serveurs proxy vont normalement bloquer ce genre de trafic.

Une meilleure façon de communiquer entre les applications c’est en utilisant HTTP, car http est accepté par tous les navigateurs web ainsi que tous les serveurs. SOAP a été créé pour atteindre ce but.

SOAP fournit un moyen de communication entre des applications exécutées sur différents systèmes d’exploitation, avec différentes technologies et différents langages.
Syntaxe de SOAP

Un message SOAP est un document XML ordinaire qui contient les éléments suivants :

  • L’élément Envelope qui identifie le document XML comme étant un message SOAP

  • L’élément Header qui est optionnel et qui contient des informations d’entête

  • L’élément Body qui contient l’appel ainsi que la réponse retournée

  • L’élément Fault qui est optionnel et qui fournit des informations sur d’éventuelles erreurs survenues lors de l’analyse du message

Tous ces éléments cité ci-dessus sont déclares dans les namespace de l’enveloppe SOAP :

http://www. w3.org/2001/12/soap-envelop

Et le namespace pour le SOAP encoding et les types de données :

http://www.w3.org/2001/12/soap-encoding

Squelette d’un message SOAP


L’élément Envelope

Cet élément est la racine de tout message SOAP, il définit le document XML comme étant un message SOAP.

Noter l’utilisation du namespace xmlns:soap. Il doit toujours avoir la valeur :

http: //www. w3.org/2001/12/soap-envelop

Et il définit l’enveloppe comme étant une enveloppe SOAP.


Le namespace xmlns : soap

Un message SOAP doit toujours avoir un élément Envelope associé au namespace : http ://www. w3.org/2001/12/soap-envelop

Si un autre namespace est utilisé, l’application doit générer une erreur.

L’attribut encodingStyle

Cet attribut est utilisé pour définir les types de données utilisés dans le document. Cet élément peut apparaître dans n’importe quel élément SOAP, et il sera appliqué au contenu de cet élément ainsi que tous ses éléments fils. Un message SOAP n’a pas d’encodage par défaut.
Syntaxe


Exemple


L’élément Header

C’est un élément optionnel et contient des informations spécifiques à l’application (par exemple des informations sur l’authentification) sur le message SOAP. Si cet élément est présent, il doit être le premier fils de l’élément Envelope.
Note Tous les éléments fils de l’élément Header doivent être qualifiés par un namespace.




Dans l’exemple ci-dessus l’élément header a l’élément Trance comme fils qui a la valeur 234 et l’attribut mustUnderstand de valeur 1.

SOAP définit trois attributs pour l’élément Header. Ces attributs sont actor, mustUnderstand, et encodingStyle. Les attributs définis dans l’élément Header indiquent comment le récepteur doit traiter le message SOAP.
L’attribut actor 

Un message SOAP parcourt un chemin du l’émetteur vers le récepteur en passant par différents points (endpoints). L’attribut actor peut être utilisé pour adresser l’élément header à un endpoint particulier.
Syntaxe


Exemple


L’attribut mustUnderstand

Cet attribut indique si l’élément header doit être traité ou pas par le récepteur.

Syntaxe



Exemple


L’élément SOAP Body

Cet élément contient le message envoyé au récepteur. Le fils de l’élément Body peut être qualifié par un namespace.
Exemple


L’élément SOAP Fault

Un message d’erreur est porté par cet élément. Si un élément Fault est présent, il doit apparaître comme étant fils de l’élément Body. Un élément Fault ne peut apparaître qu’une seule fois dans un message SOAP.

L’élément Fault a les éléments fils suivants :


Les codes des erreurs

Pour décrire une erreur l’élément faultcode utilise les valeurs suivantes dépendamment de l’erreur qui s’est produite :

b- WSDL

WSDL est un langage basé sur XML utilisé pour décrire les web services et comment les accéder [07] :

  • WSDL est l’acronyme de Web Service Description Language

  • WSDL est écrit en XML

  • WSDL est un document XML

  • WSDL est utilisé pour décrire les web services

  • WSDL est un standard du W3C


WSDL décrit les web services

Le document décrit le web service. Il spécifie la localisation du web service et les opérations (méthodes) qu’expose ce web service.
WSDL est une recommandation du W3C

WSDL est devenu une recommandation du W3C en Juin 2007.

La structure d’un document WSDL

WSDL décrit un web service en utilisant ces principaux éléments :


  • Services 

Cet élément définit une collection d’adresses permettant d’invoquer un service. Il sert à regrouper un ensemble de points de communication. En général ; il correspond à une URL invoquant un service SOAP.


  • Ports 

Cet élément définit un point de communication unique avec l’adresse réseaux à laquelle elle est liée.


  • Port types 

Cet élément définit de manière abstraire une collection d’opérations ou d’actions, chaque opération est déclenchée par une requête, puis génère une réponse.


  • Opérations

Cet élément définit de manière abstraire une action supportée par le service Web.


  • Binding (liaison)

Cet élément spécifie de manier concrète le protocole de communication (exemple : SOAP1.1, HTTP, MIME (Multipurpose Internet Mail Extension), …) et le format des donnés pour les opérations et messages définit par un type de port particulier. WSDL possède des extensions internes pour définir des services SOAP ; de fait, les informations spécifiques à SOAP se retrouvent dans cet élément.



  • Types 

Cet élément décrit de manière abstraire tous les types de données échangées. Cette description n’est pas liée à un système spécifique de typage, mais utilise par défaut la spécification XML schéma.
La structure principale d’un document WSDL ressemble à :


Types d’opérations

L’opération de type requête/réponse est la plus commune mais il ya d’autres types :


c- UDDI

Initialement définie par Ariba, IBM et Microsoft, UDDI est un protocole d’annuaire permettant aux entreprises de publier et de découvrir, d’une manière standard, des informations relatives aux fournisseurs et aux types de services qu’ils proposent. Ainsi, les clients peuvent savoir quels sont les services fournis par chaque fournisseur et les concepteurs de logiciels clients peuvent apprendre ce qu’ils ont besoin de connaître pour créer ces clients .UDDI est une technologie qui s’articule autour des protocoles HTTP et SOAP, ainsi que du langage XML. Les spécifications UDDI définissent les types d’annuaire de services Web distribues : pages blanches (nom de l’entreprises, adresse, contacts), pages jaunes (services classés par catégories industrielles) et pages verts (information d’implémentation des services Web proposes). Ainsi, UDDI se présente comme un ensemble de bases de données utilisées par les entreprises pour enregistrer leurs services Web ou pour localiser d’autres services Web. Grâce à UDDI, les entreprises peuvent enregistrer des données les concernant, des renseignements sur les services qu’elles offrent et des informations techniques sur le mode d’accès à ces services. Une fois l’enregistrement terminé, les informations sont automatiquement répliquées sur l’ensemble des annuaires. Ce fonctionnement permet aux services d’être découvert par un plus grand nombre d’entreprises [09].
Les types de données UDDI :

L’XML schéma d’UDDI fournit 4 éléments obligatoires pour accéder et utiliser un Web service [08] (voir la figure ci-dessous)


nom,description,

URL :pointeur vers des specifications

information sur des Relations entre deux entreprises

Figure 1.2 Structure des informations dans UDDI [08]


  • L’entité commerciale :< BusinessEntity >

Cet élément est la racine du document UDDI décrivant l’enregistrement du ou des web services d’un même fournisseur. Il contient l’identité de ce dernier, son adresse physique et électronique ainsi que des qualifications ou des mots-clés faisant référence aux taxonomies industrielles standards [10].


  • La description des services :

A l’intérieur de l’élément précédent, les services proprement dits sont délimites par la balise businessService. chacun de se sous éléments contient pour l’essentiel le nom et la description du service, sa catégorie dans une taxonomie propre à UDDI, des clés de recherche et des pointeurs vers des classes de liaisons (bindingTemplates) [10].


  • La liaison UDDI :

Comme dans WSDL, la liaison UDDI regroupe, pour un protocole de communication donné, les données techniques nécessaire à l’exploitation du web services par un programme : adresse IP, noms de domaines et le cas échéant, des informations sur les modalités d’usage du service (hébergement, paramétrage initial, et.). Un même service peut disposer de plusieurs points d’accès, par exemple, selon des protocoles différents (SOAP, SMTP…) [10].


  • Les modèles données :

Le model est une structure « creuse » qui est utilisée dans la description des entités commerciales comme référence à un autre document décrivant un modèle de données ou toute autre information nécessaire aux requêtes de recherche et aux interactions avec l’entité commerciale considère. Dans le cas courant de l’enregistrement d’un web service, par exemple, le tmodel pointera, en général, vers le document WSDL décrivant l’interface publique du service. plus généralement, le tmodel peut renvoyer à d’autres documents spécifiant par exemple, les conventions employées dans les échanges ou bien encore les taxonomies industrielles les attributs peuvent faire référence, etc. [10].
Processus métiers et Workflows
1.1. Introduction

Les processus métiers occupent une place centrale dans la mise en œuvre et l’évolution des systèmes d’informations et constituent le plus souvent le socle de construction. En effet, la maîtrise des processus métiers est un des points clé pour la réussite des projets [09].

De nos jours l’utilisation croissante des systèmes de gestion de workflows dans les entreprises exprime leur importance indéniable comme outil d’automatisation du processus métier, les systèmes de gestion de workflows sont parmi les systèmes les plus élaborés pour définir et exécuter des processus métiers. Ils permettent en particulier de décrire explicitement les méthodes de travail réalisant un processus métier de les expérimenter et de les optimiser afin de pouvoir assurer l’amélioration et la réutilisation des processus. Pendant la dernière décennie, les systèmes de gestion de workflows offrent un fort potentiel de modélisation et d’automatisation. Si un processus permet de décrire d’une manière informelle les méthodes de travail d’un groupe de personnes et les règles qui les régissent, un workflow permet de formaliser, de structurer, d’automatiser et d’exécuter ces méthodes de travail [09].

Les entreprises ont jusqu'à présent déployé leurs processus métier en silo c'est-à-dire de manière fonctionnelle et elles se rendent compte aujourd’hui que ces processus doivent être partagés dans les différents départements de l’entreprise et inter-entreprise [09].

Nous présenterons dans ce chapitre les concepts généraux inhérents aux processus métiers, leurs systèmes de gestion et leurs caractéristiques, puis les systèmes workflow et les étapes essentielles pour réaliser un workflow. Plus tard, on ferra une présentation de la composition des web services et l’utilisation de BPEL.
1.2. Généralités sur les processus métiers et les workflows

Le concept de processus peut être utilisé dans des contextes hétérogènes pour des finalités extrêmement variées. On assiste aujourd’hui à une véritable convergence vers ce concept de processus indépendamment du domaine, les points de vue ne sont pas exclusifs mais complémentaires. Le fais de parler de processus impliquera que l’on s’intéresse aux activités qui le composent, à sa finalité, à certaines ressources qu’il consomme. Sur cette base, chaque spécialité appose son filtre qui permettant de ne retenir que ce qui lui semble pertinent [13].

1. Processus métier et système de gestion des processus métiers 

a- Notion de processus et processus métier

Plusieurs définitions du terme processus sont présentées dans la littérature. Il est vrai que cette notion est suffisamment générale pour être utilisée dans différents domaines scientifiques ou applicatifs. L’étude de ces définitions permet d’avoir une idée claire de ce qui est désigné par un «processus».

Nous définissons un processus d’une entreprise en tant qu’enchaînement d’activités interactives. Un processus reçoit des objets en entrée, il va les manipuler par le moyen de ressources, tout en fournissant des objets en sortie (produits/services) remplissant les besoins et les exigences d’un client (atteindre les objectifs) interne ou externe à l’entreprise. Il ne peut être déclenché que par des événements internes et/ou externes à l’entreprise, c'est-à-dire des changements d’état des composants du système. Chaque processus est en communication avec d’autres et peut être décomposé en sous-processus. Une activité transforme des entrées en sorties par l’influence d’objets de contrôle et en utilisant les ressources requises et disponibles pendant une durée bien définie [09].

Le terme processus métier est une traduction française de la notion de business process, et on peut trouver plusieurs synonymes de ce mot tel que : processus d’affaire, processus opérationnel et processus d’entreprise.

On peut définir le processus métier comme suit : un processus est un ensemble d’activités, une activité est un ensemble de taches, et une tache est une opération élémentaire.

Les conditions de lancement d’une instance de processus sont liées aux événements de son environnement [09].
- Les activités

De nombreux modèles et représentations graphiques permettent de représenter les réseaux d’activité qui composent les processus (réseaux de pétri, state charts, graphes de précédence,…).

Une activité est caractérisée par une fonction qui transforme un flux d’objets entrant en un flux d’objets sortant dès lors qu’un ensemble de prè-conditions est satisfait et sous réserve de disponibilité de ressources et de temps. La modélisation de l’entreprise par les processus est récursive en ce sens qu’une activité peut à son tour être considérée comme un processus.

Une activité correspond à la réalisation d’une tâche ou d’un service, éventuellement sous forme d’un ensemble d’opérations, par un pool de ressources : homme, machine, application informatique. Les principales fonctions associées à une activité ont pour but de transporter, transformer, contrôler, stocker un flux entrant sous forme de matière, d’information, d’énergie ou de ressource sous contrôle de paramètres.

Les conditions de lancement d’une activité sont liées aux contraintes de succession décrites par la structure du réseau d’activités. Dans ce cas, nous trouvons l’hypothèse que chaque instance d’une activité peut se trouver dans un des états suivants [14] :

  • à exécuter : une demande ou prévisionnelle est à satisfaire mais les conditions de lancement ne sont pas remplies,

  • exécutable : une demande effective ou prévisionnelle est à satisfaire, les conditions de lancement sont remplies, l’activité n’est pas lancée,

  • en cours : sa date de début est antérieure à l’instant courant, elle est ni bloquée, ni abandonnée, ni terminée,

  • bloquée : son exécution est suspendue en attente d’une décision,

  • abandonnée : suite à une anomalie, l’exécution de l’instance n’est pas poursuivie,

  • terminée : sa date de fin est antérieure à l’instant courant, le responsable ayant validé son exécution.

Le diagramme suivant illustre le changement d’état d’une activité :



Figure 2.1 Diagramme d’états-transitions pour une instance d’activité [14].
- Les événements

Pour un processus ou une activité, un événement correspond à un changement d’état.

Dans les processus d’entreprise, de nombreuses activités sont réalisées par des ressources techniques [09].

L’activité humaine se positionne sur les opérations de contrôles et de décision pour lesquelles l’individu doit gérer l’occurrence des événements dont une partie n’est ni prévue, ni programmée. Le diagramme d’états-transitions de la figure 2.1 (formalisme UML/ Unified Modeling Language) présente l’enchaînement des différents d’états d’une activité et les contraintes d’ordonnancement entre ces états [09].
b- Système de gestion des processus métiers

Le GPM (traduction de BPM/Business Process Management) est une approche globale de la gestion des processus d’entreprise. Le GPM couvre la modélisation, l’information, l’exécution, l’administration et l’optimisation des processus d’entreprise. Un modèle GPM comporte les mécanismes d’identification, de description et de gestion des processus métiers de l’entreprise [09].

Un système de gestion de processus métier SGPM (traduction de BPMS/Business Process Management System) est une plate forme logicielle de production pour modéliser, informatiser, déployer, exécuter, superviser, contrôler et optimiser les processus d’une organisation [09].

Parmi les principes de GPM, il y a deux concepts utiles qui sont : l’orchestration et la chorégraphie qu’on définira plus tard.
2. Catégorisation des processus

Les processus métiers peuvent être classés dans un espace à deux dimensions (voir la figure 2.2) suivant le temps nécessaire à l’exécution complète du processus et suivant la complexité de celui-ci (de simple et directe à hautement complexe). A partir de ce classement, il ressort trois catégories bien distinctes de processus métier : processus à processus, personne à processus et enfin personne à personne. Le passage d’une catégorie à l’autre s’accompagne d’une augmentation du temps nécessaire et d’une complexification du processus. Une démarche GPM complète devrait englober les trois catégories de processus puisqu’ils jouent un rôle approprié et nécessaire dans l’entreprise. Actuellement une telle solution GPM nécessite la combinaison de plusieurs produits GPM du marché car ceux-ci sont encore trop spécialisés [16].


Figure 2.2 Catégorisation des processus [09].
a- Processus à processus

Dans la majorité des cas, les processus appartenant à cette catégorie sont peu complexes et ne durent que très peu de temps. Il s’agit de processus discrets qui se concentrent sur des transformations de données. Leur but est de transférer un objet business d’une application vers une autre. Ce qu’il faut, c’est définir la logique business de transformation de ses objets business [09].
b- Personne à processus

Les interactions personne à processus découlent le plus souvent d’un processus de type transactionnel comme une demande de validation ou la résolution d’une exception dans une tâche automatisée. Pour cette raison, ce type de processus est très répétitif avec peu de différences entre les différentes instances du processus. Ces processus sont souvent basés sur des états, impliquent des interactions personnes à processus à des étapes spécifiques alors que les autres étapes sont automatisées. Un exemple serait l’acceptation d’accorder un crédit lors d’une vente [09].
c- Personne à personne

Les processus de type personne à personne relient les employés d’une entreprise dans un but collaboratif comme par exemple le processus de développement de nouveaux produits.

La planification des ressources est centrée sur des processus et des connaissances explicites alors que la gestion des projets est plus guidée par des connaissances tacites.

2. Composition des web services

Dans cette section nous allons présenter la composition des web services et voir sa relation avec les processus métiers, ensuite on présentera le langage BPEL.
2.1. Composition des web services

Nous avons vu que les services fournissent des opérations, donc pour atteindre l’objectif de la SOA, les services doivent pouvoir être composés en des services plus complexes. On les compose jusqu’à ce que le service résultant fournisse un support entier pour les processus métiers. Les processus métiers sont ainsi définis dans le contexte de la composition des web services, comme étant une collection d’activités à travers lesquelles les services sont invoqués [01]. Pour le monde extérieur c'est-à-dire du point de vu client, un processus métier est vu comme n’importe quel autre service. Avec la composition, on peut utiliser des services fournis par d’autres partenaires dans nos processus [01].

La composition des services en des processus métiers nécessite la définition d’activités qui collaborent et aussi la définition des échanges de messages entre les web services impliqués [01]. WSDL fournit une description basique et une spécification des messages échangés, mais cette description ne permet que de décrire de simples interactions entre le client et le web service, ces interactions peuvent être sans états (stateless), synchrones, ou asynchrones. Ces relations sont inadéquates pour décrire des compositions complexes de plusieurs web services qui consistent souvent en des échanges de messages dans un ordre bien défini. Dans ce type de compositions, les messages synchrones et asynchrones peuvent être combinés et les interactions sont assez longues. Un autre aspect important est la capacité de décrire la façon dont les erreurs sont traitées. Etant donné les limitations de WSDL, il nous faut un mécanisme pour décrire la composition des web services en des processus plus complexes [01].

La composition de services en des processus métiers peut être réalisée en utilisant un des langages de programmation bien connus (Java, C#,...), mais le problème est que la composition de services diffère un peu de la programmation classique [01]. Avec la composition, on fusionne les fonctionnalités (services) en des services et des processus plus complexes. En d’autres termes on fait de la programmation de haut niveau [01]. Cette programmation signifie la représentation de la logique de transition d’état du système. Si on utilise les langages de programmation tels que Java, C#, etc., pour la composition on aura des solutions inflexibles, car il n’y a pas de séparation claire entre le flux de processus et la logique métier [01].

En plus de ces faits, la composition de services a d’autres exigences, comme le support de plusieurs instances de processus, des processus qui ont un temps d’exécution assez long, etc.

Tout ça, fait que l’utilisation de technologies dédiées à la composition est une chose indispensable [01].
2.2.3. Orchestration et Chorégraphie

Dépendamment des besoins, la composition des web services peut être faite en utilisant l’une des deux méthodes :

  • Orchestration

  • Chorégraphie


a- Orchestration

Un processus central (qui peut être un autre web service) prend le contrôle sur les web services impliqués et coordonne l’exécution des différentes opérations sur ces web services. Ces derniers ne savent pas (et n’ont pas à savoir) qu’ils sont invoqués dans une composition et qu’ils sont une partie d’un processus métier complexe. Seul le coordinateur central de l’orchestration le sait. Donc l’orchestration est centralisée avec des définitions explicites des opérations et l’ordre d’invocation des web services. L’orchestration est utilisée dans les processus métiers privés et est schématiquement décrite dans la figure 2.3 [01].


Figure 2.3 La composition des web services en utilisant l’Orchestration [01]
b- Chorégraphie

D’autre part on peut ne pas compter sur un coordinateur central. Au lieu de cela, chaque web service impliqué dans la chorégraphie sait exactement quand exécuter ses opérations et avec qui interagir. La chorégraphie est un effort de collaboration focalisé sur l’échange de messages dans des processus métiers publiques. Tous les participants à la chorégraphie doivent savoir leurs rôles dans le processus métier, les opérations à exécuter, les messages à échanger, et le temps d’échange de ces messages. La chorégraphie dans la composition des web services est montrée par la figure 2.4 [01].


Figure 2.4 La composition des web services en utilisant La chorégraphie [01]

Du point de vue de la composition des web services, pour exécuter des processus métiers, l’orchestration a un avantage sur la chorégraphie, parmi ces avantages :

  • On connaît de façon exacte qui est le responsable de l’exécution du processus métier en entier.

  • On peut incorporer les web services, même ceux qui ne savent pas qui sont impliqués dans des processus métiers.

  • On peut aussi fournir un scénario alternatif quand il y a des erreurs.

similaire:

Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le iconPar André-Michel berthoux
«a fire hose nozzle», disent les habitants de la ville (photo 1). C’est alors que Scottie lui répond : «c’est bien la première fois...

Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le iconDell™ elargit son offre entreprise en integrant la technologie double...
«Data Center Environment Assessment», une nouvelle offre de service technique qui aide les clients à planifier et à utiliser efficacement...

Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le iconAnnuaire d’entreprise
«time part» : Rédaction de spécifications fonctionnelles pour différents projets de sites marchands

Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le iconMarche public de service a procedure adaptee : avis de publicite et
«Choix de l’offre économiquement la plus avantageuse» pondéré par les critères suivants

Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le iconAnnuaire électronique 35

Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le iconAnnuaire électronique 42

Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le iconAnnuaire électronique 30

Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le iconL'Annuaire des Coachs

Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le iconChristian Pattyn a été directeur régional des Affaires culturelles...
«Santa-Maria de la Victoria» (qui commémore la victoire de Aljubarrota du 15 août 1385 qui assura au Portugal son indépendance) avec...

Annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel service, alors IL renvoie au client le iconAnnuaire saytara de septembre 2011








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com