BPEL: composition de services pour SOA

BPEL (Business Process Execution Language) est devenu l'une des technologies les plus importantes de la SOA (architecture orientée services) et permet une composition simple et flexible des services en processus métier. BPEL est particulièrement important car il introduit un nouveau concept dans le développement d'applications: la programmation en général. Ce concept nous permet de développer rapidement des processus en définissant l'ordre dans lequel les services seront appelés. De cette manière, les applications (et les systèmes d'information) deviennent plus flexibles et peuvent mieux s'adapter aux changements des processus métier.

Les processus commerciaux sont généralement de nature dynamique. Les entreprises doivent s'améliorer et modifier, agir de manière agile, optimiser et adapter les processus pour améliorer la réactivité de l'ensemble de l'entreprise. Chaque changement et amélioration dans un processus métier doit se refléter dans les applications qui les accompagnent. Bien que cette exigence puisse ne pas sembler très difficile à remplir, la situation du monde réel nous montre une image différente. Changer et modifier des applications est souvent un travail difficile, qui demande du temps. Par conséquent, les applications ne peuvent pas réagir instantanément aux modifications des processus métier. Elles nécessitent plutôt un certain temps pour implémenter, tester et déployer les modifications.

Rendre les systèmes d'information plus flexibles et adaptables aux changements, et mieux alignés sur les processus métier est la principale promesse de la SOA. Dans cet article, je montre pourquoi BPEL est si important et je montre comment développer un processus BPEL.

Approche orientée service

L'approche SOA pour une automatisation efficace des processus métier nécessite:

  • Méthode standardisée pour exposer et accéder aux fonctionnalités des applications en tant que services
  • Infrastructure de bus d'entreprise pour la communication et la gestion des services, y compris l'interception des messages, le routage, la transformation, etc.
  • Langage spécialisé pour la composition des fonctionnalités exposées des applications dans les processus métier

La première exigence est remplie par la dernière architecture distribuée: les services Web. La deuxième exigence est remplie par l'ESB (Enterprise Service Bus), qui prend en charge une gestion centralisée, déclarative et bien coordonnée des services et de leurs communications. La troisième exigence, la composition des services en processus, est remplie par BPEL, le langage spécialisé communément accepté pour la définition et l'exécution des processus métier.

Un processus métier, tel que vu par BPEL, est un ensemble d'appels de services coordonnés et d'activités associées qui produisent un résultat, soit au sein d'une seule organisation, soit à travers plusieurs. Par exemple, un processus métier de planification de voyages d'affaires fera appel à plusieurs services. Dans un scénario simplifié à l'extrême, le processus commercial nous obligera à spécifier le nom de l'employé, la destination, les dates et d'autres détails de voyage. Ensuite, le processus appellera un service Web pour vérifier le statut de l'employé. En fonction du statut de l'employé, il sélectionnera la classe de voyage appropriée. Ensuite, il invoquera les services Web de plusieurs compagnies aériennes (telles qu'American Airlines, Delta Airlines, etc.) pour vérifier le prix du billet d'avion et acheter celui avec le prix le plus bas.

Pour les clients, le processus BPEL exposera ses fonctionnalités de la même manière que tout autre service Web. Du point de vue du client, il ressemblera exactement à n'importe quel autre service Web. Ceci est important et utile, car cela nous permet de composer des services en processus simples, des processus simples en processus plus complexes, etc. Cela signifie également que chaque processus BPEL sera décrit avec une description WSDL (Web Services Description Language).

Concepts de base

BPEL est un langage basé sur XML. Un processus BPEL se compose d'étapes. Chaque étape est appelée une activité. BPEL prend en charge les activités primitives et de structure. Les activités primitives représentent des constructions de base et sont utilisées pour des tâches courantes, telles que celles énumérées ci-dessous:

  • Appel de services Web, utilisation
  • En attente de la demande, en utilisant
  • Manipulation des variables de données, utilisation
  • Indication des défauts et exceptions, utilisation , etc.

Nous pouvons ensuite combiner ces activités dans des algorithmes plus complexes qui spécifient les étapes d'un processus métier. Pour combiner des activités primitives, BPEL prend en charge plusieurs activités de structure. Les plus importants sont:

  • Sequence ( ) pour définir un ensemble d'activités qui seront appelées dans une séquence ordonnée
  • Flow ( ) pour définir un ensemble d'activités qui seront appelées en parallèle
  • Construction Case-switch ( ) pour implémenter des branches
  • While ( ) pour définir des boucles, etc.

Comme nous le verrons, BPEL n'est pas si différent des langages de programmation, tels que Java. Mais nous verrons que BPEL diffère de Java et prend en charge les caractéristiques des processus métier. BPEL fournit également des gestionnaires d'erreurs et de compensation, des gestionnaires d'événements et des ensembles de corrélations. Il permet d'exprimer des flux parallèles complexes. Cela rend également relativement facile d'appeler des opérations asynchrones et d'attendre des rappels.

Les processus BPEL nécessitent un environnement d'exécution - un serveur BPEL, ce qui nous donne un bon contrôle sur leur exécution. En règle générale, les serveurs BPEL permettent de contrôler les instances de processus en cours d’exécution et celles qui sont terminées. Ils prennent en charge les processus de longue durée et peuvent déshydrater l'état du processus pour économiser les ressources. Certains serveurs permettent de contrôler les activités des processus et permettent leur surveillance. Enfin, à l'aide d'un serveur BPEL, tous nos processus sont déployés de manière centralisée, ce qui simplifie la maintenance. Tout cela fait du serveur BPEL l'environnement privilégié pour l'exécution et la gestion des processus.

Choisir le bon serveur BPEL peut cependant être assez difficile, car il existe plusieurs choix. Certains des serveurs BPEL les plus populaires basés sur Java EE (le nouveau nom de Sun pour J2EE) incluent Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration et AquaLogic. Il existe également au moins quatre serveurs BPEL open source disponibles: ActiveBPEL Engine, FiveSight PXE, bexee et Apache Agila.

Exemple de processus

Regardons maintenant un exemple de processus BPEL pour les voyages d'affaires que nous avons décrit ci-dessus. Nous développerons un processus asynchrone qui utilisera un appel synchrone pour vérifier le statut de déplacement des employés et deux appels asynchrones pour acquérir les prix des billets d'avion. La figure ci-dessous montre la structure globale de notre processus. Sur la gauche, nous voyons le client qui appelle le processus. Le processus appelle d'abord le service Web de statut de déplacement des employés. Ensuite, il invoque les services Web des deux compagnies aériennes simultanément et de manière asynchrone. Cela signifie que le processus devra implémenter l'opération de rappel (et un type de port), par lequel les compagnies aériennes renverront la confirmation du billet d'avion. Enfin, le processus renvoie la meilleure offre de billets d'avion au client. Dans cet exemple, par souci de simplicité, nous n'implémenterons aucune gestion des pannes,ce qui est crucial dans les scénarios du monde réel.

Écrivons maintenant le code BPEL. Nous commençons par la déclaration de processus - l'élément racine, où nous définissons le nom du processus et les espaces de noms:

Ensuite, nous devons définir les liens partenaires. Les liens partenaires définissent différentes parties qui interagissent avec le processus BPEL. Cela inclut tous les services Web qui seront appelés et le client du processus. Chaque lien partenaire spécifie jusqu'à deux attributs: myRolequi indique le rôle du processus métier lui-même et partnerRolequi indique le rôle du partenaire. Dans notre exemple, nous définissons quatre liens partenaires:

Pour stocker les messages, les reformater et les transformer, nous avons besoin de variables. Habituellement, nous utilisons une variable pour chaque message envoyé aux services Web et reçu d'eux. Dans notre exemple, nous aurons besoin de quelques variables. Pour chaque variable, nous devons spécifier le type. Nous pouvons utiliser un type de message WSDL, un type simple de schéma XML ou un élément de schéma XML. Dans notre exemple, nous utilisons des types de message WSDL pour toutes les variables:

Nous sommes maintenant prêts à écrire le corps du processus principal. Il ne contient qu'une seule activité de niveau supérieur. Habituellement, c'est un qui nous permet de définir plusieurs activités qui seront exécutées séquentiellement. Dans la séquence, nous spécifions d'abord le message d'entrée qui démarre le processus métier. Nous faisons cela avec la construction, qui attend le message correspondant. Dans notre cas, c'est le TravelRequestmessage. Dans la construction, nous ne spécifions pas directement le message. Nous spécifions plutôt le lien du partenaire, le type de port, le nom de l'opération et, éventuellement, la variable qui contient le message reçu pour les opérations consécutives. Nous lions la réception du message avec le client partenaire et attendons que l' TravelApprovalopération soit appelée sur le type de port TravelApprovalPT. Nous stockons le message reçu dans leTravelRequest variable:

Ensuite, nous devons appeler le service Web Statut de déplacement des employés. Avant cela, nous devons préparer l'entrée pour ce service Web. Nous pouvons construire un tel message en copiant la partie employé du message que le client a envoyé. Nous pouvons maintenant appeler le service Web Statut de déplacement des employés. Nous faisons une invocation synchrone, pour laquelle nous utilisons l' activité. Nous utilisons le employeeTravelStatuslien partenaire et invoquons l' EmployeeTravelStatusopération sur le EmployeeTravelStatusPTtype de port. Nous avons préparé le message d'entrée dans la EmployeeTravelStatusRequestvariable. Puisqu'il s'agit d'un appel synchrone, l'appel attend la réponse et la stocke dans la EmployeeTravelStatusResponsevariable:

L'étape suivante consiste à appeler les deux services Web des compagnies aériennes. Encore une fois, nous préparons d'abord le message d'entrée requis (qui est égal pour les deux services Web). Nous allons faire des invocations asynchrones simultanées. Pour exprimer la concurrence, BPEL fournit l' activité. L'appel à chaque service Web comprendra deux étapes:

  1. L' activité est utilisée pour l'appel asynchrone
  2. L' activité est utilisée pour attendre le rappel

Nous avons l'habitude de regrouper les deux activités. Les deux appels ne diffèrent que par le nom du lien partenaire. Nous utilisons AmericanAirlinespour l'un et DeltaAirlinespour l'autre:

...