Gérer les dépendances des processus et des services dans un environnement SOA
Contexte Savez-vous de quels services dépend un processus BPEL ? Si différentes versions d'un processus BPEL sont utilisées, les dépendances entre les deux peuvent rapidement devenir plus complexes. La complexité de la gestion des dépendances augmente si l'on prend en compte les services Enterprise Service Bus (ESB) invoqués par le processus BPEL. La complexité rend le déploiement et les tests longs, difficiles et sujets aux erreurs.
Nous finissons souvent par utiliser l'outil de modélisation Microsoft Visio pour schématiser manuellement les dépendances et nous efforcer de mettre à jour les dépendances après chaque modification du processus. Il s’agit d’un obstacle majeur à l’agilité des infrastructures d’architecture orientée services (SOA), conçues pour permettre des changements agiles dans les processus métier.
Dans cette note technique, vous apprendrez comment améliorer avec succès votre processus de génération et mettre en œuvre la génération automatique de graphiques de dépendances de processus.
Notre défi est de mettre en œuvre un projet de démonstration Oracle SOA Suite pour un client qui contient de nombreux processus BPEL et référence de nombreux sous-processus BPEL et services ESB. Nous avons fini par utiliser une douzaine de processus BPEL et de services ESB (qui ont été définis comme services publics et partagés sur le registre de services) ainsi que d'autres processus BPEL et services ESB propriétaires.
Tout d'abord, nous avons décidé de créer un déploiement basé sur Ant pour tous les services du projet, de déployer les processus BPEL (y compris les cas de test qui les exécutent) dans différents environnements (test, intégration, production), et également de déployer les services ESB pour ces environnements basés sur Ant. Téléchargement gratuit de livres électroniques sur ordinateur
Exigences Après avoir terminé la première version du projet, nous avons quelques exigences :
,
Lorsqu'un processus BPEL ou un service ESB change, nous ne souhaitons pas déployer tous les services du projet. Nous devons donc passer d’un déploiement centré sur les projets à une approche de déploiement centrée sur le service public.
Lors du déploiement d'un processus BPEL, tous les sous-processus (propriétaires) et services ESB dépendants sont également automatiquement déployés.
Pour éviter d'écraser une version spécifique d'un processus, déployez cette version du processus uniquement si elle n'est pas déjà déployée sur le serveur. L'écrasement entraînera la perte de toutes les informations de flux d'instance.
Un graphique visuel de toutes les dépendances des processus et des services doit être automatiquement créé lors du déploiement sans qu'il soit nécessaire de conserver ces informations séparément. La visualisation devrait ressembler à ceci.
Questions ouvertes En réponse à ces nouvelles exigences, nous avons posé les questions suivantes et fourni les réponses suivantes :
Question : Où sont stockées les informations provenant des dépendances de processus et de services ? Besoin d'ajouter plus d'informations pour créer un graphique de dépendance complet ?
Réponse : Tous les services appelés par le processus BPEL sont stockés dans le fichier bpel.xml marqué par PartnerLinkBinding. Les informations sur le processus BPEL appelé et la version sont également codées dans l'URL. Par exemple : Téléchargement gratuit de livres électroniques informatiques
<nom de la propriété="wsdlRuntimeLocation">
${domain_url}/CustomerAccount_BES/1.3/CustomerAccount_BES?wsdl
</propriété>
La version actuelle du processus BPEL à déployer se trouve dans le fichier build.properties. Pour la maintenance de la version du processus BPEL, il suffit de modifier la propriété rev dans le fichier build.properties.
Pour différencier les processus BPEL publics et privés, le lien partenaire du client dans le fichier bpel.xml fournit un nouvel attribut « type » avec une valeur « public » ou « privé », comme indiqué ici :
<partnerLinkBinding name="client">
<property name="wsdlLocation">CustomerAccount_BES.wsdl</property>
<property name="type">public</property>
</partnerLinkBinding>
Question : Existe-t-il un outil ou un framework capable de générer dynamiquement des graphiques de dépendances ?
Réponse : Oui, Graphviz ( www.graphviz.org ), un outil open source, peut générer des graphiques à partir de fichiers d'entrée au format texte.
Question : Quelles sont les options pour référencer d’autres processus BPEL ?
Réponse : Les options sont :
Référencer la version par défaut Référencer une version spécifique Référencer une clé de service UDDI (avec ou sans informations de version codées)
Question : Comment mettre en œuvre toutes ces nouvelles exigences de déploiement ?
Réponse : Il est préférable de répondre à ces nouvelles exigences de déploiement en utilisant des tâches Ant personnalisées.
Une fois les questions de démarrage répondues de manière satisfaisante, commençons par créer une tâche Ant personnalisée. Le fichier bpel.xml est analysé dans la tâche Ant. Pour toutes les balises PartnerLinkBindings trouvées, l'analyse du fichier bpel.xml correspondant commencera de manière récursive. En plus de l'analyse, la valeur actuelle de la propriété de version (« ref ») est extraite du fichier build.properties de chaque projet BPEL trouvé. L'un des défis de l'analyse récursive est d'ignorer les dépendances cycliques.
Notre nouvel attribut "type" et notre analyse récursive dans le fichier bpel.xml implémentent tous nos besoins de déploiement en gardant le service à l'esprit.
Mieux encore, nous utilisons Graphviz pour résoudre le problème de génération automatique de graphiques de dépendances. Pour y parvenir, nous fusionnerons toutes les dépendances obtenues à partir de l'analyse récursive de bpel.xml en un seul fichier XML, comme indiqué ci-dessous. Téléchargement gratuit de livres électroniques sur ordinateur
<?xml version="1.0" encoding="UTF-8"?>
<Valise BPEL>
<BPELProcess id="Resource_BAS_SetForAccount" src=" http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/Resource_BAS_SetForAccount.bpel ">
<partnerLinkBindings>
<partnerLinkBinding name="client">
<property name="wsdlLocation">Resource_BAS_SetForAccount.wsdl</property>
<property name="type">public</property>
<property name="version">1.2</property>
</partnerLinkBinding>
<partnerLinkBinding name="RemoveFromAccount">
<property name="wsdlLocation">Resource_BAS_RemoveFromAccount.wsdl</property>
<property name="version">1.5</property>
</partnerLinkBinding>
...
</partnerLinkBindings>
</BPELProcessus>
<BPELProcess id="Resource_BAS_RemoveFromAccount" src=" http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/Resource_BAS_RemoveFromAccount.bpel ">
<partnerLinkBindings>
<partnerLinkBinding name="client">
<property name="wsdlLocation">Resource_BAS_RemoveFromAccount.wsdl</property>
<property name="type">public</property>
<property name="version">1.5</property>
</partnerLinkBinding>
<partnerLinkBinding name="CheckAvailability">
<property name="wsdlLocation">Resource_BES_CheckAvailability.wsdl</property>
<property name="version">1.1</property>
</partnerLinkBinding>
...
</partnerLinkBindings>
</BPELProcessus>
<BPELProcess id="Resource_BES_CheckAvailability" src=" http://www.oracle.com/technology/tech/soa/soa-suite-best-practices/Resource_BES_CheckAvailability.bpel ">
<partnerLinkBindings>
<partnerLinkBinding name="client">
<property name="wsdlLocation">Resource_BES_CheckAvailability.wsdl</property>
<property name="type">public</property>
<property name="version">1.1</property>
</partnerLinkBinding>
...
</partnerLinkBindings>
</BPELProcessus>
...
</BPELValise>
Utilisez XSLT pour convertir les fichiers XML fusionnés dans un format cible (.dot), qui peut être utilisé comme entrée dans le générateur Graphviz pour générer une image PNG, comme indiqué ci-dessous :
structures digraphiques {
nœud [shape=record,fontname="Arial",fontsize="10"] ;
bord [fontname="Arial",fontsize="8"];
classement=LR;
labeljust=l;
"Resource_BAS_SetForAccount_1_2" [shape=record,label="{Resource_BAS_SetForAccount}|{1.2|public}",
fillcolor=jaunevert,style=rempli];
"Resource_BAS_RemoveFromAccount_1_5" [shape=record,label="{Resource_BAS_RemoveFromAccount}|{1.5|public}",
fillcolor=jaunevert,style=rempli];
"Resource_BES_CheckAvailability_1_1" [shape=record,label="{Resource_BES_CheckAvailability}|{1.1|public}",
fillcolor=jaunevert,style=rempli];
"Resource_BAS_SetForAccount_1_2" -> "Resource_BAS_RemoveFromAccount_1_5" [decorate=true,label=""] ;
"Resource_BAS_RemoveFromAccount_1_5" -> "Resource_BES_CheckAvailability_1_1" [decorate=true,label=""] ;
}
Le graphique de dépendance généré par le fichier DOT ci-dessus ressemble à ceci :
Le nom, la version et le type du service sont affichés dans la zone. La couleur de la case indique le type de service. Dans ce diagramme, nous avons trois services publics (verts). Le diagramme au début de cet article montre également le service ESB (blanc) et le service BPEL (orange).
Après avoir généré le schéma idéal pour chaque processus BPEL public, nous devons mettre en œuvre le déploiement automatique des processus concernés. Pour ce déploiement centré sur les services, nous avons utilisé la liste de processus que nous avons générée précédemment. La cible de déploiement standard est appelée pour chaque processus de la liste. Pour éviter d'écraser les versions de processus existantes sur le serveur, la cible de déploiement n'est appelée que s'il n'existe aucune version actuelle du processus sur le serveur.
Vous pouvez déterminer si une version de processus spécifique est disponible en ouvrant une connexion HTTP à l'URL WSDL du processus, puis en vérifiant le code d'état renvoyé (état HTTP 200 ? Déployé, état HTTP 404 ? Pas encore déployé). Téléchargement gratuit de livres électroniques sur ordinateur
Le résultat de notre tâche Ant personnalisée (contenant l'analyse récursive), la génération d'images PNG et le déploiement centré sur les services ressemble à ceci :
...
[mkdir] Répertoire créé : /MyProject/Resource_BAS_SetForAccount/doc
[bpeltask] ** DÉMARRAGE de DeployWithDependencesTask **
[bpeltask] Resource_BAS_SetForAccount-1.2
[bpeltask] ** PARAMÈTRE **
[bpeltask] nom de fichier point : doc/bpel-recursiv-all.dot
[bpeltask] dotfilenamepublic : doc/bpel-recursiv-public.dot
[bpeltask] déployertarget : déployer
Déploiement [bpeltask] : vrai
[bpeltask] écrasement : faux
[bpeltask] arrêt sur déjà déployé : faux
[bpeltask] ** RÉSOLUTION RÉCURSIVE DE TOUS LES FICHIERS bpel.xml **
[bpeltask] [Resource_BAS_SetForAccount-1.2]
[bpeltask] [Resource_BAS_SetForAccount-1.2, Resource_BAS_RemoveFromAccount-1.5]
[bpeltask] [Resource_BAS_SetForAccount-1.2, Resource_BAS_RemoveFromAccount-1.5, Resource_BES_CheckAvailability-1.1]
[bpeltask] ** ÉCRITURE DU FICHIER bpel.xml CENTRAL **
[bpeltask] ** TRANSFORMATION DU FICHIER DOT **
[bpeltask] ** DÉPLOIEMENT DE SERVICE **
[bpeltask] ================================================ =========================
[bpeltask] SERVICE DÉJÀ DÉPLOYÉ (HTTP/1.1 200 OK) 'Resource_BES_CheckAvailability' dans la version '1.1' http://localhost:8888/orabpel/default/Resource_BES_CheckAvailability/1.1/ Resource_BES_CheckAvailability?wsdl
[bpeltask] ================================================ =========================
[bpeltask] ================================================ =========================
[bpeltask] SERVICE DÉJÀ DÉPLOYÉ (HTTP/1.1 200 OK) 'Resource_BAS_RemoveFromAccount' en version '1.5' http://localhost:8888/orabpel/default/Resource_BAS_RemoveFromAccount/1.5/ Resource_BAS_RemoveFromAccount?wsdl
[bpeltask] ================================================ =========================
[bpeltask] ================================================ =========================
[bpeltask] SERVICE PAS ENCORE DÉPLOYÉ (HTTP/1.1 404 introuvable) http://localhost:8888/orabpel/default/Resource_BAS_SetForAccount/1.2/ Resource_BAS_SetForAccount?wsdl
[bpeltask] DÉMARRAGE DU DÉPLOYEMENT DU SERVICE de Resource_BAS_SetForAccount dans la version 1.2
[bpeltask] ================================================ =========================
...
Conclusion Le déploiement centré sur les services qui génère automatiquement des graphiques de dépendances répond à tous nos besoins en matière de transparence de l'infrastructure SOA. Étant donné que le déploiement est entièrement basé sur Ant, nous pouvons également l'utiliser pour nos tâches de build nocturnes et de production Luntbuild (environnement de build continu).
Pour prendre en charge la gouvernance SOA de nos clients, nous exposerons notre processus public et sa documentation, ainsi que le graphique de dépendances qui en résulte, dans le wiki du client, comme indiqué ici :
Les pages wiki sont générées dynamiquement lorsqu'une recherche dans le registre de services récupère la version d'un service public actuellement enregistré. Les figures de la page wiki fournissent des liens vers le référentiel source (Subversion), qui contient des figures en taille réelle de la documentation et des versions enregistrées de nos services publics. Cliquez sur la vignette pour récupérer le fichier correspondant depuis Subversion via WebDAV