Orchestration

Les organisations qui ont déjà utilisé des produits middleware d’intégration d’applications d’entreprise (EAI) pour automatiser les processus métier ou intégrer divers environnements hérités seront probablement déjà familiarisées avec le concept d’orchestration. Dans ces systèmes, un ensemble de logique de flux de travail contrôlé de manière centralisée facilite l’interopérabilité entre deux ou plusieurs applications différentes. Une implémentation courante de l’orchestration est le modèle en étoile qui permet à plusieurs participants externes de s’interfacer avec un moteur d’orchestration central.

L’une des exigences motrices de la création de ces solutions était de s’adapter à la fusion de grands processus métier. Avec l’orchestration, différents processus peuvent être connectés sans avoir à réaménager les solutions qui ont initialement automatisé les processus individuellement. L’orchestration comble cette lacune en introduisant une nouvelle logique de flux de travail. En outre, l’utilisation de l’orchestration peut réduire considérablement la complexité des environnements de solution. La logique de flux de travail est abstraite et plus facilement maintenue que lorsqu’elle est intégrée dans des composants de solution individuels.

Le rôle de l’orchestration s’élargit dans les environnements orientés services. Grâce à l’utilisation d’extensions qui permettent d’exprimer la logique des processus métier via des services, l’orchestration peut représenter et exprimer la logique métier dans un lieu standardisé basé sur les services. Lors de la construction de solutions orientées service, cela fournit un moyen extrêmement attrayant de loger et de contrôler la logique représentant le processus en cours d’automatisation.

L’orchestration tire davantage parti de l’interopérabilité intrinsèque recherchée par les conceptions de services en fournissant des points de terminaison d’intégration potentiels dans les processus. Un aspect clé de la position de l’orchestration au sein de SOA est le fait que les orchestrations elles-mêmes existent en tant que services. Par conséquent, s’appuyer sur la logique d’orchestration normalise la représentation des processus au sein d’une organisation, tout en répondant à l’objectif de la fédération des entreprises et en favorisant l’orientation vers les services.

Figure 6.32. Une orchestration contrôle presque toutes les facettes d’une activité complexe.

Une spécification principale de l’industrie qui standardise l’orchestration est le langage d’exécution des processus métier des services Web (WS-BPEL). Ce livre reconnaît WS-BPEL comme une extension clé de deuxième génération et utilise donc ses concepts et sa terminologie comme base pour un certain nombre de discussions relatives à la modélisation des processus métier.

Note

WS-BPEL est le nom le plus récent donné à cette spécification, également connue sous le nom de BPEL4WS et simplement BPEL. Pour un aperçu des principales parties du langage WS-BPEL et une discussion sur la façon dont le changement de nom s’est produit, voir le chapitre 16.

En clair

Après avoir lavé avec succès plusieurs voitures ensemble, Chuck, Bob, Jim et moi décidons de créer notre propre entreprise. Nous formalisons les étapes de notre processus de lavage de voiture afin de pouvoir gérer différents types de voitures avec des exigences de nettoyage différentes.

Notre processus est donc affecté par les nouvelles exigences suivantes:

• Nous décidons d’engager une aide supplémentaire pendant les heures de pointe. Cela introduit jusqu’à deux membres supplémentaires qui rejoignent notre équipe.
• Comme nous n’avons pas de capital-risque pour cette entreprise, nous concluons un accord avec une station-service locale. En échange de l’utilisation d’une partie de leur lot pour notre opération de lavage de voiture, nous acceptons d’aider avec les tâches de pompage de gaz pendant leurs heures de pointe.

Notre processus de lavage de voiture simple est maintenant beaucoup plus compliqué. Le processus n’est plus fixe en ce sens qu’il peut changer à tout moment à la suite de diverses conditions et événements.

• Lorsque nos travailleurs supplémentaires arrivent, la répartition des tâches de toute l’équipe est modifiée.
• Lorsque le personnel de la station-service a besoin d’une aide supplémentaire, nous sommes obligés d’envoyer un ou plusieurs membres de notre équipe de lavage de voiture pour les aider.

Ces exemples concernent des conditions prévisibles qui se produisent quotidiennement. Notre fonctionnement est en outre affecté par certaines contraintes:

• Si nos flux de trésorerie tombent en dessous d’un certain montant, nous ne pouvons pas nous permettre de travailler à temps partiel.
• S’il pleut, tous les travaux sont suspendus (entraînant également une réduction des flux de trésorerie).

Ces contraintes introduisent des conditions moins courantes, mais que nous devons toujours prendre en considération. Pour tenir compte de ces situations potentielles, nous élaborons un plan qui trace notre processus élargi et fournit des processus alternatifs pour faire face à des conditions communes et inhabituelles.

Ce plan est essentiellement un flux de travail qui relie des étapes individuelles à des processus et des sous-processus partitionnés par des points de décision. Ce flux de travail élaboré intègre notre processus original avec le processus de la station-service et le processus étendu résultant de l’arrivée de nos travailleurs à temps partiel. Ce flux de travail est essentiellement une orchestration qui gère les exigences individuelles des processus et les ressources associées, les participants, les événements, les règles métier et les activités.

6.6.1. Définition des protocoles métier et des processus

La logique de workflow qui comprend une orchestration peut comprendre de nombreuses règles métier, conditions et événements. Collectivement, ces parties d’une orchestration établissent un protocole métier qui définit la façon dont les participants peuvent interagir pour mener à bien une tâche métier. Les détails de la logique de workflow encapsulée et exprimée par une orchestration sont contenus dans une définition de processus.

6.6.2. Les services de processus et les services de partenaires

identifiés et décrits dans une définition de processus sont les participants admissibles au processus. Premièrement, le processus lui-même est représenté comme un service, ce qui donne un service de processus (qui se trouve être un autre de nos modèles de services, comme le montre la figure 6.33).

Figure 6.33. Un service de processus coordonnant et exposant les fonctionnalités de trois services partenaires.

Les autres services autorisés à interagir avec le service de processus sont identifiés comme des services partenaires ou des liens de partenaires. Selon la logique du flux de travail, le service de processus peut être appelé par un service partenaire externe ou il peut appeler d’autres services partenaires (figure 6.34).

Figure 6.34. Le service de processus, après avoir d’abord été appelé par un service partenaire, appelle ensuite un autre service partenaire.

6.6.3. Activités de base et activités structurées

WS-BPEL décompose la logique de flux de travail en une série d’activités primitives prédéfinies. Les activités de base (recevoir, invoquer, répondre, lancer, attendre) représentent des actions de flux de travail fondamentales qui peuvent être assemblées en utilisant la logique fournie par des activités structurées (séquence, commutateur, while, flux, pick). La façon dont ces activités peuvent être utilisées pour exprimer la logique réelle des processus métier est explorée au chapitre 16.

6.6.4. Les séquences, flux et liens

Les activités de base et structurées peuvent être organisées de manière à ce que l’ordre dans lequel elles s’exécutent soit prédéfini. Une séquence aligne des groupes d’activités associées dans une liste qui détermine un ordre d’exécution séquentiel. Les séquences sont particulièrement utiles lorsqu’une partie de la logique d’application dépend du résultat d’une autre.Les flux

contiennent également des groupes d’activités connexes, mais ils introduisent des exigences d’exécution différentes. Des éléments de logique d’application peuvent s’exécuter simultanément dans un flux, ce qui signifie qu’il n’est pas nécessairement nécessaire qu’un ensemble d’activités attende avant la fin d’un autre. Cependant, le flux lui-même ne se termine pas tant que toutes les activités encapsulées n’ont pas terminé le traitement. Cela garantit une forme de synchronisation entre la logique applicative résidant dans des flux individuels.

Les liens sont utilisés pour établir des dépendances formelles entre les activités qui font partie des flux. Avant qu’une activité puisse être entièrement terminée, elle doit s’assurer que toutes les exigences établies dans les liens sortants sont d’abord satisfaites. De même, avant qu’une activité liée puisse commencer, les exigences contenues dans les liens entrants doivent d’abord être satisfaites. Les règles fournies par les liens sont également appelées dépendances de synchronisation.

6.6.5. Orchestrations et activités

Comme nous l’avons défini précédemment, une activité est un terme générique qui peut être appliqué à toute unité logique de travail complétée par une solution orientée service. La portée d’une orchestration unique peut donc être classée comme une activité complexe et très probablement de longue durée.

6.6.6. Orchestration et coordination

L’orchestration, telle que représentée par WS-BPEL, peut pleinement utiliser le cadre de gestion du contexte de coordination WS-Coordination en incorporant le type de coordination WS-BusinessActivity. Cette spécification définit des protocoles de coordination conçus pour soutenir des activités complexes et de longue durée.

6.6.7. Orchestration et SOA

La logique des processus métier est à la base des solutions d’automatisation. L’orchestration fournit un modèle d’automatisation où la logique des processus est centralisée tout en restant extensible et composable (figure 6.35). Grâce à l’utilisation d’orchestrations, les environnements de solutions orientées services deviennent intrinsèquement extensibles et adaptatifs. Les orchestrations elles-mêmes établissent généralement un point d’intégration commun pour d’autres applications, ce qui fait d’une orchestration implémentée un facilitateur d’intégration clé.

Figure 6.35. Orchestration relative à d’autres parties de SOA.

Ces qualités conduisent à une agilité organisationnelle accrue car:

• La logique de flux de travail encapsulée par une orchestration peut être modifiée ou étendue dans un emplacement central.
• Le positionnement centralisé d’une orchestration peut faciliter considérablement la fusion des processus métier en abstrayant la colle qui lie les solutions d’automatisation correspondantes.
• En établissant des architectures d’intégration orientées services potentiellement à grande échelle, l’orchestration, sur un plan fondamental, peut soutenir l’évolution d’une entreprise diversement fédérée.

L’orchestration est un ingrédient clé pour atteindre un état de fédération au sein d’une organisation qui contient diverses applications basées sur des plates-formes informatiques disparates. Les avancées du middleware permettent aux moteurs d’orchestration eux-mêmes de s’intégrer pleinement dans des environnements orientés services.

Le concept d’orchestration orientée services tire pleinement parti de tous les concepts que nous avons discutés jusqu’à présent dans ce chapitre. Pour de nombreux environnements, les orchestrations deviennent le cœur de SOA.

Étude de cas

La série d’étapes que nous avons regroupées dans une activité commerciale dans l’exemple d’étude de cas précédent a montré comment TLS utilisait le protocole WS-BusinessActivity pour ajouter la gestion du contexte et la gestion des exceptions à une activité complexe de longue durée. Même si la portée d’une activité commerciale peut constituer un processus métier, elle ne fournit pas à TLS un moyen standard d’exprimer la logique de flux de travail sous-jacente. Pour cela, TLS utilise une orchestration WS-BPEL (Figure 6.36).

Figure 6.36. Le Processus de Soumission de bons de commande TLS étendu géré par une orchestration et impliquant de nombreuses organisations partenaires potentielles.

L’orchestration établit une logique de processus complète qui englobe l’activité commerciale et l’étend encore plus pour régir des scénarios d’interaction supplémentaires avec plusieurs services de fournisseurs. Par exemple, lorsqu’un fournisseur ne peut pas exécuter une commande, le fournisseur suivant en ligne reçoit le même bon de commande. Ce cycle est répété jusqu’à ce qu’un fournisseur puisse terminer la commande dans son intégralité (dans certaines limites de prix) ou jusqu’à ce que tous les fournisseurs aient été interrogés. Dans cette dernière situation, le système évalue simplement la meilleure offre sur la table en appliquant une formule qui prend en compte le prix, le pourcentage de commande à exécuter et les conditions de commande en attente.

La logique d’orchestration gère tous les aspects du processus, y compris l’implication de plusieurs services partenaires fournisseurs, ainsi que l’activité commerciale qui intervient lorsqu’un bon de commande est traité.

RÉSUMÉ DES POINTS CLÉS

• Une orchestration exprime un ensemble de logiques de processus métier qui appartient généralement à une seule organisation.
• Une orchestration établit un protocole métier qui définit formellement une définition de processus métier.
• La logique de flux de travail au sein d’une orchestration est décomposée en une série d’activités de base et structurées qui peuvent être organisées en séquences et en flux.
• L’orchestration a été appelée le « cœur de la SOA « , car elle établit un moyen de centraliser et de contrôler une grande partie de la logique inter et intra-application grâce à un modèle de service standardisé.