Génération d'un MPM exécutable à partir d'un MPM exécutable

Chapter 14 Génération d'autres modèles à partir d'un MPM

Génération d'un MPM exécutable à partir d'un MPM exécutable

Vous pouvez être amené à générer un MPM exécutable à partir d'un MPM exécutable pour les raisons suivantes :

Type de génération	Utilisation
SOA > Orchestrator ou BPEL4WS	Vous utilisez le langage de processus SOA lorsque vous souhaitez modéliser l'orchestration de services Web indépendamment de toute plateforme. Vous utilisez l'un des autres langages de processus exécutables fournis (Orchestrator ou l'un des langages BPEL) lorsque vous souhaitez exécuter vos processus et personnaliser des paramètres spécifiques à la plateforme
BPEL4WS > Orchestrator	Les langages BPEL sont un format d'échange standard. PowerAMC permet de procéder au reverse engineering d'un fichier BPEL dans un MPM BPEL, puis de générer un MPM Orchestrator qui peut être exécuté dans une application Sybase Unwired Orchestrator
Orchestrator > BPEL4WS	Un utilisateur d'une application Sybase Unwired Orchestrator peut souhaiter partager son MPM exécutable en utilisant le format standard d'un langage BPEL

La plupart du temps, vous effectuez le type de génération suivant :

Génération d'un MPM Sybase Unwired Orchestrator à partir d'un fichier BPEL ayant subi un reverse engineering BPEL
Génération d'un MPM Sybase Unwired Orchestrator ou d'un MPM BPEL à partir d'un MPM SOA

Changement de cible depuis BPEL4WS 1.1 vers WS-BPEL 2.0
Si vous devez changer de cible de BPEL4WS 1.1 vers WS-BPEL 2.0, notez que le gestionnaire de compensation racine est supprimé et que l'attribut étendu "variableAccessSerializable" dans les portées et le processus racine est remplacé par l'attribut étendu "isolated".

Les transformations suivantes sont exécutées lorsque vous générez un MPM Sybase Unwired Orchestrator à partir d'un MPM exécutable (SOA ou ou l'un des langages BPEL). Il est recommandé de préserver la sémantique des processus et de mettre à jour les opérations.

Mode d'appel automatique

Orchestrator prend en charge un mode d'appel automatique qui implique les opérations suivantes :

Opération	Type
Opération reçue	Notification ou Sollicitation-Réponse
Opération envoyée	Sens unique Requête-Réponse

Lorsque vous changez de langage de processus de SOA ou de l'un des langages BPEL à Orchestrator, vous devez préserver les types d'action de processus (envoi ou réception) en modifiant les types d'opération :

Lorsqu'une opération reçue dans le modèle source est de type Sens-unique ou Requête-Réponse elle devient une opération Notification ou Sollicitation-Réponse dans Orchestrator.

Lorsqu'une opération envoyée dans le modèle source est de type Notification ou Sollicitation-Réponse elle devient une opération Sens-unique ou Requête-Réponse dans Orchestrator.

Lorsque le même type d'opération est à la fois reçu et envoyé dans le même modèle source elle est dupliquée dans Orchestrator.

Types d'opération pris en charge

Chaque langage permet de restreindre le type des opérations qui peuvent être associées à un processus. Lorsque vous passez d'un langage de processus exécutable à un autre, la liste des types d'opération pris en charge peut être différente.

Lorsque le langage cible ne prend pas en charge un type d'opération Sollicitation-Réponse ou Requête-Réponse, l'opération synchrone (qui a à la fois des messages d'entrée et de sortie) est scindée en deux opérations : l'une gère les messages d'entrée et l'autre gère les messages de sortie. L'envoi de messages d'erreur est également remplacé par des opérations Sens-unique ou Notification spécifiques associées au message d'erreur.

Par exemple, Orchestrator ne prend pas en charge les opérations Sollicitation-Réponse qui représentent la réception d'un message avec une réponse synchrone (l'appelant s'attend à ce que le processus réponde dans un délai limité). Une telle opération est modélisée dans l'un des langages BPEL à l'aide de l'un des types d'action suivants : "Recevoir une demande", "Répondre" et "Répondre par une erreur".

A l'issue de la génération du MPM Orchestrator :

Les processus "Recevoir une demande" sont associés à une opération Notification qui a le message d'entrée de l'opération initiale comme message de sortie.

Les processus "Répondre" sont associés à une opération Sens-unique qui a le message de sortie de l'opération initiale comme message d'entrée.

Les processus "Répondre par une erreur" sont associés à une nouvelle opération Sens-unique qui aura le message d'erreur comme message d'entrée.

Graphe par défaut pour les processus racine

Pour tous les langages exécutables qui prennent en charge la chorégraphie racine et ne prennent pas en charge l'objet association de rôle, le diagramme racine doit être un graphe valide comportant au moins un début et une fin.

Lorsque vous générez par exemple depuis l'un des langages BPEL ou de ebXML vers Orchestrator, chaque processus racine doit être converti en un simple graphe contenant un début, un processus et une fin :

Si vous créez des processus racine dans un MPM d'analyse, ces derniers sont également convertis en graphes valides lors de la génération Orchestrator, s'ils respectent les règles suivantes :

Le processus doit être associé à un modèle ou à un package et ne doit pas avoir de flux entrant ou sortant
L'objet association de rôles ne doit pas être pris en charge dans le langage cible
Les chorégraphies racine doivent être admises

Dans le cas où il existe plusieurs processus racine, ces derniers doivent tous êtres associés aux mêmes objets début et fin :

Packages

Les packages sont utilisés pour organiser des jeux de processus. Toutefois, dans Orchestrator, le modèle ne peut contenir qu'un seul processus. Lorsque vous générez vers Orchestrator, les packages ne sont pas conservés, et seuls les objets définis immédiatement au-dessous du modèle sont générés.