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
-
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.
-
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.
-
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.
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 :
-
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).
-
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.
-
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.
-
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.
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.
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.
|