Instructions: Réalisation de service - services BPEL dans une application SOA
Ces instructions décrivent une application construite à l'aide d'une chorégraphie à base de langage BPEL et de style Architecture SOA.
Relations
Description principale

Introduction

Ces instructions décrivent une application construite à l'aide la chorégraphie BPEL et de style Architecture SOA. Les leçons tirées des phases de conception et de développement de ce projet apportent des connaissances générales pour les autres phases concernant la chorégraphie à base de langage BPEL dans une architecture SOA. L'approche de conception est évaluée par une comparaison des avantages et des inconvénients concernant les exigences métier et les éléments d'application existants. Cette page contient des recommandations relatives à la conception et identifie les caractéristiques suggérant l'utilisation d'une approche guidée par le langage BPEL.

Leçons tirées de l'expérience

  1. Il est parfois difficile, mais toujours primordial, de choisir la bonne segmentation de logique métier entre l'enchaînement d'activités et les services partenaires.

    La logique métier se partage entre la chorégraphie à base d'enchaînement d'activités et les services partenaires. Les services partenaires doivent être responsables des logiques complexes ou entraînant de nombreux calculs, tandis que la chorégraphie doit contenir la logique devant changer en fonction des changements des exigences métier.

    Cette séparation n'étant pas toujours aussi nette, une bonne stratégie pour y remédier est de concevoir l'application de façon à ce qu'elle s'étende en modifiant l'enchaînement d'activités et en ajoutant de nouveaux services partenaires, plutôt qu'en modifiant des services partenaires existants.

    Il s'agir d'une approche itérative. Il est probable que les premiers prototypes nécessitent une restructuration des services partenaires afin d'avoir une conception pouvant évoluer grâce à l'ajout de nouveaux services partenaires.

    Dans tous les cas, vous devez bien entendu conserver le code superflu ou ne changeant jamais en dehors de l'enchaînement d'activités.

  2. Optimiser les fonctions uniques du langage BPEL

    Le langage BPEL a la capacité d'orchestrer les services partenaires qui exposent différentes variétés d'associations.

    Veillez à ne pas construire de dépendances sur les caractéristiques de l'implémentation particulière d'un partenaire ou sur l'association d'un service de partenaire. Cela rendrait plus complexe ou limiterait les changements ultérieurs apportés à la chorégraphie ou à l'application en général.

    Pensez à conserver des résultats intermédiaires sur les variables BPEL pour les utiliser afin d'améliorer les performances.

  3. Lorsque cela est possible, concevez les services partenaires sans état avec des opérations idempotentes.

    Dans le cadre de ces instructions, l'idempotence signifie simplement qu'un service peut être appelé avec les mêmes données d'entrée plusieurs fois et en s'attendant à ce que la réponse soit correcte à chaque appel. Cette caractéristique peut grandement simplifier les choses pour l'appelant et pour le service car elle rend l'interaction beaucoup plus simple. La correction d'erreurs, le redémarrage après incident et le changement d'échelle grâce à la classification se trouvent simplifiés. Pour l'appelant, la correction d'erreurs du réseau et les problèmes de serveur et de client sont simplifiés. L'idempotence est un indicateur clé concernant une bonne association pour une chorégraphie BPEL des services partenaires.

    Bien sûr, si des interactions plus complexes sont requises, les protocoles des services Web incluent des fonctions de compensation pouvant alors être employées. De la même façon, si vous pouvez éviter ce type d'exigences pour la conception générale de l'application, le résultat sera plus facile à conserver et à tester.

L'étude de cas

Cette étude de cas décrit un projet IBM visant à mettre à niveau la technologie de l'information utilisée par son programme ServicePac®. L'objectif de ce projet était de réduire les points problématiques et d'utiliser le programme ServicePac® pour l'expansion continue, aussi bien au niveau du volume que des fonctions.

Comme beaucoup de programmes ayant du succès, le ServicePac IBM® a connu des transitions incrémentielles, à commencer par la transformation de nombreux programmes de garanties en trois entités organisées géographiquement. Ensuite, des opérations distinctes géographiquement ont été réunies en une seule opération mondiale. Au fil des années, le programme ServicePac® a continué à proposer de nouvelles offres, comme des services d'installation et des offres pour prendre en charge du nouveau matériel IBM. Bien que le programme ServicePac® soit lui-même une opération mondiale, ses produits, les ServicePacs®, sont vendus par de nombreuses lignes IBM et par de nombreux partenaires commerciaux. Chaque organisation commercialisant ces produits a son propre système de saisie des commandes personnalisé en fonction de son secteur d'activités (et pas des ServicePacs®). Ces systèmes représentent une véritable énumération des différentes technologies élaborées à différents moments par différentes équipes.

Les systèmes de saisie des commandes qui gèrent les ServicePacs® doivent procéder à des confirmations au moment de l'entrée des commandes d'après les exigences développées par le programme ServicePac®. La confirmation de ServicePac peut être complexe. Les ServicePacs® sont vendus dans plus de cent pays et les offres ne sont pas les mêmes partout. Les offres ServicePac® dépendent du modèle du produit, du pays où il est livré, du canal de distribution, du système de saisie des commandes et des informations relatives au client, comme les ServicePacs® qu'il possède déjà.

Habituellement, la confirmation de la commande ServicePac® est réalisée dans le système de saisie des commandes, n'implémentant que les exigences de confirmation nécessaires pour les canaux de distribution pris en charge par ce système. Le programme ServicePac® s'étant beaucoup développé, le coût entraîné par le fait de communiquer les exigences de confirmation, de coordonner leur développement, leur test et leur déploiement est devenu beaucoup trop élevé. De plus, trouver la confirmation de la commande appropriée dans les systèmes de commande a beaucoup augmenté le temps d'accès au marché pour les nouvelles offres.

Image illustrant une approche orientée services pour la confirmation de commande.

Figure 1 - Approche orientée services pour la confirmation de commande du services ServicePac®. Le but est de créer un service disponible unique pour tous les systèmes de saisie des commandes ServicePacs®, plutôt que de mettre au point une logique de confirmation spécifique pour chaque système de commande.

Une approche orientée services pour la confirmation

Au départ, il semblait que la confirmation devait être sous la responsabilité du programme ServicePac®, et non des systèmes de ventes individuels au travers desquels les ServicePacs® sont commandés. Les deux choix envisagés étaient soit de distribuer à tous les systèmes de commande le code qui encapsulait les exigences de confirmation de la commande, soit de fournir un service centralisé de confirmation des commandes. Eviter les questions de gouvernance associées à l'approche de distribution de code fut déterminant dans le choix de l'approche des services centralisés.

L'avantage majeur représenté par le fait d'exposer la confirmation des commandes comme un service pour commander les systèmes de saisie des commandes est que ces derniers n'ont plus besoin d'implémenter, de tester ou de lancer localement leur propre logique de confirmation des commandes ServicePac®. La préoccupation (ou l'inquiétude) principale provient des différents propriétaires de système de saisie des commandes qui ont à présent une dépendance d'exécution sur un système externe dirigé par une autre organisation. Comme vous l'apprendrez plus tard dans ce document, le bénéfice entraîné par le fait de proposer la logique de confirmation comme service a rapidement fait disparaître ces craintes.

Voici un rapide résumé des objectifs architecturaux du projet :

  1. Conception de l'interface : l'interface de confirmation doit être conçue de manière à gérer correctement l'évolution anticipée de l'entreprise (par exemple, des nouveaux produits ne devraient pas, de manière générale, entraîner de modifications de l'interface).

  2. Indépendance du protocole de messagerie : le service de confirmation doit être accessible indépendamment de la plateforme d'appel, du modèle de programmation, de la couche de transport par réseau ou des choix matériels.

  3. Flexibilité du métier : la logique de confirmation a été implémentée pour rendre les changements métier anticipés sûrs, peu coûteux et rapides, sans pour autant faire baisser les performances, la fiabilité ou compromettre les règles de conception fondamentales.

  4. Evolutivité : de meilleurs rendements ne doivent pas impliquer de reprogrammation ou de tests fonctionnels importants.

Conception de l'interface

En collaborant avec le propriétaire métier et les architectes métier de toutes les parties qui gèrent la nomenclature des produits, une taxinomie non contradictoire et bien documentée a été développée pour les produits actuels et futurs. D'après cette taxinomie, un modèle de données en langage XML a été développé. Il indique tous les types de produits nécessaires, ainsi que leurs attributs. A mesure que de nouveaux produits sont proposés, la taxinomie peut changer. Cependant, malgré les changements potentiels du schéma, le format de message réel est censé resté le même jusqu'à ce que les nouveaux produits se trouvent dans la portée de la taxinomie définie.

Cette approche donne à l'entreprise la flexibilité voulue pour introduire de nouvelles offres de manière rapide et peu coûteuse. Elle ne couvre pas, bien entendu, tous les cas possibles. Par exemple, si l'offre d'un nouveau produit a une précondition n'ayant pas été anticipée dans les définitions de messages existantes, de nouvelles définitions de messages devront être mises en place.

La charge d'un simple message de demande incluant une seule commande pour un seul ServicePac® pour l'ordinateur d'un client identifié par son numéro de référence et son numéro de série est indiquée dans la liste 1. Le format du message prend en charge les différents ServicePacs® pouvant être associés au matériel ancien et existant. Dans certains cas, les messages peuvent avoir des milliers d'éléments imbriqués.

Indépendance du protocole de messagerie

L'un des avantages de l'utilisation du langage BPEL est que les relations de messagerie entre les services sont brièvement décrites en WSDL, ce qui donne une certaine indépendance au protocole de messagerie. Pour profiter au maximum de cette fonction, il faut éviter de construire des implémentations qui dépendent de caractéristiques spécifiques du protocole de messagerie utilisé au cours du développement. Par exemple, si les liaisons Enterprise JavaBeans sont utilisées pendant le développement, le style de programmation peut donner des échanges de messages courts et saccadés (c'est-à-dire des échanges fréquents de petits messages). Si par la suite la liaison devient une liaison Java Message Service ou SOAP par le biais de HTTP, il risque d'y avoir un véritable goulot d'étranglement des performances à cause d'un temps système par message plus important pour ces protocoles. Dans ce cas, l'impact des changements de liaisons peut être limité en respectant le style de programmation dans lequel les échanges de messages ont une grande granularité (à savoir des échanges relativement peu courants de corps de message plus importants), de façon à ce que le temps système de la création de message et sa réception puissent être amortis à l'aide de davantage de données.


<?xml version="1.0" encoding="UTF-8"?>
 <spkOrderDataList>
  <header>
   <orderReference>1040-5124-001</orderReference>
   <orderDate>2004-08-15</orderDate>
   <orderingSystem>WEB</orderingSystem>
   <country>US</country>
   <distributionChannel>A</distributionChannel>
   <headerReturnCode/>
  </header>
 <spkSegmentList>
   <orderItemReference>102</orderItemReference>
   <spkPartNumber>69P9921</spkPartNumber>
   <spkType>WMAINTOPT</spkType>
   <spkQuantity>1</spkQuantity>
   <hardwareQuantity>1</hardwareQuantity>
   <spkReturnCode/>
   <hardwareSegment>
    <serialNumber>77X9182</serialNumber>
    <hardwareIdentifier>8676M2X</hardwareIdentifier>
    <hardwareReturnCode/>
   </hardwareSegment>
 </spkSegmentList>
 </spkOrderDataList>
</ServicePacData:validationRequest>

Liste 1 - Exemple d'un message simple reçu par le service de confirmation composé de la commande d'un seul ServicePac® qui sera appliqué à un ordinateur existant, identifié par son numéro de référence et son numéro de série. Le service de confirmation renvoie le message reçu en indiquant soit les codes de vérification, soit les codes d'erreur. Le composant qui appelle peut fournir ses propres numéros de référence pour pouvoir transmettre les demandes et les réponses.

Une autre question relative à l'indépendance du protocole est le style de messagerie. Dans ce projet, les besoins futurs de messagerie asynchrone seront réglés en créant des définitions de messages de confirmation avec un champ, pour le moment inexploité, pour les demandes de corrélation et les messages de réponse, même si les utilisations actuelles sont synchrones et n'ont donc pas besoin de corrélation. Régler ce type de problèmes fait généralement appel aussi bien à la conception du message qu'à celle de l'application.

Flexibilité métier

De manière générale, le service de confirmation du ServicePac® accepte une commande, puis retourne des informations indiquant si la commande est valide ou non et, le cas échéant, les raisons de l'invalidité. Cependant, le but est de réduire la reconception, le nombre de nouveaux tests et l'impact sur les performances lorsque des modifications doivent être apportées en réponse à de nouvelles exigences métier. Il est donc très utile d'avoir une idée de ce à quoi vont ressembler les nouvelles exigences lors de la conception de l'implémentation initiale.

Caractéristiques de l'implémentation initiale :

Le service de confirmation extrait les détails de la commande du ServicePac®, c'est-à-dire : les types de ServicePac®, le matériel auquel il doit s'appliquer, le lieu de livraison (pays) du ServicePac®, les canaux de distribution et les données client. La logique métier teste ensuite les informations de la commande par rapport à un ensemble d'instructions déclaratives fournies par la métier ServicePac®. L'ensemble des tests auxquels doit être soumise une commande dépend des caractéristiques de cette dernière. Certains tests doivent avoir accès à des données supplémentaires disponibles uniquement sur les systèmes éloignés.

Trois types de données sont nécessaires pour valider une commande : les données de référence que possède l'application, les données de référence placées dans la mémoire cache que possèdent les autres systèmes et les données opérationnelles devant être obtenues auprès des autres systèmes à chaque confirmation de commande.

On peut avoir accès aux données de référence que possède l'application à l'aide d'un service partenaire qui a été construit comme faisant partie de cette application. Ce service est également disponible pour les autres applications auxquelles il faut accéder pour référencer les données possédées par cette application.

On peut avoir accès aux données de référence que possèdent les autres applications à l'aide d'un service partenaire qui a été construit comme faisant partie de cette application. Lorsque cela est possible, le service partenaire met en cache les données obtenues des autres applications de façon à réduire le nombre d'accès réseau. Le fait de placer la stratégie de mise en cache dans le service partenaire permet de la modifier quand cela est nécessaire, sans nécessiter de changements dans le reste de l'application.

Les données et les résultats intermédiaires devant simplement être stockés pendant la durée de vie de la requête de confirmation sont stockés dans les variables BPEL. Les variables BPEL permettent de supprimer le temps système des accès inutiles aux services partenaires et peut donc améliorer les performances de manière générale.

Image illustrant une vue topologique de l'enchaînement d'activités entraîné par l'implémentation d'une logique métier.

Figure 2 - Vue topologique de l'enchaînement d'activités entraîné par l'implémentation d'une logique métier qui choisit les tests de calculs ou de données devant être réalisés de façon à valider une commande donnée. La même interface de service est utilisée par tous les systèmes de saisie de commande devant valider des commandes.

A ce stade commencent les recherches sur la nature de ces nouvelles exigences pouvant être tirées des discussions avec le métier et l'étude des tendances historiques.

A mesure que le programme ServicePac® se développe, de nouveaux tests métier pour la confirmation des ServicePac® sont créés. Cependant, les tests existants ne sont pas supposés changer. La validation de nouveaux produits demande l'évaluation d'un nouveau regroupement de tests existants et de nouveaux tests.

Cet ensemble d'exigences correspond bien à un système guidé par un enchaînement d'activités dans lequel l'enchaînement d'activités est utilisé pour rassembler les ensembles de tests nécessaires pour chaque type de produit. L'aspect des tests comportant beaucoup de calculs ou de données peut être développé à l'aide d'une technologie moins flexible, mais plus efficace, et avoir la forme de services partenaires disponibles pour le moteur central de l'enchaînement d'activités, comme le montre la figure 2.

Lorsque de nouvelles offres métier sont ajoutées au système de confirmation, l'enchaînement d'activités lui-même est modifié pour avoir accès aux services partenaires existants (et parfois même à de nouveaux services partenaires nécessaires pour prendre en charge les nouvelles offres). En supposant que les services partenaires ont été segmentés correctement à l'extérieur, il est possible d'ajouter de nouvelles exigences à cette architecture sans qu'elles n'entraînent de nouveaux tests et une nouvelle codification de la fonction implémentée précédemment.

Evolutivité

L'application BPEL étant déployée sur une pile middleware mature offrant pour option de configuration le clustering (classification), on est passé directement du projet de confirmation du ServicePac® à sa mise en place, facilement extensible grâce à l'ajout de nouveau matériel si nécessaire. Bien sûr, l'architecture générale des services partenaires appelant depuis un moteur d'enchaînement d'activités correspond bien au modèle de clustering.

Au niveau de la conception, ce service est idempotent car les appels vers ce service n'ont aucune conséquence sur les appelants. Il n'est donc pas nécessaire qu'un client du service procède à une correction d'erreurs si un appel du service mentionne une erreur ou ne s'achève pas. Au contraire, le client du service peut réitérer son appel en toute sécurité quand il le souhaite. Le fait que les services partenaires soient aussi idempotents simplifie grandement les facteurs associés à l'échelonnement du processus à l'aide du clustering, car la correction d'erreurs est relativement simple et la reprise et le redémarrage après un incident s'effectuent directement. De plus, il n'est pas nécessaire qu'il y ait une "affinité de l'appelant" car chaque interaction est atomique et il n'y a pas de mise en cache spécifique associée au traitement d'une requête.

Application de l'enchaînement d'activités et du langage BPEL

Le BPEL4WS (Business Process Execution Language for Web Services) est un langage et un modèle de programmation conçu spécialement pour exécuter la logique métier basée sur l'enchaînement d'activités impliquant la chorégraphie des services Web. BPEL est un standard ouvert pour lequel il existe de nombreuses implémentations de fournisseurs d'outils auteur et de temps d'exécution.

La possibilité de décrire le processus métier du ServicePac® à l'aide d'un diagramme de processus schématique, puis de représenter la logique de l'implémentation en utilisant les standards basés sur les constructions BPEL4WS permet le bon dosage de flexibilité et d'isolation pour implémenter la logique métier souple du ServicePac®.

Pour ce projet, nous avons choisi l'IBM WebSphere Application Developer Integration Edition (WSADIE) comme environnement auteur. Les artefacts de code doivent normalement pouvoir être exécutés sur l'IBM WebSphere® Business Integration Server Foundation v5.1.1, qui fournit un moteur d'exécution de processus métier pour exécuter ultérieurement l'enchaînement d'activités. Les données sont hébergées sur un serveur DB2 (v8.1).

Les tests individuels nécessaires pour la confirmation des ServicePac® ont été implémentés sous forme d'Enterprise Java Beans, et plus spécifiquement sous forme de beans session sans état, exécutées sur le conteneur d'EJB du serveur WebSphere® Application. Les outils WSADIE ont facilité l'intégration de ces EJB sous forme de services Web grâce à la génération automatisée de fichiers WSDL. Les tests individuels peuvent donc être déployés, soit dans le même conteneur que le processus BPEL, soit dans les conteneurs appropriés sur les autres instances du serveur.

Image illustrant l'enchaînement d'activités représenté par un éditeur graphique BPEL.

La figure 3 illustre la vue d'un éditeur BPEL de la validation d'un enchaînement d'activités. L'outil prend en charge les boucles et les sous-processus qui se croisent pour simplifier le travail concernant les détails des pièces individuelles de l'enchaînement d'activités général.

La figure 3 illustre le processus BPEL développé utilisé pour guider les services de confirmation du ServicePac® comme le montre l'outil de création et d'édition WSADIE BPEL.

Une nette amélioration des performances a été constatée lorsqu'une implémentation précoce du processus d'enchaînement d'activités de la confirmation du ServicePac® a été modifiée pour tirer profit de l'utilisation des variables BPEL afin d'obtenir des résultats intermédiaires, au lieu de passer des appels supplémentaires au service partenaire. La figure 3 illustre cette approche dans laquelle la liste de tests à exécuter sur chaque élément d'une commande est consignée dans une variable BPEL.

Récapitulatif des avantages & des inconvénients de la conception

Avantage
Inconvénient
1. L'ajout de nouvelles offres est plus rapide et moins coûteux.

2. L'ajout de nouveaux systèmes de passation de commande est moins onéreux.

3. La confirmation est cohérente et complète.

4. L'utilisation du service de confirmation peut être progressive à mesure que les systèmes de commande sont mis à jour.

5. Une nouvelle logique de validation doit être implémentée et testée dans un seul endroit.

6. La logique de validation n'appartient qu'au programme ServicePac® et n'est pas distribuée sur plusieurs systèmes étrangers.
1. Dépendances supplémentaires au niveau du temps d'exécution entre organisations.

2. Temps système des performances sous forme de temps d'attente réseau supplémentaire.

3. Nécessite une réingénierie des systèmes existants.

4. Crée un nouveau composant centralisé pouvant jouer le rôle d'un point de défaillance unique pour plusieurs applications.

Dans le cas de l'application ServicePac®, les avantages soulignés ci-dessus ont une valeur réelle, tandis que les inconvénients peuvent tous être tempérés. Les appelants individuels étant autorisés à continuer une confirmation privée jusqu'à ce qu'ils bénéficient d'une mise à jour prévue couvrant plusieurs problèmes, le travail de programmation supplémentaire qui consiste à regrouper les données pour un appel de confirmation est un petit incrément pouvant être contenu dans la portée générale du projet de l'application appelante. Pour les services en ligne ayant des exigences de temps de réponse ne pouvant être remplies par le service de confirmation, l'appelant peut faire une première confirmation en ligne, avec un accès à la confirmation finale unique pour le service de validation. Cette stratégie préserve les facteurs humains de l'application appelante, tout en préservant l'intégrité du processus de passation de commande du ServicePac®. Pour certains systèmes en vigueur n'ayant pas de protocoles de services Web, un convertisseur a été mis au point, qui accepte un protocole privé et le transforme en appel de service Web (un document spécifique pour les fournisseurs concernant les services Web a été construit pour l'un des appelants dans ce projet). Les tests et la démonstration de la robustesse du service ont fait disparaître les craintes concernant les goulots d'étranglement introduites par le service de validation. A l'aide des clusters, le rendement du service de confirmation peut augmenter très rapidement si nécessaire. Enfin, le fait de concentrer la logique de validation dans une seule implémentation signifie que la somme qui aurait autrement été dépensée pour déployer et tester plusieurs implémentations indépendantes peut être consacrée aux tests et au déploiement d'une seule implémentation qui fera plus que compenser toutes les questions associées au fait d'avoir un seul point de défaillance pour plusieurs systèmes de saisie de commandes très différents.

En conclusion, le fait que le métier puisse prendre possession des exigences de confirmation et de leur implémentation afin de proposer rapidement de nouvelles offres et pour assurer une confirmation de la commande cohérente au début du processus de commande lui a permis de s'intéresser à de nouvelles opportunités qui étaient inenvisageables auparavant ou beaucoup trop coûteuses.