BPEL4WS_ Outils et Validation

Document Sample
BPEL4WS_ Outils et Validation Powered By Docstoc
					    BPEL4WS,
Outils et Validation


        Animé par : Anne-Elisabeth Caillot
        Directeur de recherche : Hafedh Mili
                        Sommaire
   Vers BPEL4WS
        Les services Web
        Rappel sur WSDL
        Pourquoi BPEL4WS

   Le langage BPEL4WS
        Apparition du BPEL4WS
        La structure globale
        Les activités
        BPEL Handlers

   Les outils
        BPWS4J
        Collaxa Orchestration Server

   Théories de validation
        Le principe de model-checking
        Le BPEL calculus
        LTSA et FSP

   Plates-formes de composition
Vers BPEL4WS
Les Services Web
    Les Services Web
 SOAP : protocole de transport de données (dont celles au
format XML) basé sur http.
 UDDI : standard d’annuaire permettant d’enregistrer et de
rechercher des services Web.
   WSDL : dialecte XML permettant de décrire un service Web
    Rappel sur WSDL
WSDL:

   Permet de localiser et de décrire en détails l’utilisation d’un
    Service Web donné.

    Contient des informations opérationnelles concernant le service :

                 L'interface du service
                 Les protocoles d'accès
                 Les points d'activation (endpoint)
   Rappel sur WSDL
<definitions>
 <documentation> ……</documentation>
 <import/> importation de document
 <types> définition des types complexes........ </types>
 <message> définition des messages .... </message>
 <portType> définition des opérations...
         <operation> définition des entrées - sorties... </operation>
 </portType>
 <partnerLinkType>définition interactions entre services </partnerLinktype>
</définitions>


Pas d’élément binding ou service, seule l’utilisation et le
référencement par les portTypes suffit  réutilisation de la
définition du processus.
     Pourquoi BPEL4WS

   Supprimer les conflits liés à la composition de service, à l’intégration
    de services dans des processus d’affaires, aux différences des
    langages.
   Définir un langage standard de spécification et de normalisation des
    processus d’affaires, notamment pour la composition de services Web.


BPEL4WS:
   Permet la définition de processus d’affaires comme un ensemble
    coordonné de Services Web, via des opérations des Service Web
    définies en WSDL.
   Les processus d’affaires, eux-même, sont définis en utilisant WSDL.
Le Langage BPEL4WS
     BPEL4WS_apparition
BPEL4WS :
   A ses racines dans les modèles de flux et la programmation
    structurée,
   Issu du fusionnement de WSFL (de IBM) et XLANG (de Microsoft).
   Situé au dessus de WSDL et des spécifications XML qu’ils utilisent.


Spécification :
   Version 1.1, définie le 5 mai 2003 :
           http://www.ibm.com/developerworks/library/ws-bpel/
   Développé par IBM, Microsoft et BEA.
     BPEL4WS_structure globale

BPEL4WS :
   Permet la modélisation des procédés exécutables (executable
    business ) et des procédés abstraits (business protocols)
            Executable business : modélisation des comportements     des
             différents partenaires interagissant ensemble.
            Business protocols : description du comportement visible des
             processus.


   Est utilisé avec deux autres spécifications
     BPEL4WS_structure globale
Un processus BPEL4WS est donc constitué de deux parties:

   La partie definition : l’interface du processus, définition en WSDL des
                          différentes opérations utilisés

   La partie process : fichier BPEL qui comprend :
           une partie de     définition   de   ces   éléments   :   variables,
            partnerLink….;
           La description du processus et de l’enchaînement de ses actions.
     BPEL4WS_structure globale
<process>
<partnerLinks> .. partenaires utilisés dans le processus.. </partnerLinks>

<variables> ..données échangées au sein du processus.. </variables>

<correlationSets>utilisé pour identifier une instance unique du processus
 </correlationSets>

 <faultHandlers> ..activités exécutées en réponse à des fautes précises..
 </faultHandlers>

 <compensationHandlers> ..code exécuté pour «défaire» une action..
 </compensationHandlers>

         (activités) actions exécutées par le processus
</process>
  BPEL4WS_structure globale
<partnerLinks>….</partnerLinks>
       partenaires (Services Web) utilisés dans le processus




<variables>…</variables>
       données échangées par le processus
  BPEL4WS_structure globale

<correlationSets>….</correlationSets>
          Utilisé pour identifier uniquement une instance du processus

 Ensemble de corrélation = ensemble de propriété :




Utilisation de la corrélation dans le processus:
   BPEL4WS_les activités
Les activités élémentaires :
<invoke
       partnerLink=‘‘…’’
       portType=‘‘….’’
       operation=‘‘….’’          Le processus appelle une opération d’un
       inputVariable=‘‘….’’      partenaire
       outputVariable=‘‘….’’/>

<receive
       partnerLink=‘‘…’’         Le processus reçoit l’invocation d’un
       portType=‘‘….’’           partenaire
       operation=‘‘….’’
       variable=‘‘….’’ />

<reply
         partnerLink=‘‘…’’
                                 Le processus envoie un message de réponse à
         portType=‘‘….’’
                                 l’invocation du partenaire
         operation=‘‘….’’
         variable=‘‘….’’ />
   BPEL4WS_les activités
<assign>
  <copy>
     <from variable=‘‘….’’/> <to variable=‘‘….’’/>
  </ copy >
</ assign >

<throw faultName= “…” faultVariable=“…”/>
          Pour la détection et la gestion d’erreur

<wait for=‘‘…’’’ ? Until=‘’…’’ ? ’/>
           arrête l’exécution du processus pour un temps spécifié

<terminate/>     termine le processus

<empty> ne fait rien
  BPEL4WS_les activités
Les activités de structure :

<sequence>
Exécution des activités de manière séquentielle

<flow>
Exécution des activités en parallèle

<while>
Répétition de l’activité jusqu’au non-respect de la condition

<pick>


<link>
Définition d’une dépendance d’exécution entre une activité source et
        une cible
BPEL4WS_exemple
BPEL4WS_exemple




                  …
BPEL4WS_handlers

  Scope (portée) : un contexte associée à une structure
 ou à un ensemble d’activités élémentaires.


    faultHandlers et compensationHandlers : définis au
     sein des Scopes.


    Possibilité de plusieurs faultHandlers par Scope.


    Un compensationHandler par Scope.
  BPEL4WS_handlers
<faultHandlers>….</faultHandlers>
        Activités qui seront exécutées en réponse à des fautes particulières




Les activités catch sont spécifiques à une faute, définie par un faultName
unique.
 BPEL4WS_handlers
<compensationHandlers> … </compensationHandlers>
       Utilisé pour défaire une action réalisée précédemment




                                               Les compensationHandler
                                               utilisent les valeurs des
                                               variables au moment précis ou
                                               la compensation est déclenchée.




Utilisation de compensationHandler dans le processus :
Outils BPEL4WS
BPEL4WS_outils

 Outils :

    BPWS4J : Business Process Web Service for Java
    Collaxa Orchestration Server

 Links:
  www.alphaworks.ibm.com/tech/bpws4j
  www.collaxa.com
BPEL4WS_BPWS4J

   Développé par IBM

Permet l’exécution de processus d’affaires écrits
en BPEL4WS

Contient un outil de validation de documents
BPEL4WS

Contient un éditeur pour créer et modifier des
fichiers BPEL4WS
BPEL4WS_éditeur BPWS4J

 L’éditeur BPWS4J:

 Vues synchronisées de code source et d’arbre
 XML du processus d’affaires traité,

 Flexibilité pour gérer les approches ascendantes
 ou descendantes de conception de processus,

 Validation du processus durant l’édition (syntax-
 directed editor)
BPEL4WS_éditeur BPWS4J
BPEL4WS_Collaxa

    Développé par Collaxa

 Collaxa Orchestration Server contient :

    BPEL Orchestration Server
    BPEL Scenario Designer
    BPEL Console
BPEL4WS_Collaxa

Collaxa Orchestration Server :

    A une architecture basée sur l’architecture
     J2EE,

    Supporte les Services Web XML,

    Les scénarios BPEL peuvent être implémentés en
     XML, mais aussi en JSP
BPEL4WS_Collaxa

Collaxa Orchestration Server :

    Permet la gestion (contrôle, sauvegarde, etc.)
     des interactions asynchrones : Scenario
     manager,

    Permet le déboggage des flux d’affaires
     asynchrones : console debbuger,

    Permet le contrôle des exécutions des flux
     d’affaires : console,

    A un serveur autonome : bpel Server.
BPEL4WS_Collaxa console

        Visualisation graphique du flux




        Visualisation de Bug



                                    résultat d’une requête


        Visualisation du code
Validation de BPEL4WS
BPEL4WS_model-checking

    Article de Nakjima, sur l’application du principe
     de model-checking sur des Services Web
     décrits en WSFL.

    Intérêt : voir comment le principe du model-
     checking utilisé en conception logicielle peut être
     appliqué aux Services Web.

    Limites : manipulation difficile des flux de contrôle
     et de données; DPE mal approprié
BPEL4WS_model-checking

    Principe de fonctionnement :

       Description WSFL transcrite en Promela,
      (Protocol Meta Language), entrée du langage SPIN,

      Propriétés à vérifier exprimées en LTL, autre
      entrée de SPIN,
         Vérification de la concordance des deux
      Transcription dans un langage plus générique
      risque de perte d’information
BPEL4WS_model-checking
Script Promela = liste de déclaration de variables, canaux et processus.

   déclaration de variables : bool b1 = false, b2 = false;
   déclaration de canaux : Transfert=[2] of {bit, short, chan};
   déclaration de processus : proctype nom ( paramètres_formels )
                               {instructions }
   instructions : [](submitToTravelAgent-><>receiveTicket && <>receiveItinerary)
Programme structuré comme avec le langage C.

Fonctionnement de SPIN :
    Mode simulation ou vérification;
    utilisé avec des options pour préciser l’opération a exécuter
BPEL4WS_LTSA-FSP

   Article de Foster sur la vérification de la
    composition de Services Web en utilisant la
    notation FSP.

   Intérêt : peu de limite de modélisation grâce à FSP


   Limites : pas de précisions sur les propriétés
    vérifiées; limites dues à la transcription.
BPEL4WS_LTSA-FSP
Principe de fonctionnement :
   Propriétés de la composition spécifiées avec
   MSC,
      Implémentation en BPEL4WS,
      Transcription de BPEL4WS en FSP,
      Comparaison des deux fichiers FSP.
BPEL4WS_LTSA-FSP

Exemple de transcription de BPEL4WS en FSP :
BPEL4WS_BPE calculus

    Article de Koshkina et Breugel

    Intérêt : vérification automatique de présence
     d’impasse. Méthode qui ne transcrit pas le langage


    Limite : trop d’éléments du langage BPEL4WS non
     pris en compte.
BPEL4WS_BPE calculus


    Principe de fonctionnement :

         Sous-ensemble de BPEL4WS  BPE calculus
      Modélisation du BPE calculus et transmission
      au PAC (Process Algebra Compiler)
      Vérification du processus avec le CWB
      (concurrency workbench)
BPEL4WS_BPE calculus




Syntaxe de BPE-calculus:
BPEL4WS_BPE calculus

Sémantique de BPE-calculus : ensemble de règles représentant le
                                 processus, ces liens et ces activités
                                 élémentaires.

Exemple de règles pour l’activité flow :




Utilisation du CWB:
   Une base extensible de propriétés vérifiées : µ-calculus
   Options de vérification disponible.
   Exemple de commande CWB :
Plate-formes de composition
        de Services
BPEL4WS_Service Composition

    Article de Chakraborty et Joshi, état de l’art
     sur les plates-formes de composition de
     services

    Intérêt : évaluer la possibilité à gérer la
     composition de service en environnement ad hoc.

    Leur propre plate-forme est en cours
     d’élaboration.
BPEL4WS_Service Composition
    Carleton University, Canada
     2 façons de composer des services :
        - interface fusion / composite service interface :
        interface représentant le service qui pourra être
        composé à un moment donné
 Limite : besoin de machines clientes puissantes

        - standalone composite service :
        Service composé autonome à base de services déjà disponibles
 Limites : services statiques et fournisseurs peu disposés à passer leur
          code pour qu’il soit exécuté sur une autre plate-forme.
          Nécessite beaucoup de ressources.
BPEL4WS_Service Composition

    Laboratoire HP
        -plate-forme d’intégration de e-services : eFlow.
     Service composé = modélisation en utilisant les principes de
     noeuds de services, noeuds d’évènements et de noeuds de
     décision.

     Système capable d’aller contacter des “service brokers”
     extérieurs pour découvrir de nouveaux services.


 Limites : architecture beaucoup trop dépendante d’un point de
          faille centrale. Pas de contrôle de respect de
          paramètres.
BPEL4WS_Service Composition

   ATL Postmaster
        -framework autonome de collaboration d’agents et de
    diffusion de l’information.
    Modification dynamique des itinéraires des agents mobiles.
    présence d’un gestionnaire d’agents dans chaque nœud :
    l’ATL Postmaster
    Collaboration entre agents, diffusion d’informations sur les
    agents d’agents en agents.


Limites : besoin de machines puissantes. Maintenance de l’information
          globale pas réalisable sur un réseau ad hoc. Pas de gestion
          de fautes , ou d’exceptions lors de l’échec d’un nœud.
BPEL4WS_Service Composition

   Ninja Service Composition Platform
       -plate-forme de composition dynamique de services.
    Accès aux même services pour des clients ayant des
    ressources et aux accès réseaux différents.
    Utilisation d’une partie APC (Automatic Path Creation), un
    service de contrôle d’accès


Limite : dépendance totale au fonctionnement de l’APC.
BPEL4WS_validation

   Recherche en pleine évolution, transcription encore
    simplifiée des langages de description de processus,
    mais des outils de vérification qui s’adapte de plus en
    plus.

   Évolution de LTSA avec Java

   Évolution de CWB : CWB-NC (New Century)
BPEL4WS_Composition

Projet de plate-forme:

   Plate-forme permettant l’accès aux informations de
    dispositifs mobiles ou fixes
   Découverte plus efficace des services : plus de
    fonctionnalités décrites.

       3
                    4
                        Plate-forme avec une entité centralisée
                        qui coordonne les différents sous-
                        composants et leurs fonctions
                2



            1
Bibliographie :
Dynamic Service Composition : State of Arts and Research Directions
       Dipanjan Chakraborty, Anupam Joshi.
       Departement of Computer Science and Electrical Engineerinf,
       University of Maryland, Baltimore County.

LTSA-BPEL4WS: Tool Support for Model-based Verification of Web
Service Compositions
        Howard Foster, Sebastian Uchitel, Jeff Magee, Jeff Kramer.
       Department of Computing, Imperial College London.
Model-based Verification of Web Service Compositions
       Howard Foster, Sebastian Uchitel, Jeff Magee, Jeff Kramer.
       Department of Computing, Imperial College London, 180 Queen's
       Gate, SW7 2BZ, UK.

Verification of Business Processes for Web Services
        Mariya Koshkina and Franck van Breugel.
       Department of Computer Science, York University,Toronto,
       Canada.
Merci de votre attention !
BPEL4WS_Collaxa
BPEL4WS_Collaxa
BPEL4WS_Collaxa
BPEL4WS_Collaxa
Exemple d’achat de billet

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:16
posted:3/4/2012
language:
pages:58