Introduction lArchitecture

Oriente Service
Modules SAR O2/SAR O3 SI3
Revu par F. Baude, M2 MIAGE
NTDP, 2008
(essentiellement simplification,
raccourcissements, + quelques details)

Plan du cours
A quels besoins rpond le SOA ?
Pourquoi les solutions actuelles sont insuffisantes ?
Quels sont les principes de base du SOA ?
Quels sont les lments cl dune architecture oriente
services ?
Quel est le cycle de vie dun service ?
Quelles mthodes et outils permettent de mettre en
oeuvre une architecture oriente services ?

A quels besoins rpond le SOA ?

Pourquoi les solutions actuelles sont
insuffisantes ?

Problmatique de lintgration en entreprise

La cration d'applications dans l'entreprise est trs
souvent pilote par des besoins trs court terme
Dveloppement d'une application sous tel dlai avec telles
fonctionnalits
Modlisation et dveloppement dirig par les
choix/contraintes techniques
Pas de discussion entre maitrise d'ouvrage (MOA) et
maitrise d'oeuvre (MOE)
Dcalage entre besoins mtier et leur ralisation
(constituants informatiques)
Pas de place pour la prise en compte de l'volution des
besoins fonctionnels au niveau de l'application

Problmatique de lintgration en entreprise

Le dcoupage prsentation/traitement/base de donnes
de l'architecture 3-tiers facilite le travail de la MOE mais
favorise le cloisonnement en silos applicatifs indpendants
(blocs monolithiques)
Certaines fonctions sont redondantes : une version pour
chaque application

Pas de mutualisation des dveloppements entre projets

et peu de rutilisation possible

Problmatique de lintgration en entreprise

Entreprises dcoupes en dpartements fonctionnels y
compris le SI
Processus mtiers de + en + inter-dpartementaux
Les processus franchissent les fontires de l'entreprise
qui doit pouvoir prendre en compte les activits et
processus des partenaires pour tre reactive

Cots considrables dans la gestion des flux entre

dpartements et dans lintgration de leurs SI

Hier : plat de spaghettis

Dveloppements coteux
Interconnexions redondantes (point point)
Grande complexit
Maintenance difficile

Vers toujours plus d'abstraction

Procdures
Modules
Modles orients objets
Packages
Encapsulation

Design pattern
...

Limites de la programmation oriente Objet

Structure et architecture de lapplication peu visibles
Interactions entre objets enfouies dans le code
volution / modification difficile
Recherche des bouts de code impliqus source
derreur
Gestion de la consistance dun changement dlicate

Objets et encapsulation
Granularit encore trop fine
Mal adapte la programmation grande chelle
Couplage fort
Rend difficile la rutilisation
Accrot la complexit des Systmes OO

Encore plus de structuration avec les

composants logiciels
Analogie avec les composants
lectroniques, legos, puzzles

Un Composant : Quest-ce que cest ?

Dfinition usuelle

Une unit regroupant les fonctionnalits concernant

une mme ide
Un module logiciel autonome pouvant tre install sur
diffrentes plates-formes
qui exporte des attributs et des mthodes
qui peut tre configur (dploiement semi
automatique)
capable de sauto-dcrire

Intrt

tre des briques de base configurables pour permettre

la construction dune application par composition

Structure dun 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

Interface de
configuration

Interfaces
requises

Interfaces
fournies

proprits (attributs publics)

connexions
cycle de vie (arret, redemarrage, ...)
contraintes techniques
(transaction, persistance, scurit, ...)

Re-configuration dynamique
Consommer:
payer,
selectionner,
prendre
Gerer:
ouvrir,
remplir,
mettreMonnaie

Facturer:
encaisser,
rendreMonnaie

Distributeur de
boissons

Rparer:
ouvrirCapot,
fermerCapot

Facturation
version 1
Facturer:
encaisser,
rendreMonnaie

Just in time binding

Permet de modifier l'application
chaud sans modification du code
en manipulant les assemblages

Facturation
version 2
Facturer:
encaisser,
rendreMonnaie

Les composants dans la nature

La modlisation des composants logiciels est intgre
UML 2.0
Spcification :
Composants CORBA (CCM)
Spring (JEE beans for Web apps)
Fractal (Etendu pour le rparti, 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)
...

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

Convergence Composants / Services : Exemple

From :

Demain : Architecture urbanise

Lurbanisation informatique dfinit l'organisation dun SI
limage dune ville
dcouper le SI en modules autonomes (zone, quartier, lot, bloc)
localiser les zones dchange dinformations (routes, ponts, tunels) qui
permettent de dcoupler les diffrents modules

Objectif : faire voluer le SI au mme rythme que la stratgie

et l'organisation des mtiers de l'entreprise
legacy

services

portail

...
Canal d'change
donnes

processus

partenaires

...

Quels sont les principes de base du SOA ?

Principes fondamentaux de larchitecture SOA

Il nexiste pas une recette pour garantir le succs
de la mise en place dune SOA mais des principes
respecter :
Discussion entre mtier et IT
Utilisation des use case mtier
Utilisation de standards
Pas de remise en cause de lexistant lors
dvolutions technologiques
Dcouplage entre fournisseur et consommateur
de services
Indpendance des ressources vis vis de ceux
qui les utilisent

Quest ce quun Service (au sens SOA) ?

Partage les caractristiques suivantes dun objet
Modulaire (ensemble de fonctionnalits qui font sens)

Partage les caractristiques suivantes dun composant

Boite noire (sparation interface/implmentation)
Indpendant de la localisation
Neutralit vis--vis des protocoles de transport

Correspond un primtre fonctionnel que lon souhaite

exposer des consommateurs
Est faiblement coupl (indpendant des autres services)
Expose un petit nombre doprations offrant un
traitement de bout en bout
Sans tat

4 proprits du service retenir

Un Service est Autonome
et sans tat (en gnral,
c.ex WSRF)

Un Service expose un
Contrat
in

Conditions Gnrales de Vente

Rglement Intrieur
Vos droits/Vos devoirs

out

Les Frontires entre

services sont Explicites

Les services communiquent

par messages

Exemple de couplage fort : Gestion de prts

Entits
LoanAgent

LoanApproval

calculateRisk

Account

Loan

SMSGateway

checkCredit

createLoan
sendConfirmation

LoanAgent est li LoanApproval et Loan

LoanApproval est li Account
Loan est li SMSGateway

Gestion de prts en couplage faible

Services
LoanProcess

CheckAccount
Balance

Calculate
LoanRisk

CreateLoan

Notify
ViaSMS

Quest ce que LoanProcess ?

Un processus mtier !
Il permet dorchestrer les services => couplage lche

Business Process Management (BPM)

But : Donner l'Entreprise les moyens de grer ses processus
mtiers de manire informatise (modlisation, simulation,
excution et audit)
Optimisation, adaptation aux besoins en temps rel

Un processus est compos de sous processus, de dcisions

(Business rules) et dactivits
Un sous processus a son propre but, entres et sorties
Les activits

correspondent aux parties du processus mtier qui nincluent pas de

dcision et sont associes des rles
Sont ralises par des systmes ou des humains

Des mesures (KPI pour Key Performance Indicators) permettent

de capturer les performances du processus
Un processus est le rsultat dune orchestration de service
Le processus est lui-mme accessible en tant que service

BPM par lexemple

Ex
:

Co
up
l

ag
e

fo
rt

**

Co
au up
ou n lag
vi a ive e
si u au fa
on n
i v te i b l
S C ea c e
A u hn i
lo q
gi ue
qu
e
:

Co
au up
ni lag
ve e
au fa
l o i bl e
gi
qu
e

Les couches SOA

Ces diffrents
modes de couplage
sont ncessaires et
dpendent du
niveau dans
larchitecture

e-store : Couches
AccountController

CartController
Default

SignOut

SignIn

Search

Category

Items

Presentation
Layer
My
Account

Business
Logic
Layer

Data
Access
Layer

Edit
Account

Item
Details

Shopping
Cart

Check
out

Create
Account

Account

Profile

Product

Item

Inventory

IAccount

IProfile

IProduct

IItem

IInventory

Cart

Help

Order
Billing

OrderInsert

Error

Order
Shipping

OrderRead

IOrder

Order
Process

e-store : Domaines
Default
SignOut

SignIn

Search

Category

Items

Presentation
Layer
My
Account

Business
Logic
Layer

Data
Access
Layer

Edit
Account

Account

Item
Details

Check
out

Create
Account

Profile

Shopping
Cart

Product

Item

Inventory

Cart

Help

Order
Billing

OrderInsert

Error

Order
Shipping

Order
Process

OrderRead

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

Customer

IProduct

Catalog

IItem

IInventory

Inventory

IOrder

Shopping

Billing

e-store : Domaines

Presentation
Layer

Business
Logic
Layer

Data
Access
Layer

Customer

Catalog

Inventory

Shopping

Billing

e-store : Services

Presentation
Layer

Business
Logic
Layer

Service
Layer

Data
Access
Layer

Manage
Customer

Show
Catalog

Make
Inventory

Shop

Bill

Bnfices mtier
Amliorer lagilit et la flexibilit du mtier
Faciliter la gestion des processus mtier
Offrir la capacit casser les barrires
organisationnelles (silos)
Rduire en temps le cycle de dveloppement
des produits
Amliorer le retour sur investissement
Accrotre les opportunits de revenu

Bnfices techniques
Rduire la complexit de la solution
Construire les services une seule fois et les
utiliser frquemment
Garantir une intgration standardise et le
support de clients htrognes
Faciliter la maintenabilit

Quels sont les lments cl dune

architecture oriente services ?

Points cls de larchitecture

1.a Search for service

Service
consumer

Repository

1.b Return contract

Contract

2.a Create a process instance

Mediation layer/Service bus

2.d Send request

Service
provider

2.b
Execute
process

Business service
orchestrator

2.c Retrieve service

end-point

Business
process description

Registry

Standards de larchitecture
Les standards sont un lment cl dune SOA, ils
assurent linteroprabilit

SOAP

WSDL

UDDI

BPEL

W3C

W3C

Microsoft, IBM, HP

Oasis

Simple Object
Access Protocol

Web Services
Description Language

Universal Description
Discovery and Integration

Business Process
Execution Language

Transporte

Dcrit le contrat

Spec pour
Repository/Registry

Dcrit les
processus mtier

Les trois piliers des Services Web

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 lordre de la technologie :
On peut utiliser les Web Services sans faire de SOA

Les WS constituent la meilleure solution

standardise disponible
Un service mtier = un webservice

Le langage BPEL
Standard de lOASIS
Norme permettant de dcrire des processus en XML
Propose les fonctions basiques dun langage de
programmation:
sequence, flow, loop, switch

Identification des Instances de Process

Gestion des transactions longue dure (scope,
compensation)
Gestion des fautes

BPEL le chef dorchestre

BPEL par lexemple

<PartnerLink> references to the
services participating in the process flow
<invoke> a credit rating service synchronously

<faultHandlers> catch and manage

exceptions when customer
has a bad credit history

PartnerLink

<flow> initiates asynchronous loan processors in parallel of execution

flow

PartnerLink

PartnerLink

<receive> asynchronous callbacks

from longrunning loan processors
<switch> to the lowest loan offer

loan.bpel

Quelques dtails sur le langage BPEL

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

ESB : couche de mdiation

Cest le point dentre vers un service => invocation indirecte
du service au travers du bus
Ce point dentre doit tre normalis mais on ne sait pas qui
fournit le service et comment il le fournit (implmentation).
Infrastructure qui optimise les changes entre
consommateurs et fournisseurs de services. Il peut prendre
en charge :
Routage
transformation des donnes
transactions,
scurit,
qualit de service,

Ex: voir http://petals.ow2.org/what-is-petals-esb.html
Le but dun ESB est de permettre de communiquer de manire
simple et standardise entre des applications htrognes

Quelques manires dimplmenter un ESB

Intergiciels de type MOM (Message Oriented
Middleware)
Intergiciels de type Bus (CORBA par exemple)
Intergiciels de type EAI (Message Broker avec
connecteurs propritaires lis au moteur dintgration)
Routeurs Web services tel que WebSphere Web
Services Gateway
Selon le type dimplmentation retenu, lESB
assurera plus ou moins de services : le choix
dpend des besoins
LESB nest pas obligatoire : mais il est fortement
recommand pour viter le couplage entre
fournisseur et consommateur

Exemples darchitecture techniques se

basant ou pas sur un ESB
Avec ESB

Plusieurs connecteurs
Orchestration importante
Transactions consquentes

Sans ESB

Communications inities par les

applications seront donc homognes
Pas dorchestration, parce que pas
dintermdiaire: invocations de
services directement pilotes par le

Intgration applicative via un bus JBI

Dans cet exemple, hormis le BPEL process, tous les autres lments applicatifs sont des services externes au
bus.

Mais, par ex. un lment pourrait tre un autre BPEL process ou un composant EJB, ou autre, dploy DANS
le bus, et vu comme un service interne.

Specification JBI pour ESB (ouvert)

BC et SE peuvent se rajouter (et senregistrer)

sur le bus dynamiquement

Quel est le cycle de vie dun service ?

Dcoupage du cycle de vie dun service

4 grandes phases :

Identification
Spcification
Dveloppement
Gestion

1 aspect tranversal : la gouvernance

Les architectures orientes service impliquent

une vision globale
La gouvernance permet de casser les silos de
lentreprise

Cycle de vie des services (activits de gouvernance)

yes

Search for
Existing
Implementation

Service
Identified

exists?

no

Service Identification

Service Owner
Approval
Service
reusability
Commission

Service Specification Created

Candidate
Consumers
Identified

Service
Specification
Review

Provider Interfaces Documented

Service/Process Workflow Created

Service Specification
Develop
Components

Integrate
& Test

Create
Deployment Unit

Acceptance
Test

Code in
repository

Service Development

Certify
Service

Service in
registry

Service
in use

Monitor
service

Service Management

Plan
New
Version

Decommis
sion
Service

Deprec
ate
Service

Rles associs au cycle de vie des services

n
o
i
t
ic a

on
i
t
ca
Analyste
mtier
i
f
f
ci
ti

n
e
Sp Dfinit les services pour les use
Id Dfinit les processus mtiers et les
KPI associes
Identification des services mtier
Optimise les processus via la
simulation

nt
e
m

pe
p
elo Assemble les services
v
D

on
i
t
es

cases
Modlise les services

nt
e
em
Intgrateur
p
p
o
l
ve Implmente les services

Gestionnaire

Publie les services

Gre le cycle de vie des services
Contrle la qualit de service

Dvel

Zoom sur la phase didentification

Un des problmes centraux pour mettre en uvre une SOA
La granularit des services est fondamentale
dtermine en grande partie la rutilisabilit des services

Or succs SOA = % de rutilisation des services

viter une granularit trop fine qui entrane :
beaucoup dinteractions
des problmes 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 rutilisable

Trouver le juste milieu

2 mthodes didentification des services

Une premire phase d'indentification doit tre effectue sur
l'ensemble du SI dans le cadre de son urbanisation en s'appuyant sur
la cartographie des domaines mtiers de l'entreprise et sur le code
existant
Approche incrmentale : une phase d'identification est ncessaire au
dmarrage de chaque nouveau projet SOA en s'appuyant sur les
processus et services rpertoris prcdemment
Approche Bottom-up :
On part des briques informatiques, on rassemble les bouts (abstraction)
Ralise gnralement par la MOE
Plus adquat pour rutiliser lexistant non SOA-is

Approche Top-down :
On part des interactions mtier pour aboutir aux interactions techniques
Ralise gnralement par la MOA
Plus adquat pour dmarrer un nouveau projet

Approche Outside in
Dans la pratique on utilise rarement une seule approche
Pour obtenir une granularit pertinente des services, il est
ncessaire de concilier les 2
Faire lanalyse Top-down sans se proccuper de lexistant
Faire lanalyse Buttom-up en ne considrant que lexistant
Comparer les services remonts avec ceux dduits des processus
Faire les compromis ncessaires pour rutiliser le maximum de
code

Zoom sur la phase de spcification

Les services identifis ne doivent pas tre
tous publis :
Chaque service a un cot et un risque
Il faut viter la prolifration des services

Le Service Litmus Test

d'IBM aide
trouver les bons
services exposer

Quelques critres d' exposabilit

Le potentiel d'un service est d'autant plus
important qu'il :

permet d'automatiser un processus mtier critique

est rutilisable par plusieurs domaines mtiers
remplace une application dsuette
supporte des besoins non fonctionnels (scurit,
logging, monitoring, ...)

Les services non exposs

Location de vhicules : services exposs

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

Quelles mthodes et outils permettent de

mettre en oeuvre une architecture oriente
services ?

Mthodes de conception des services

SOMA (IBM)
SODA (De Gamma)
Praxeme (Unilog Management et Orchestra
Networks)
+ toutes les formations proposes par les
diteurs tels que Softeam (SEA),
DreamSoft, etc sur leur savoir-faire
Autant doffres que de mthodes
diffrentes : de quoi sy perdre !

Modeleurs de processus
Outils de modlisation des processus mtier

IBM WebSphere Business Modeler

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

Moteurs dexcution de processus

Plate-forme dintgration
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)

Contrleurs/moniteurs
BAM (Business Activity Monitoring)

IBM WebSphere Business Monitor

Oracle BAM
Systar Business Bridge
BMC Service Impact Manager

Composants de scurit
Oracle Web Service Manager
Oblix

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

Business Analyst

Service Architect

WebSphere Business
Modeler

Service Specification

BPEL

Rational Software
Architect

WSDL
Developer

KPIs

Integration
Developer

WebSphere
Integration Developer

Rational Application
Developer

Service Development
WebSphere Service
Repository & Registry

Service Registrar

Business Analyst

WebSphere Business
Monitor

Server Administrator

WebSphere Process Server

WebSphere ESB
Service execution & Management

Governance
Manager

Performance
Manager

WebSphere
Business Services
Fabric

Conclusions

Du dj vu ?
SOA est une volution des plate-forme passes, tout en
prservant les caractristiques russies des architectures
traditionnelles
Contractualisation des services
Design by Contract (Meyer)

Dcouplage Interface/Implmentation,
interoprabilit, transparence des communications,
Middlewares la CORBA

Dcouplage fournisseur/comsommateur
Message Oriented Middleware (MOM)

Orchestration des services

Travaux autour des workflows, langages de coordination

SOA est une volution plutt quune rvolution

Assembleur
Langages machine

Chronique dune volution

objets
Langages
procduraux

**

composants

01011
10100
11000
01011

Niveaux dabstraction grandissant

services

services

Synthse
Depuis
Orient fonctionnalits
Conu pour durer

Vers
Orient processus
Conu pour changer

Cycle de dveloppement long

Dveloppement et
dploiement interactif

Silos applicatifs

Orchestration de Services

Couplage fort

Couplage faible

Orient Objet

Orient message

Avantages et inconvnients

Architecture adaptative
Rutilisation du code
Utilisation de standards
Productivit accrue

Manque de maturit des standards

Lenteur dexcution
Difficile effectivement implmenter
Encore peu de chose sur la contractualisation

Quelques rfrences ...

Urbanisation et BPM - Yves Caseau, DSI
Bouygues Tlcom, 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 scnario Rent-a-car

http://www.research.ibm.com/journal/sj/444/cherbakov.h
tml

Quelques rfrences ...

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://www128.ibm.com/developerworks/library/specification/ws-sca/

OpenCCM
http://openccm.objectweb.org/
Sofa
http://dsrg.mff.cuni.cz/projects/sofa/tools/doc/comp
model.html