FOCAS : un canevas extensible pour la construction d’applications orientées procédé

Examinatrice

Marie-Christine ROUSSET, Professeur UJF, Grenoble

Rapporteur Carlo MONTANGERO, Professeur à l’Université de Pise, Pise

Rapporteur Claude GODART, Professeur à l’Université Henri Poincaré, Nancy

Examinatrice

Claudia RONCANCIO, Professeur à l’INPG, Grenoble

Examinateur

Hervé VERJUS, MdC à l’Université de Savoie, Chambéry

Directeur Jacky ESTUBLIER, Directeur de recherche au CNRS, Grenoble

FOCAS : UN CANEVAS EXTENSIBLE POUR LA CONSTRUCTION D’APPLICATIONS ORIENTÉES

PROCÉDÉGabriel PEDRAZA FERREIRA

Jury:

CONTEXTE

12/11/2009

2

FOCAS - Gabriel PEDRAZA FERREIRA

ProcédéLogiciel

Workflow Orchestration

Modèles Ingénierie dirigée par les modèles

Approche à services

Applications orientées procédé

Une approche dirigée par les modèles

Services

Procédés

Modèles

1990 2000 2003

CONTEXTE

12/11/2009

3


FOCAS

Un canevas dirigé par les modèles pour la construction d’ orchestrations flexibles de services.

Extensible et adaptable à « toute » application orientée procédé.

PLAN

État de l’art Les systèmes de workflow L’orchestration de services

Proposition FOCAS Noyau Les extensions fonctionnelles Les extensions non-fonctionnelles

Mise en œuvre Validation et évaluation Conclusion et perspectives

12/11/2009

4


ÉTAT DE L’ART - PROCÉDÉ

Un procédé est :« A sequence of steps performed for a given purpose »

[IEEE]« A systematic approach to the creation of a product or

the accomplishment of some task » [Osterweil]

12/11/2009

5


Un modèle de procédé sert à : comprendre et communiquer entre les acteurs, automatiser le procédé.

ÉTAT DE L’ART – LES WORKFLOWS

Un système de workflow est un logiciel qui interprète un modèle (de procédé).

12/11/2009

6


Act1

Act2

Act3

Act4

Act5

Moteur de workflow


Langages de spécification de procédés1995

Un groupe de standardisation Modèle de référence pour les systèmes de workflows Spécification ~40 pages

2007 10 groupes de standardisation 7 standards pour la modélisation des procédés Chaque spécification ~150 pages

12/11/2009

7



12/11/2009

8


Systèmes, langages et Standards de Workflow

Systèmes commerciaux

COSA, VisualWorkflow, Forté Conductor, Lotus Domino Workflow, Mobile, MQSeries/Workflow, Staffware, Verve Workflow, I-Flow, InConcert, Changengine, SAP R/3Workflow, Eastman, FLOWer, etc.

Open Source JBoss JBPM, OW2 Bonita, Active BPEL, Enhydra Shark-JaWE, etc.

Standards BPMN, UML Activities, BPEL, XPDL, SPEM, etc.

Recherche Meteor, ADEPTFlex, OpenFlow, YAWL, APEL, JOpera, etc.


YAWL XPDL jBPM APEL

Nombre de concepts

Grand Grand Petit Petit

Types d’activité

WF-Net, Manual Task, Application Task, Control Tasks

Route, BlockActivity, Implementation

Node (base)Start, End, Task, Control (extension)

Activity

Extensibilité Non documenté

Syntaxique Programmation (PVM)

Délégué

Origine Recherche Consortium Industriel Recherche

Type Système Standard Système Langage

12/11/2009

9


ÉTAT DE L’ART – LES WORKFLOWS SYNTHÈSE

Deux approches Solutions génériques contenant un nombre

élevé de concepts. Solutions spécialisées dans un domaine

spécifique difficilement adaptables. Formalismes de bas niveau d’abstraction

proches de langages de programmation. Les workflows sont fortement couplés aux

applications qu’ils utilisent. Capacités d’extension limitées ou inexistantes.

12/11/2009

10


PLAN




12/11/2009

11


ÉTAT DE L’ART – L’ORCHESTRATION DE SERVICES

12/11/2009

12


L’approche à services utilise le concept de service comme bloc de construction d’applications

Fournisseur de service

Client de service

Annuaire de services

?

Hypothèse: Un service est indépendant des autres services et du contexte d’exécution.

Mécanismes• Description• Découverte• Communication

Propriétés• Couplage faible• Liaison retardée

ÉTAT DE L’ART – ORCHESTRATION DE SERVICES

12/11/2009

13


Invo1

Invo2

Invo3

Invo4 Invo5

Orchestrateur

Un orchestrateur est un logiciel qui interprète un modèle de procédé pour coordonner l’exécution des services

S1 S2 S3 Sn

Le contrôle est externalisé. Responsabilité de l’orchestrateur.

Client

Fournisseurs

ÉTAT DE L’ART – ORCHESTRATION DE SERVICES

12/11/2009

14


WS-BPEL JOpera SELF-SERV

Type de formalisme

Blocs structurés (Type d’activités prédéfinies)

Diagramme d’activités (graphe dirigée)

Diagramme d’états et de transitions

Technologie de services

Services Web Ensemble prédéfini. Extensible.

Services Web

Liaison et sélection de services

Dynamique (Sélection mélangée avec le modèle métier)

Dynamique (Sélection mélangée avec le modèle métier)

Dynamique

Aspects non-fonctionnels

Transactions (Partiellement)

Aucun Aucun

Exécution Centralisé Centralisé Repartie

ExtensibilitéSyntaxique.BPEL4J, SCENE, BPEL4People.

Technologie de services

Aucune

ÉTAT DE L’ART – ORCHESTRATION SYNTHÈSE

Défauts hérités des workflows Formalismes de bas niveau d’abstraction. Couplage fort avec les applications

Supporte un seul type de technologie de services.

Mécanismes de sélection et de liaison mélangés avec le modèle métier.

Pas de support pour les aspects non fonctionnels.

Capacité d’extension limité ou inexistante. 12/11/2009

15


ÉTAT DE L’ART – OBJECTIF DE LA THÈSE

Proposer un canevas dirigée par les modèles pour la construction d’applications orientées procédé ayant :

noyau simple système d’orchestration de services, mécanismes d’extension fonctionnelles mécanismes d’extension non-fonctionnelles

Canevas extensible et adaptable différents domaines d’application différents environnements, …

12/11/2009

16


Objectif

PLAN




12/11/2009

17


PROPOSITION – FOCAS

FOCAS un canevas permettant la construction d’applications orientées procédés:

12/11/2009

18


FunctionalExtension

FunctionalExtension

FOCAS Core(Flexible

Orchestration)Non-functional extension

Non-functional extension

Non-functional extension

PROPOSITION – FOCAS NOYAU

FOCAS Noyau : un système d’orchestration de services

Spécification abstraite de l’orchestration Séparation des préoccupations: contrôle, données

et services Composition de services implémentés en diverses

technologies Liaison et sélection dynamique de services

12/11/2009

19


FOCAS NOYAU – UNE DESCRIPTION ABSTRAITE

Trois points de vues dans l’orchestration de services Le contrôle : ordre des invocations et flot de

données Les données : entités à traiter Les services : traitement des données

12/11/2009

20


S1

S2

S3

Sn

x

yInvo1

Invo2

Invo3

Invo4 Invo5

Chaque point de vue est formalisé en un domaine exécutable

FOCAS CORE – STRUCTURE D’UN DOMAINE

12/11/2009

21


Interpréteur de domaine

Modèle de domaine

Méta-modèle du domaine

Conforme à

Exécute

Un formalisme utilisé pour exprimer des modèles, i.e. méta-modèle.

Un interpréteur qui opérationnalise la sémantique.

Des modèles conformes au méta-modèle et exécutés par l’interpréteur.Modèle

DOMAINE DU CONTRÔLE

12/11/2009

22


Interpréteur de contrôle

Méta-modèle de contrôle

Ensemble minimal de concepts(Activity, Port, Product, ProductType, Dataflow)

Gère le contrôle et le routage des données.Gère le cycle de vie des activités.Maintient l’état du procédé.

Modèle de contrôle

DOMAINE DES DONNÉES

12/11/2009

23


Interpréteur de données

Méta-modèle de données

Typage des données(DataType, SimpleType, ComplexType, Attributes, etc)

Création, élimination, modification des données.Versionnement des données.

Modèle de données

Temperature

+value: Double+unit: String+hour: Hour

Average

+value: Double+number: Integer

public interface StoreDB { public boolean saveData(Average average);}

DOMAINE DES SERVICES

12/11/2009

24


Interpréteur de services

Méta-modèle de services

Description des services(Services, Interface, Operation, Properties)

Modèle de services

SAM (Service Abstract Machine)Description, Découverte, CommunicationHétérogénéité des technologies à services

Propriétés Protocol = DPWS

StoreDB

LA COMPOSITION DES DOMAINES

12/11/2009

25


Interpréteur de contrôle


Modèle de données

Méta-modèle du contrôle

Méta-modèle des données

Interpréteur de données

Conforme à

Exécute

méta-lien

lien

Conforme à Conforme à

Exécute

Code de synchronisation

LA COMPOSITION DES DOMAINES

12/11/2009

26


Interpréteur du contrôle


Modèle de données

Méta-modèle du contrôle

Méta-modèle des données

Interpréteur des données

Exécute

méta-lien

lien

Conforme à


L’ORCHESTRATION DE SERVICES DANS FOCAS

12/11/2009

27


GetTemperature

DoAverage

StoreDB

Temperature

+value: Double+unit: String+hour: Hour

Average

+value: Double+number: Integer

Interpréteur d’orchestration

DPWS WS Java

GetHumidity

StoreFile

Humidity

+value: Double+hour: Hour

AbstraiteFlexibleHétérogèneDynamique

FOCAS NOYAU - CONTRIBUTION

Formalismes de bas niveau d’abstraction

Couplage fort avec les applications

Support pour un seul type de technologie des services

Mécanismes de sélection et liaison mélangés avec le modèle métier

12/11/2009

28


Description abstraite de l’orchestration

Flexibilité de la spécification

Hétérogénéité des technologies à services (SAM)

Séparation des préoccupations

Support des aspects non-fonctionnels

Extensibilité de l’orchestration

PLAN




12/11/2009

29


PROPOSITION – EXTENSIONS FONCTIONNELLES

12/11/2009

30


Workflow

Bureautique

Applications à médiation

FOCAS Noyau

Autres …

Applications orientées procédé

Extensions

Objectifétendre le canevas pour supporter la création d’autres applications orientée procédé

EXTENSIONS NON-FONCTIONNELLES : AJOUT D’ACTIVITÉS HUMAINES

Dans les applications de Workflow les tâches peuvent être effectuées par des humains.

Dans les applications d’orchestration toutes les tâches sont effectuées par des services automatiques

12/11/2009

31


Object i f de l ’extens ion : supporter la réa l isat ion par des humains des tâches d ’un

procédé

EXTENSION FONCTIONNELLE – COMPOSITION DOMAINES

12/11/2009

32


Interpréteur d’orchestratio

n

Modèle d’orchestration

Modèle d ’assignation de ressources

Méta-modèle noyau

(orchestration)

Méta-modèle ressources

Interpréteur de ressources

Conforme à

Exécute

méta-lien

lien

Conforme à Conforme à

Exécute


12/11/2009

33


Director : Role

name = Director

Student : Role

name = Student

Jacky : Human

name = Estublier

Philippe : Human

name = Lalanda

Idrissa : Human

name = Dieng

Issac : Human

name = Garcia

Mod

èle

Méta

-mod

èle

Domaine d’orchestration Domaine de ressources

EXEMPLE : AJOUT DES ACTIVITÉS HUMAINES

Activity

-name: String

Port

+name: String+isAutomatic: Boolean

+entry

0..*

+exit

0..*

Role

+name: String

Human

+name: String+email: String+birthdate: Integer

0..* 0..*

EXTENSION FONCTIONNELLE – CONTRIBUTION

Le langage (méta-modèle) est étendue tout en gardant les outils de spécification.

Un modèle peut être spécifié en réutilisant les modèles existants.

L’interpréteur des modèles composites est créé en composant les interpréteurs existants. Réutilisation des interpréteurs.

12/11/2009

34


Réutilisation des langages et des éditeursCompromis entre approche spécifique et

générique


Construction d’interpréteurs modulaire

PLAN




12/11/2009

35


PROPOSITION – EXTENSIONS NON-FONCTIONNELLES

12/11/2009

36


Orchestration de services

Sécurité

Gestion de transactions

Distribution

Autres

Objectif:Proposer un mécanisme permettant le support des aspects non-fonctionnels pour l’orchestration.

SCHÉMA GÉNÉRAL EXTENSION NON-FONCTIONNELLE

12/11/2009

37


Interpréteur d’orchestration

Modèle d’orchestration

Annotations(Modèle abstrait)

Méta-modèle d’orchestratio

n

Méta-modèle aspect non-fonctionnel

Conforme à

Exécute

méta-lien

lien

Conforme àConforme à

Bibliothèque support non-fonctionnel

Code de tissage

Générateur

12/11/2009

38


Mod

èle

Méta

-mod

èle

Domaine d’orchestration Aspect de sécurité

EXEMPLE – L’ORCHESTRATION SÉCURISÉE

Activity

-name: String

Port


+entry

0..*

+exit0..*

Product

-name: String

contains

port

0..*

Authentication

-type: String

Integrity

Confidentiality

:Authentication

:Confidentiality

:Integrity

L’ORCHESTRATION RÉPARTIE

12/11/2009

39


FOCAS RuntimeFOCAS (Nœud 1) FOCAS (Nœud 2) FOCAS (Nœud 3)

Objectifs: Performance (communication, distribution de la

charge, ..) Souplesse (choix de la répartition au niveau modèle) Évolutivité (changement de topologie du réseau) Adaptabilité (différents environnement clients)

Une architecture centralisée Problèmes de performance Robustesse de l’application Passage à l’échelle

12/11/2009

40


Mod

èle

Méta

-mod

èle

Domaine d’orchestration Aspect de distribution

L’ORCHESTRATION RÉPARTIE

DBServer:Node

ApplicationServer:Node

EdgeServer:Node

Activity

-name: String

Port


+entry

0..*

+exit

0..*Node

+name: StringNetwork

1..*

ApplicationServer:Node

EXEMPLE – L’ORCHESTRATION RÉPARTIE

12/11/2009

41


DBServer

AppServer

AppServer

EdgeServer

EdgeServer

AppServer

ODS

IDS

DBServer

ODS

IDS

Transformateur

Extension non fonctionnelle mais: Algorithme de partition de modèles Composants de communication pour supporter la

distribution

EXTENSIONS NON-FONCTIONNELLES - CONTRIBUTION

Spécification abstraite des propriétés non-fonctionnelles L’utilisateur peut ne pas être expert des

technologies d’implémentation

Séparation entre la partie métier et non fonctionnelle Différentes annotations pour le même modèle

métier

Génération automatique du code de support

Une architecture répartie pour l’orchestration

12/11/2009

42


Approche d’annotations de modèles


Adaptation à la technologie d’implémentation

PLAN




12/11/2009

43


DÉMONSTRATION

CADSE-FOCAS

CADSE (Computer Aided Domain Specific Engineering environment)

FOCAS (Framework for Orchestration, Composition and Aggregation of Services)

12/11/2009

44


PLAN



Mise en œuvre L’environnement de spécification CADSE-FOCAS

Validation et évaluation Conclusion et perspectives

12/11/2009

45


VALIDATION ET EVALUATION

Projet ITEA – S4ALL Validation de l’approche de base

Project ITEA SODA Validation d’extension non fonctionnelle: la

sécurité de l’orchestration Évaluation de l’utilisabilité de l’environnement

Approche d’orchestration répartie Validation d’extension NF : la distribution Évaluation : Performance de l’exécution répartie

12/11/2009

46


VALIDATION – CAS D’UTILISATION SODA

Cas d’utilisation : système de surveillance L’application observe les conditions physiques

d’une usine et prend des mesures en conséquence

Objectif 1 : valider l’ajout non fonctionnel Étendre le canevas afin d’introduire l’aspect

sécurité dans une orchestration de services

Objectif 2 : valider l’utilisabilité et l’approche générative Expérience d’ajout de sécurité pour notre cas

d’utilisation.

12/11/2009

47


EVALUATION CADSE-FOCAS

Expérience: ajout de la sécurité 3 scénarios de sécurisation de l’application 8 développeurs ont réalisé les scénarios 2 fois 2 experts technologie sécurité ont réalisé les

scénarios sans CADSE-FOCAS

12/11/2009

48


Scénario Session 1

Session 2

Experts % Session 1

% Session 2

1 13:20 05:21 23:00 44% 79%

2 07:49 05:33 24:00 71% 79%

3 03:22 02:10 15:00 80% 86%

EXPÉRIENCE ORCHESTRATION RÉPARTIE

12/11/2009

49


FOCAS –Nœud 1 FOCAS –Nœud 2

S1 S2 S3 S4

Nœud 1 Nœud 2 Total %

Cas 0 349,20 0,00 349,20

Cas 1 262,27 50,07 318,55 8,78%

Cas 2 216,53 66,93 286,87 17,85%

Cas 3 161,93 91,47 256,46 26,56%

Cas 4 130,20 120,33 256,03 26,68%

Objectif: Réduire le temps de communication de l’orchestrationMoyen: Déplacer des fragments vers le nœud où les services sont locaux

EXPÉRIENCE ORCHESTRATION RÉPARTIE

12/11/2009

50


Objectif: Réduire le temps d’exécution d’une orchestration parallèleMoyen: Exécuter chaque branche dans un nœud différent

FOCAS –Nœud 1

FOCAS –Nœud 3

FOCAS –Nœud 2

Nœud 1

Nœud 2

Nœud 3

Total %

Cas 0 550,81 0,00 0,00 550,81

Cas 1 420,73 193,88 0,00 420,73 23,62%

Cas 2 265,76 187,14 171,23 265,76 51,75%

PLAN



Mise en œuvre L’environnement de spécification CADSE-FOCAS

Validation et évaluation Conclusion et perspectives

12/11/2009

51


CONCLUSIONS

Une approche IDM pour la construction des applications orientées procédés qui préconise: Séparation des préoccupations Réutilisation Langages de haut niveau d’abstraction

Un système de base pour l’orchestration de services Technologies de services hétérogènes Mécanismes de sélection et de liaison dynamique

Des mécanismes d’extension fonctionnelle Des mécanismes d’extension non fonctionnelle Une implémentation du canevas FOCAS

12/11/2009

52


PERSPECTIVES

Un ensemble de CADSE pour supporter le cycle de vie du génie logiciel.

Des applications orientées procédés dynamiques qui peuvent s’adapter à l’exécution.

Une approche pour la chorégraphie de services.

Expérimenter avec d’autres aspects non-fonctionnels.

Expérimenter d’autres domaines d’application.12/11/2009

53


12/11/2009

54


MerciQuestions ?

Documents

FOCAS : un canevas extensible pour la construction d’applications orientées procédé