Introduction à l’Architecture

Orientée Service
1ère année Master SIC – SIR - WIC

-1-
 Plan du cours
• A quels besoins répond le SOA ?
• Pourquoi les solutions actuelles sont insuffisantes ?

• Quels sont les principes de base du SOA ?

• Quels sont les éléments clé d’une architecture

orientée services ?

• Quel est le cycle de vie d’un service ?

• Quelles méthodes et outils permettent de mettre en

oeuvre une architecture orientée services ?

-3-
 Plan du cours
• A quels besoins répond le SOA ?
• Pourquoi les solutions actuelles sont
insuffisantes ?

• Quels sont les principes de base du SOA ?

• Quels sont les éléments clé d’une architecture

orientée services ?

• Quel est le cycle de vie d’un service ?

• Quelles méthodes et outils permettent de mettre en

oeuvre une architecture orientée services ?

-4-
 Problématique de l’intégration en
entreprise
• La création d'applications dans l'entreprise est très
souvent pilotée par des besoins à très court terme
 Développement d'une application sous tel délai avec
telles fonctionnalités

• Modélisation et développement dirigé par les

choix/contraintes techniques
Pas de discussion entre maitrise d'ouvrage
(MOA) et maitrise d'oeuvre (MOE)

 Décalage entre besoins métier et leur

réalisation (constituants informatiques)
 Pas de place pour la prise en compte de
l'évolution des besoins fonctionnels au niveau
de l'application
-6-
 Problématique de l’intégration en
entreprise
• Le découpage présentation/traitement/base de
données de l'architecture 3-tiers facilite le travail de la
MOE mais favorise le cloisonnement en silos
applicatifs indépendants (blocs monolithiques)
• Certaines fonctions sont redondantes : une version
pour chaque application

 Pas de mutualisation des développements entre

projets et peu de réutilisation possible
-7-
 Problématique de l’intégration en
entreprise
• Entreprises découpées en départements fonctionnels y
compris le SI
• Processus métiers de + en + inter-départementaux
• Les processus franchissent les fontières de l'entreprise
qui doit pouvoir prendre en compte les activités et
processus des partenaires pour être reactive

 Coûts considérables dans la gestion des flux

entre départements et dans l’intégration de
leurs SI
-8-
 Hier : plat de spaghettis

• Développements coûteux
• Interconnexions redondantes (point à point)
• Grande complexité
• Maintenance difficile
-9-
 Vers toujours plus d'abstraction

• Procédures

• Modules

• Modèles orientés objets

– Packages

– Encapsulation

• Design pattern

• ...
- 10 -
Limites de la programmation orientée Objet

• Structure et architecture de l’application peu

visibles

• Interactions entre objets enfouies dans le code

• Évolution / modification difficile

• Recherche des bouts de code impliqués source

d’erreur

• Gestion de la consistance d’un changement

délicate
- 11 -
 Objets et encapsulation
 Granularité encore trop fine
 Mal adaptée à la programmation à grande
échelle

Couplage fort
 Rend difficile la réutilisation
 Accroît la complexité des Systèmes OO

- 12 -
 Encore plus de structuration avec les
composants logiciels
Analogie avec les composants
électroniques, legos, puzzles

- 13 -
 Un Composant : Qu’est-ce que c’est ?

Définition usuelle
 Une unité regroupant les fonctionnalités
concernant une même idée
 Un module logiciel autonome pouvant être installé
sur différentes plates-formes
 qui exporte des attributs et des méthodes
 qui peut être configuré (déploiement semi
automatique)
 capable de s’auto-décrire

Intérêt
Être des briques de base configurables pour
permettre la construction d’une application par
composition
- 14 -
 Structure d’un composant
Interactions avec un composant
 ce qui est fourni par le composant
 ce qui est utilisé par le composant
 modes de communication

Configuration du composant
 propriétés (attributs publics)
 connexions
 cycle de vie (arret, redemarrage, ...) Interface de
 contraintes techniques configuration
(transaction, persistance, sécurité, ...)
…

Interfaces
Interfaces

requises
fournies

- 15 -
 Re-configuration dynamique
Consommer:
payer,
selectionner, Facturer:
prendre encaisser,
rendreMonnaie
Gerer:
ouvrir, Distributeur de Facturation
remplir,
mettreMonnaie boissons version 1
Réparer: Facturer:
ouvrirCapot, encaisser,
fermerCapot rendreMonnaie

« Just in time binding »

Facturation
Permet de modifier l'application version 2
à chaud sans modification du code
Facturer:
en manipulant les assemblages encaisser,
rendreMonnaie

- 16 -
 Les composants dans la nature
La modélisation des composants logiciels est intégrée
à UML 2.0
Spécification :
Composants CORBA (CCM)
Spring (JEE beans for Web apps)
Fractal (Etendu pour le réparti, voir
GridComponentModel – Equipe I3S/INRIA OASIS)
SCA (Service component Architecture) =>
utilisé pour SOA (voir OSOA Tuscany, HydraSCA,
IBMWebSphere pack for SOA, etc)
Plates-formes d'éxecution
OpenCCM (GridCCM, Equipe PARIS IRISA Rennes)
Julia (Fractal), ProActive (GCM)
Sofa (Fractal)
... - 17 -
 Convergence Composants / Services
• Exposer les interfaces offertes par les composants selon
une technologie au choix; Par exemple
– Services web, avec binding SOAP
– Interface Java avec binding RMI ou JMS
• Principe suivi par la norme SCA : Service Component
Architecture
– Notion de Composite Service

- 18 -
Convergence Composants / Services : Exemple

From :
- 19 -
 Demain : Architecture urbanisée
• L’urbanisation informatique définit l'organisation d’un SI à
l’image d’une ville
− découper le SI en modules autonomes (zone, quartier, îlot, bloc)
− localiser les zones d’échange d’informations (routes, ponts, tunels)
qui permettent de découpler les différents modules

• Objectif : faire évoluer le SI au même rythme que la

stratégie et l'organisation des métiers de l'entreprise

legacy services portail

...

Canal d'échange
données processus partenaires
...
Non-
Interruptible

Receive Invoke Invoke Reply

Reply
Invoke
Fault

- 20 -
 Plan du cours
• A quels besoins répond le SOA ?
• Pourquoi les solutions actuelles sont insuffisantes ?

• Quels sont les principes de base du

SOA ?

• Quels sont les éléments clé d’une architecture

orientée services ?

• Quel est le cycle de vie d’un service ?

• Quelles méthodes et outils permettent de mettre en

oeuvre une architecture orientée services ?

- 21 -
Principes fondamentaux de l’architecture
SOA
Il n’existe pas une recette pour garantir le
succès de la mise en place d’une SOA mais des
principes à respecter :

– Discussion entre métier et IT

– Utilisation des use case métier

– Utilisation de standards
– Pas de remise en cause de l’existant lors
d’évolutions technologiques

– Découplage entre fournisseur et

consommateur de services
– Indépendance des ressources vis à vis de
ceux qui les utilisent
- 22 -
Qu’est ce qu’un Service (au sens SOA)
?
• Partage les caractéristiques suivantes d’un objet
– Modulaire (ensemble de fonctionnalités qui font sens)

• Partage les caractéristiques suivantes d’un

composant
– Boite noire (séparation interface/implémentation)
– Indépendant de la localisation
– Neutralité vis-à-vis des protocoles de transport

• Correspond à un périmètre fonctionnel que l’on

souhaite exposer à des consommateurs
• Est faiblement couplé (indépendant des autres
services)
• Expose un petit nombre d’opérations offrant un
traitement de bout en bout
• Sans état
- 23 -
 4 propriétés du service à retenir

• Un Service est • Un Service expose un

Autonome Contrat
et sans état (en
Conditions Générales de
général, c.ex WSRF) Vente
in Règlement Intérieur
Vos droits/Vos devoirs
out

• Les services
• Les Frontières entre
communiquent par
services sont messages
Explicites

- 24 -
 Exemple de couplage fort : Gestion de
prêts
Entités
LoanAgent LoanApproval Account Loan SMSGateway

calculateRisk
checkCredit

createLoan

sendConfirmati
on

 LoanAgent est lié à LoanApproval et Loan

 LoanApproval est lié à Account
 Loan est lié à SMSGateway

- 25 -
 Gestion de prêts en couplage faible
Services
LoanProcess CheckAccount Calculate CreateLoan Notify
Balance LoanRisk ViaSMS

 Qu’est ce que LoanProcess ?

 Un processus métier !
Il permet d’orchestrer les services =>
couplage lâche
- 26 -
Business Process Management (BPM)
• But : Donner à l'Entreprise les moyens de gérer ses processus
métiers de manière informatisée (modélisation, simulation,
exécution et audit)
– Optimisation, adaptation aux besoins en temps réel

• Un processus est composé de sous processus, de

décisions (Business rules) et d’activités
• Un sous processus a son propre but, entrées et sorties
• Les activités
– correspondent aux parties du processus métier qui n’incluent pas
de décision et sont associées à des rôles
– Sont réalisées par des systèmes ou des humains

• Des mesures (KPI pour Key Performance Indicators)

permettent de capturer les performances du processus

• Un processus est le résultat d’une orchestration de

service
• Le processus est lui-même accessible en tant que service
- 27 -
BPM par l’exemple

- 28 -
 C
au ou
p
n la
iv g
ea e
u fai
lo bl
g e
iq
u
e

C
**

ou
p
la
C g
e
au ou fo
ou n pla rt
Les couches SOA

vi a iv g
si u ea e
on n u fa
i i
Ex S ve te ble
C a ch
: A u
modes de

lo niq
g u
niveau dans

iq e
u
l’architecture
Ces différents

dépendent du
couplage sont
nécessaires et

e
:
- 29 -
 e-store : Couches
AccountController CartController

Default
SignOut SignIn Search Category Items Item Shopping Help Error
Details Cart
Presentation
Layer

Check Order Order Order

My Edit Create
out Billing Shipping Process
Account Account Account

Account Profile Product Item Inventory Cart OrderInsert OrderRead

Business
Logic
Layer

IAccount IProfile IProduct IItem IInventory IOrder

Data
Access
Layer

- 30 -
 e-store : Domaines

Default
SignOut SignIn Search Category Items Item Shopping Help Error
Details Cart
Presentation
Layer

Check Order Order Order

My Edit Create
out Billing Shipping Process
Account Account Account

Account Profile Product Item Inventory Cart OrderInsert OrderRead

Business
Logic
Layer

1.0 1.0 10.0 5.1 1.0

1.1 2.0 11.2 5.2 6.0
1.2 3.5 11.5 5.3 7.0
IAccount IProfile IProduct IItem IInventory IOrder
Data
Access
Layer

Customer Catalog Inventory Shopping Billing

- 31 -
 e-store : Domaines

Presentation
Layer

Business
Logic
Layer

Data
Access
Layer

Customer Catalog Inventory Shopping Billing

- 32 -
 e-store : Services

Presentation
Layer

Business
Logic
Layer

Service Manage Show Make

Layer Shop Bill
Customer Catalog Inventory

Data
Access
Layer

- 33 -
 Bénéfices métier
• Améliorer l’agilité et la flexibilité du métier
• Faciliter la gestion des processus métier

• Offrir la capacité à casser les barrières

organisationnelles (silos)
• Réduire en temps le cycle de
développement des produits

• Améliorer le retour sur investissement

• Accroître les opportunités de revenu

- 34 -
 Bénéfices techniques

• Réduire la complexité de la solution

• Construire les services une seule fois et

les utiliser fréquemment

• Garantir une intégration standardisée et

le support de clients hétérogènes

• Faciliter la maintenabilité

- 35 -
 Plan du cours
• A quels besoins répond le SOA ?
• Pourquoi les solutions actuelles sont insuffisantes ?

• Quels sont les principes de base du SOA ?

• Quels sont les éléments clé d’une

architecture orientée services ?

• Quel est le cycle de vie d’un service ?

• Quelles méthodes et outils permettent de mettre en

oeuvre une architecture orientée services ?

- 36 -
 Points clés de l’architecture
1.a Search for service

Service Repository
consumer 1.b Return contract
Contract

2.a Create a process instance

Mediation layer/Service bus

2.c Retrieve
2.d Send request service end-point
2.b
Execute
process
Service
provider Business service
orchestrator Registry
Business
process description
- 37 -
 Standards de l’architecture
Les standards sont un élément clé d’une SOA, ils
assurent l’interopérabilité

SOAP WSDL UDDI BPEL

W3C W3C Microsoft, IBM, HP Oasis
Simple Object Web Services Universal Description Business Process
Access Protocol Description Language Discovery and Integration Execution Language

Transporte Décrit le contrat Spec pour Décrit les

Repository/Registry processus métier

Les trois piliers des Services Web

- 38 -
 SOA et web services

• Attention à ne pas confondre les 2 !

– SOA est un ensemble de concepts :
Une SOA peut se mettre en œuvre sans Web
Services

– Les WS sont de l’ordre de la technologie :

On peut utiliser les Web Services sans faire de
SOA

• Les WS constituent la meilleure solution

standardisée disponible
– Un service métier = un webservice

- 39 -
 Le langage BPEL

• Standard de l’OASIS
• Norme permettant de décrire des processus en
XML

• Propose les fonctions basiques d’un langage de

programmation:
– sequence, flow, loop, switch…

• Identification des Instances de Process

• Gestion des transactions longue durée (scope,

compensation)

• Gestion des fautes

- 40 -
BPEL le chef d’orchestre

- 41 -
 BPEL par l’exemple
<PartnerLink> references to the
PartnerLink
services participating in the process flow
<invoke> a credit rating service synchronously
<faultHandlers> catch and manage
exceptions when customer
has a bad credit history

<flow> initiates asynchronous loan processors in parallel of execution

<receive> asynchronous callbacks

from longrunning loan processors

<switch> to the lowest loan offer flow PartnerLink

loan.bpel

PartnerLink

- 42 -
Quelques détails sur le langage BPEL

• Transparents 52 -> 67 de
http://arcad.essi.fr/riveill.old/enseignement/2007-08/SAR
02/SAR%2002%20bpel.pdf

- 43 -
 ESB : couche de médiation

An enterprise service bus (ESB) is a software

architecture model used for designing and
implementing communication between
mutually interacting software applications in
a service-oriented architecture (SOA). As a
software architectural model for distributed
computing it is a specialty variant of the more
general client server model and promotes
agility and flexibility with regards to
communication between applications. Its
primary use is in enterprise application
integration (EAI) of heterogeneous and
- 44 -
 ESB : couche de médiation
• C’est le point d’entrée vers un service => invocation
indirecte du service au travers du bus
• Ce point d’entrée doit être normalisé mais on ne sait pas
qui fournit le service et comment il le fournit
(implémentation).
• Infrastructure qui optimise les échanges entre
consommateurs et fournisseurs de services. Il peut
prendre en charge :
– Routage
– transformation des données
– transactions,
– sécurité,
– qualité de service,
–…
Ex: voir http://petals.ow2.org/what-is-petals-esb.html
• Le but d’un ESB est de permettre de communiquer de
manière simple et standardisée entre des applications
hétérogènes

- 45 -
Quelques manières d’implémenter un
ESB
• Intergiciels de type MOM (Message Oriented
Middleware)
• Intergiciels de type Bus (CORBA par exemple)
• Intergiciels de type EAI (Message Broker avec
connecteurs propriétaires liés au moteur
d’intégration)
• Routeurs Web services tel que WebSphere Web
Services Gateway

 Selon le type d’implémentation retenu, l’ESB

assurera plus ou moins de “services” : le
choix dépend des besoins

 L’ESB n’est pas obligatoire : mais il est

fortement recommandé pour éviter le
couplage entre fournisseur et consommateur
- 46 -
Exemples d’architecture techniques se
basant ou pas sur un ESB
Avec ESB Sans ESB

• Communications initiées par les

applications seront donc
• Plusieurs connecteurs homogènes
• Orchestration importante • Pas d‘orchestration, parce que pas
• Transactions d’intermédiaire: invocations de
conséquentes services directement pilotées par
le code
• Peu de transactions, ou alors les
- 47 -
Intégration applicative via un bus JBI

• Dans cet exemple, hormis le BPEL process, tous les autres éléments applicatifs
sont des services externes au bus.
• Mais, par ex. un élément pourrait être un autre BPEL process ou un composant EJB,
ou autre, déployé DANS le bus, et vu comme un service interne.
• Mais, est un composant applicatif
- 48 -
Specification JBI pour ESB (ouvert)

• BC et SE peuvent se rajouter (et s’enregistrer)

sur le bus dynamiquement

- 49 -
 Plan du cours
• A quels besoins répond le SOA ?
• Pourquoi les solutions actuelles sont insuffisantes ?

• Quels sont les principes de base du SOA ?

• Quels sont les éléments clé d’une architecture

orientée services ?

• Quel est le cycle de vie d’un service ?

• Quelles méthodes et outils permettent de mettre en

oeuvre une architecture orientée services ?

- 50 -
Découpage du cycle de vie d’un
service

• 4 grandes phases :
– Identification
– Spécification
– Développement
– Gestion

• 1 aspect tranversal : la gouvernance

– Les architectures orientées service
impliquent une vision globale
– La gouvernance permet de casser les silos
de l’entreprise

- 51 -
 Cycle de vie des services (activités de
gouvernance)
yes Service Owner
Search for Approval
Service
Existing exists?
Identified
Implementation Service Candidate
no reusability Consumers
Service Identification Commission Identified

Service Specification Created

Service
Provider Interfaces Documented Specification
Review
Service/Process Workflow Created
Service Specification

Develop Integrate Create Acceptance Code in

Components & Test Deployment Unit Test repository
Service Development

Plan Decommis Deprec

Certify Service in Service Monitor
New sion ate
Service registry in use service
Version Service Service

Service Management
- 54 -
 Rôles associés au cycle de vie des services
t io io n
ca Analyste métier a t
ifi fi c Architecte
t c i
en pé
Id • Définit les processus métiers et les S • Définit les services pour les use
n KPI associées cases
• Identification des services métier • Modélise les services
• Optimise les processus via la
simulation
n t n t
e e
em em
p Intégrateur p Développeur
lop lop
v e • Assemble les services v e• Implémente les services
D é D é

io n Gestionnai
est
G re
• Publie les services
• Gère le cycle de vie des
services
• Contrôle la qualité de service

- 55 -
 Zoom sur la phase d’identification
• Un des problèmes centraux pour mettre en œuvre une
SOA
• La granularité des services est fondamentale
– détermine en grande partie la réutilisabilité des services
• Or succès SOA = % de réutilisation des services

• Éviter une granularité trop fine qui entraîne :

– beaucoup d’interactions
– des problèmes de performance

• On recommande des services à “gros grain”

– attention à une granularité trop “épaisse”
– un service qui fait trop de chose, risque de ne pas être réutilisable

 Trouver le juste milieu

- 56 -
 2 méthodes d’identification des services
• Une première phase d'indentification doit être effectuée sur
l'ensemble du SI dans le cadre de son urbanisation en s'appuyant
sur la cartographie des domaines métiers de l'entreprise et sur le
code existant
• Approche incrémentale : une phase d'identification est nécessaire
au démarrage de chaque nouveau projet SOA en s'appuyant sur
les processus et services répertoriés précédemment

• Approche Bottom-up :
– On part des briques informatiques, on rassemble les bouts
(abstraction)
– Réalisée généralement par la MOE
– Plus adéquat pour réutiliser l’existant non “SOA-isé”

• Approche Top-down :
– On part des interactions métier pour aboutir aux interactions
techniques
– Réalisée généralement par la MOA
– Plus adéquat pour démarrer un nouveau projet - 57 -
 Approche “Outside in”

• Dans la pratique on utilise rarement une seule approche

• Pour obtenir une granularité pertinente des services, il

est nécessaire de concilier les 2
– Faire l’analyse Top-down sans se préoccuper de l’existant
– Faire l’analyse Bottom-up en ne considérant que l’existant
– Comparer les services “remontés” avec ceux déduits des
processus
– Faire les compromis nécessaires pour réutiliser le maximum de
code

- 65 -
Zoom sur la phase de spécification
• Les services identifiés ne doivent pas être
tous publiés :
– Chaque service a un coût et un risque
– Il faut éviter la prolifération des services
Candidate
Candidate
Services
Services

• Le “Service Litmus Test”

d'IBM aide à Business Alignment
Composability

trouver les “bons” Externalized Service Description

Redundancy Elimination

services à exposer
SLT

Services
Services
(exposed)
(exposed)

- 66 -
Quelques critères d' “exposabilité”
• Le potentiel d'un service est d'autant plus
important qu'il :
– permet d'automatiser un processus métier
critique
– est réutilisable par plusieurs domaines métiers
– remplace une application désuette
– supporte des besoins non fonctionnels (sécurité,
logging, monitoring, ...)

• Les services non exposés

- 67 -
 Location de véhicules : services exposés

0.Rent Vehicle

1.1 1.2 1.3

Reserve Check-out Check-in
Vehicle Vehicle Vehicle

1.1.1 1.1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.3.1 1.3.2 1.3.3 1.3.4
Check Make Locate Modify Create Rental Sign-out Locate Rental Process Return Process Return
Rates Reservation Reservation Reservation Agreement Vehicle from Lot Agreement Information Payment Vehicle to Lot

1.1.2.1 1.1.2.2 1.1.2.3 1.1.2.4 1.1.2.5

Confirm Rental Get Customer Get Payment Confirm Create
Information Information Information Reservation Reservation

1.1.1.1 1.1.1.2 1.1.1.3 1.1.1.4 1.1.1.5 1.1.1.6

Get Location Get Date / time Choose Get Options Check Vehicle Offer Rates
(Pick-up/drop-off) (Pick-up/drop-off) Vehicle Information Availability For Selection

- 68 -
 Exemple : quels sont les services
exposables ?
•A basic calculator for performing simple
arithmetic operations (+, -, *, /)

•A printing application, shared by multiple

applications, running in multiple environments

•A credit card authorization application

•A Database lookup that returns application-

specific data

•A composite database lookup for customer

information, searching across multiple
databases - 69 -
 Plan du cours
• A quels besoins répond le SOA ?
• Pourquoi les solutions actuelles sont insuffisantes ?

• Quels sont les principes de base du SOA ?

• Quels sont les éléments clé d’une architecture

orientée services ?

• Quel est le cycle de vie d’un service ?

• Quelles méthodes et outils permettent

de mettre en oeuvre une architecture
orientée services ?
- 70 -
Méthodes de conception des services

• SOMA (IBM)
• SODA (De Gamma)
• Praxeme (Unilog Management et
Orchestra Networks)
• + toutes les formations proposées par
les éditeurs tels que Softeam (SEA),
DreamSoft, etc sur leur “savoir-faire”

 Autant d’offres que de méthodes

différentes : de quoi s’y perdre !

- 71 -
 Modeleurs de processus

Outils de modélisation des processus métier

− IBM WebSphere Business Modeler

– Bull Bonita
– De Gamma BPM
– MEGA
– Aris
– Corporate Modeler
– WinDesign
– Power AMC
– Popkin System Architecture

- 72 -
Moteurs d’exécution de processus
• Plate-forme d’intégration
– IBM Websphere Process Server
– BEA Weblogic Integrator/Acqualogic
– Microsoft Biztalk
– De Gamma Workflow
– Oracle BPEL PM
– Bull Orchestra
– SAP “Netweaver”
– Apache ODE

• ESB
– IBM Websphere ESB
– Celtix hosted on ObjectWeb/IONA Technologies
– OpenESB (java.net)
– Mule (codehaus.org)
– Sonic ESB
– EBM Web Sourcing Distributed Petals Bus (on OW2)

- 73 -
 Contrôleurs/moniteurs

• BAM (Business Activity Monitoring)

− IBM WebSphere Business Monitor
− Oracle BAM
− Systar Business Bridge
− BMC Service Impact Manager

• Composants de sécurité
− Oracle Web Service Manager
− Oblix

- 74 -
 Exemple: Gamme d'outils IBM couvrant le cycle de vie
complet

Business Analyst Service Architect

WebSphere Business Rational Software

Modeler Architect
Service
Specification
BPEL WSDL
Developer

WebSphere Rational Application

KPIs Integration Developer
Integration Developer
Developer
Service
Development

WebSphere Service
Repository & Registry
Service Registrar

Governance Performance
Business Analyst Server Administrator Manager Manager

WebSphere Business WebSphere Process Server WebSphere

Monitor WebSphere ESB Business Services
Fabric
Service execution &
- 75 -
Conclusions

- 76 -
 Du déjà vu ?
SOA est une évolution des plate-forme passées, tout en
préservant les caractéristiques réussies des architectures
traditionnelles

– Contractualisation des services

• Design by Contract (Meyer)

– Découplage Interface/Implémentation,
interopérabilité, transparence des communications,
…
• Middlewares à la CORBA

– Découplage fournisseur/comsommateur
• Message Oriented Middleware (MOM)

– Orchestration des services

• Travaux autour des workflows, langages de coordination

 SOA est une évolution plutôt qu’une révolution

- 77 -
 Chronique d’une évolution

objets
Langages machine

Langages *
procéduraux **
Assembleur

services
composants services

01011
10100
11000
01011

 Niveaux d’abstraction grandissant

- 78 -
 Synthèse

Depuis… …Vers…

• Orienté fonctionnalités • Orienté processus

• Conçu pour durer • Conçu pour changer
• Cycle de développement • Développement et
long déploiement interactif

• Silos applicatifs • Orchestration de Services

• Couplage fort • Couplage faible
• Orienté Objet • Orienté message

- 79 -
 Avantages et inconvénients
 Architecture adaptative
 Réutilisation du code
 Utilisation de standards
 Productivité accrue

Manque de maturité des standards

Lenteur d’exécution
Difficile à effectivement implémenter
Encore peu de chose sur la
contractualisation

- 80 -
 Quelques références ...
• “Urbanisation et BPM” - Yves Caseau, DSI
Bouygues Télécom, Edition Dunod

• SOA à la sauce IBM

http://www-306.ibm.com/software/fr/soa/

• SOA à la sauce Orchestra

http://www.orchestranetworks.com/fr/soa/index.cfm

• CBM appliqué au scénario Rent-a-car

http://www.research.ibm.com/journal/sj/444/cherbako
v.html

- 83 -
 Quelques références ...

• Composants
– CCM spec
http://www.omg.org/cgi-bin/doc?ptc/2002-08-03
– Fractal spec (GCM spec: proactive.inria.fr)
http://fractal.objectweb.org/
– Service Component Architecture (SCA)
http://www-128.ibm.com/developerworks/library/specification/
ws-sca/
– OpenCCM
http://openccm.objectweb.org/
– Sofa
http://dsrg.mff.cuni.cz/projects/sofa/tools/doc/
compmodel.html

- 84 -