Services Web

PLAN
Les Systmes dinformations distribus et leur volution
dans le pass
Les diffrentes architectures des SI
Communications inter-application : les diffrents
modles
Les middlewares
EAI
Intgration dapplication pour le Web
Les services Web
Technologies de base des services Web (SOAP, WSDL,
UDDI)
La coordination de services et protocoles
La composition de services
Les services web smantiques

Les Systmes dinformations distribus et leur

volution dans le pass
Conception du SI en couches

(3):
Application
logic
layer
2.
couche de
prsentation
1. La
Presentation
layer

Resource
management
layer
3. Conue
pour
supporter la
communication avec les utilisateurs

humains ou dautres ordianteurs ou IS.

Client
La couche
de logique applicatieve Ces couches sont
lieu de traitement
la fourniture
de rsultats
Cest
Lalecouche
gestionavant
de resources
clairement
identifiable s
Prsentation
dede
linformation
deavec
tous
modules(requtes,
ou programmes
implmenatnt les
Prsentation
Layer
leles
systme
rponses).
Co mpose
Interactions
Contientdemandes
les donnespar
ncessaires
au IS. (BD,
Fichiers, dautres BD
TThhee
erations
lz client travers
la couche
et
op
sentation.
Plusieurs
formes : ou desmme
dIS
diffrents
IS externes).
pre de
reprsentent
Elle fait rfrence

tous
les mchanismes
Pr ogrammess
=
services
offerets
par
leIInnff
ISoorr utiliss pour intrargir
avec les blocs qui composent
un
IS.
mmaati
une
Appel
GUIaussi business process,
business logic, business
s
rules qui met en forme les donnes dans une rprsentation
donne.
un module

Resource
Management
Layer

des sous-systmes
oonn
SSyysstt

Application Logic

Fig I.1. Couches

dun IS complis
Layer

e
e
m
m

avec de

isols

outils
diffrents.

Deux approches pour concevoir les SI

Top down
Commence par la dfinition des fonctionnalits du systmes du
point de vue de ses utilisateurs.
1) Dfiniton de buts de haut niveau
2) Dfinition de la logique applicative (tout ce quil faut pour
atteindre les buts)
3) Dfiniton des ressources ncessaires

Donc lapproche Top down met laccent sur les buts de haut niveau
et sur la manire de les atteindre.
Elle doit aussi dfinir comment le systme sera distribu sur les
diffrents noeuds.
Les IS conus de cette manire sont en gnral destins
tre excuts dans des environnements homognes.
Les composants distributs de cette manire sont dits fortement
coupls ( tightly coupled).

Deux approches pour concevoir les SI

Bottom up
ISs construits par lintgration de systmes existants (legacy
applications)
Une application ancienne est utilise pour des buts et contextes
diffrents de ceux pour lesquels elle a t conue initialement.
Problem : Comment intgrer les fonctionnalits dans un tout
cohrent?
Rsultat: la conception est dirige par les carcatristiques des
couches infrieures.
1) Dfiniton de buts de haut niveau
2) Analyse de la couche de ressources (cot et faisabilit pour
lobtention de fonctionnalits partir des composants
existants)
3) Les composants sont envelopps pour exposer les interfaces
ncessaires
4) Dfinition de la logique applicative (tout ce quil faut
pour atteindre les buts)

Avantages / Inconvnients
Avantages

Inconvnients

Top Down

Met laccent sur les buts finaux

Concerne la fois les besoins
fonctionnel et non fonctionnels

Elle peut tre applique

uniquement des
systmes concus partir
de zro (from scratch)

Bottom Up

Conduit des systmes faiblement

coupls (loosely coupled systems)
Chaque composant peut tre utilis
comme un systme indpendant du
reste du systme.

La question est comment utiliser un ancien systme la fois comme un

composant, et tout en maintenant ses fonctionnalits comme systme
indpendant?
Des tudes ont montr que ceci est possible grce aux services
Web.

Architectures dun IS

Les diffrentes couches dj prsentes reprsentent une vue

conceptuelle du systme qui sparent logiquement les
fonctionnalits du systme.
Mais quand il sagit dimplmenter un systme ces couches sont
combines et distribues de diffrentes manires. Dans ce
cas on les dsigne par des tiers.
4 types dIS sont dfinis dpendemment de comment les tiers
sont organiss :
1)
2)
3)
4)

1-tier,
2-tiers,
3-tiers
N-tiers.

Architecture 1-tier

Cest le rsultat des ordinateurs utiliss dans une priode

trs lointaine avant larrive des PCs
Les Iss sont monolithiques Les 3 couches sont
fusionnes en une seule (the mainframe).
Ces systmes noffrent aucune entre depuis lextrieur :
vus comme des botes noires.
Pour des besoins dintgration la mthode la plus utilise
pour extraire des informations est appele : dreaded
screen scrapping.
Les systmes 1-tier ne sont pas portables et sont
difficiles maintenir (ncessitent des comptences).

Architecture 1-tier
Clie
nt

Presentation
Layer

Application
Logic Layer

Resource Management
Layer

The
Infor
m
atio
n
Syst
e m

Architecture 2-tiers

Lmergence des PCs a pouss lapprition des

architectures 2-tiers.
Dans cette architecture la couche de prsentation a
migr vers le client architectures
Client/Serveur.
Nous pouvons avoir :
Client lger (Thin client)
Client lourd (Fat client).

Cela dpend des fonctionnalits offertes par le client et

la nature du dploiement de lapplication.

Architecture 2-tiers

Presentation
Layer

The
Infor
m
ation
Syst
em
Application Logic
Layer

Resource Management
Layer

La notion dAPI
Intimement lie au modle client/serveur est la notion de
RPC.
Dans RPC, les concepteurs sont forcs en termes dinterfaces
publies
Dveloppement du concept dAPI.
Une API spcifies comment invoquer un service, les rponses
qui peuvent tre attendus et les effets que peut avoir cet
invocation sur ltat du serveur.

OrganisationInterne de la couche de logique applicative

dans un systme 2-tiers
Servers
API

Service

Service

Service

Service

Service

Interfa
ce

Interfa
ce

Interfa
ce

Interfa
ce

Interfa
ce

Servi
ce

Servi
ce

Servi
ce

Resource
Management
Layer

Servi
ce

Servi
ce

 Avec les APIs, il est possible de dvelopper tout type de clients qui les
utilisent
Limplementation
des fonctionalits du serveur peuvent voluer
sans impact sur les clients.
Les programmes individuels respinsables de la logique applicative
deviennent des services sexcutant sur le serveur.
Linterface du service dfinie la manire dinteraction avec un services
donn.
dtail dimplmentation.
Il sagit dune abstraction du
Toutes les interfaces deviennet lAPI du serveur.
a engendr le besoin de
Laccent mis sur les interfaces
standardisation:
Les services Web sont le dernier rsultat de cet effort de
standardisation.

 Les systmes 2-tiers sont portables puisque la couche de

prsentation est indpendante du serveur.
Les systmes 2-tiers ont une scalabilit limit
Ils ne sont pas flexibles surtout lors de lintgration de
diffrents systmes ou serveurs.

Architecture 2-tiers
Clie
nt
Application Logic
Presentation
Layer1

Application
Logic Layer

Resource
Management
Layer

Presentation
Layer2

Application
Logic Layer

Resource
Management
Layer

Une couche de logique application additionnelle est intgre a

niveau du client ; cest le moteur dintgration

Architecture trois-tiers
Concerne lintroduction dun tier additionnel entre le client
et le serveur
Ce tier est alors responsable de lintgration de tous les
systmes et cest lendroit o rside la logique applicative
dintgration.
La couche de prsentation se trouve sur le client.
La couche de gestion de ressources est compose de tous les
serveurs que larchitecture 3-tiers essaye dintgrer.
La logique applicative rside au niveau du tier du milieu

 Labstraction et linfrastructure qui supporte le

dveloppement de la logique applicative sont appels
middleware.
Les managers de ressources doivent fournir des interfaces
claires de telle sorte quelles puissent tre accdes par
la logique applicative au niveau du middleware.
Il existe des efforts de standardisation de ces interfaces
(ODBC, JDBC, etc).
Les architectures 2-tiers ont forc la dfinition des APIs de
la couche de la logique applicative
Les architectures 3-tiers ont forc la cration des APIs de
gestion de ressources.

Architecture trois-tiers

Client
Presentati
on Layer

Applicati
on Logic
Layer

Resource
Management
Layer

Middleware

Intgration de systmes de diffrentes Architectures

dans une architecture trois-tiers
Clie
nt
Presentation
Layer

Middleware

App Logic
Layer

Integration
Logic
Clie
nt

Clie
nt

Wrapp
er

Wrapp
er

RMLayer

Wrapp
er
2tier

1tier

3tier

Rsultats: architecture point point

Architecture N-tiers
Constituent le rsultat de lapplication de larchitecture 3-tiers
dans sa totale gnralit et de limportance de linternet
comme nouveau canal de communication inter-applicatif.
2 aspects gnriques ont t ajouts :
Liaison de diffrents systmes
Ajoute linteractivit via Internet
Inclut les serveurs Web comme partie intgrante de la couche de
prsentation ce qui cre un tier supplmentaire
Dans de tels systmes le client est le navigateur et la couche de
prsentation est distribue entre le navigateur, le serveur et le code
qui prpare le flux HTML.

Clie
nt
Web Browser

Web
server
Middlewa
re
HTML
Filter

Application Logic
Layer

Resource Management
Layer

Middleware

The
Infor
ion
mat
Syst
em

Evolution depuis larchitecture 2-tiers vers N-tiers

Les modles de Communication

Interactions bloquantes et non bloquantes
Synchrones Bloquantes
Asynchrones Non bloquantes

Dans un IS, une interaction est dite synchrone ou bloquante si les

parties concernes doivent attendre que linteraction se termine avant
de faire autre chose.

Communication synchrone

Communication synchrone
Les interactions synchrones sont plus simples implmenter
Raison pour laquelle elle domine pratiquement toutes les architectures
dIS et les middleware.
Inconvnients:
Si linterection nest pas de request-response
Perte de temps Moindre performance
Ce problme sera dautant plus aggrav lors dajout de tiers
supplmentaires
Chaque appel engendre une nouvelle connection
Dangers de dpasser le nombre de connections possible
allous.
La taulrance aux fautes
Toutes les parties concerns doivent fonctionner
correctement

Communication asynchrone

Communication asynchrone
Dans une large gamme dapplication, il nest pas ncessiare de
fonctionner de manire synchrone;
Le processus metteur na pas besoin dattendre jusqu une
une rponse arrive;
Le programme peut donc ralsier dautres tches
Ceci supprime dtablir une quelconque coordiantion entre les
deux parties communicantes.
Les systmes de communications les plus adquats dans ce
cas ( middlewares) sont les messages brokers (MOM) surtout
utilis dans les architectures N-tiers.
Faible couplage

Communication asynchrone
Les communication Asynchrones peuevent tre aussi utilises
pour des interactions en ligne.
En pratique toutes les applications qui peuvent tre
implmentes moyennant un mchanisme RPC peuvent utiliser
des communication asynchrones.
Les communications Asynchrones sont utiles quand le modle
de communication nest pas du type request response.
Exemples de systmes:
Dissmination dInformations (diffusion)
Notifications dvnements
Systme de type Publish/Subscribe

Mode de fonctionnement CA
Les C A ncessitent que les messages soient stoqus dans un
espace intermdiaire jusqu ce quils soient rcuprs pour
traitement par le rcepteur.
Plusieurs systmes de files dattente sont actuellement
utiliss comme des middlewares :
filtrent,
contrlent le flix des messages
Implmentent les stratgies de distribution complexes
Manipulent les formats et les contenus des messages

Donc la logique dchange de messages est implmente par

ces systmes de file dattente au lieu quelle soit implmente
dans les enveloppes (wrappers) ou les composants en
question.

Middlewares

Les middlewares

Les Middlewares facilitatent et grent les interactions entre

les applications sur des plateformes htrognes.
Il sagit de la solution architecturale au problme dintgration
dune collection de serveurs et dapplication sous une
interface commune de services.

Quest ce que les middleware?

Middleware comme une abstraction de programmation
Les Middlewares fournissent des abstractions de programmation qui
cachent la complexit derrire la construction dapplications
distribues.
Exemple:
Avec RPC, nous avons tout juste besoin de reformuler la communication
entre les deux parties de lapplication comme des appels des
procdures.
La figure ci-dessous montre les couche caches par labstraction RPC
et o RPC joue le rle dune interface de programmation.
Les RPC transactionnels sont des middlewares supportant le
traitement des erreurs
(unwanted side effects are removed, persistence of the latest stable
state, etc)

Middleware comme Infrastructure

Il y a une infrastrcuture logicielle trs complexe derrire
labstraction de programmation de RPC par exemple.
Les Middlewares sont des platformes trs complexes.

Object broker
Avec lOO, les plateformes ont t dveloppes pour
supporter linvocation dobjets distants ce qui a donn
naissance aux Objects brokers.
En pratique, la plupart des object brokers utilisent RPC
comme mchanisme sous jacent pour implmenter les appel
distant des objet.
Les plus populaires sont bass sur CORBA (Common Object
Request Brokers Architecture) le standard de lOMG
(Object Management Group).

RPC considre comme une abstraction de programmation

couvrant la complexit des autres niveaux

Remote Procedure
Call

Socke
ts

TCP,
UDP

Internet Protocol
(IP)

Types de Middlewares
Middleware de type RPC
Ils transforment les appels de procdure en des
appels distants de procdure dune manire uniforme
et transparente.
Ils constituent la base de plusieurs middlewares y
compris les middlewares de services Web.
SOAP enveloppe les appels RPC dans les messages
XML changs via http ou dautres protocloes de
transport.

TP monitors

Ils sont vus commes des systmes RPC avec des

capacits transactionnelles

Types de Middlewares
Object monitors
Il sagit dune convergence entre les TP monitors et les
object brokers.
Message Oriented Middleware (MOM)
Ce sont des systmes grant des files dattente de
Messages.

Types de Middlewares
Message brokers
Ce sont un autre type de MOM ayant la capacit de transformer et
filtrer les messages au moment de leurs passage dans la file.
Ils ont la possibilit de choisir dynamiquement les rcepteurs des
messages (sur la base du contrat du message).

Remarques
Les systmes de gestion de Workflow et les serveurs dapplication
sont aussi dautres types de middleware.
Le mcanisme RPC ainsi que son implementation sont devenus une
partie intrinsque aux middlewares , les EAI et les services Web.

Comment fonctionne RPC?

Dcrit simplement, nous supposons un serveur qui
implmente une procdure qui va tre utilise distance
par un seul client.
Step1: Definir linterface de la procdure en utilisant
un IDL.
Step2: Avec lIDL, on peut dvelopper le client et le
serveur.
Step3: Compiler la description de lIDL avec le compilateur
dinterface. Le rsultat est le client Stub et le server
Stub (talon, skeleton).

 Chaque signature de procdure dans lIDL donne naissance

un client Stub. Celui-ci constitue un code compiler et
associer au client.
Quand le client appelle une procdure distante, lappel qui
est rellement excut est un appel local offert par le client
Stub. Celui-ci se charge alors de localiser le serveur(i.e.
tablit une liaison dappel au serveur), de formatter les
donnes de manire approprie (qui ncessite le marshaling
et la srialisation des donnes), communiquer avec le
serveur, obtenir la rponse et lenvoyer comme paramtre de
retour.
le stub joue le rle de proxy pour la procdure
implmente rellement sur le serveur.

NB : Le Marshalling ncessite lempaquetage de

donnes dans un format de message standard ou
commun qui puisse tre comprhensible par le
La
rcepteur.
srialisation consiste en la transformation du message
en une chane doctets avant lenvoi du message via le
canal de communication.
Le Stub du serveur implmente linvocation du ct du
serveur.
Il contient le code recevant linvocation partir du client
Stub, pour formatter les donnes (deserializing and
unmarshalling the call), invoker la procdure et envoyer le
rsultat au client Stub. Il doit tre compil et li au
code du serveur.

Liaison au serveur dans RPC

Pour raliser une invocation de procdure, le client doit
trouver le serveur implmentant la procdure.
Binding est le processus par lequel le client cre une
association locale pour un serveur donn.
Binding peut tre soit statique soit dynamique.
pour
Dans un binding statique, le client stub est hard
pointer
coded sur le serveur (via une adresse IP et un numro de
port ou autre).
Le serveur et le client sont fortement coupls.
Le binding dynamique permet au client dutiliser un service
spcial lui permettant de localiser les serveurs
appropris.
Il sagit du service de nommage et de rpertoire (name
and directory server) responsable de rsoudre les
addresses de serveurs en se basant sur les signatures des
procdures invoquer.

RPC et lhtrogniet
Lhtrognit :
diffrentes platformes sur lesquelles clients et
serveurs sexcutent.
Plusieurs langages de programmation pour dvelopper
le serveur et le client.
La solution est lutilisation dune sorte de
reprsentation intermdiaire que les clients et
serveurs doivent connatre pour faire des traduction
vers et depuis cette reprsentation intermdiaire.
Dcouplage du client et du serveur Un grand atout
de flexibilit.

Clie
nt

Serv
er

Client Process

Procedu
re

Procedure
call

Server
Stub

Client
Stub

Bind, Marshall,
serialize
2.Fin
d
5.Sen
d

3. Query for server

implementing the
procedure

Server Process
Dispatcher
(select stub)

0.Register
Unmarshall, Deserialize
Communication
Module

4. Address of
server

7.Recei
ve

6. Invoke
procedure

Communication
Module

1.Register
server and
procedure

Name and directory service

Dynamic binding allows to register the procedures it

implements (0,1). A client can then ask for the address of the
server implementing a given procedure (2,3), obtain the
address from the binder (4), and make the call to the
procedure (5,6,7), which then proceeds as in the static case.

Object brokers
Une extension dRPC pour la POO
Object brokers sont des middleware qui supportent
linteroprabilit entre les objects.
Diffrence avec RPC : Le client doit invoquer une mthode
dobjet et non une procdure.
Puisque les modles objets incluent des notions comme
lhritage et le polymorphisme, la fonction ralise par le
serveur dpend de la classe dappartenance de lobjet
serveur.
Differents objects peuvent rpondre de manire diffrente
linvocation de la mme mthode.

 Le middleware doit lier les clients des objets spcifiques

sexcutant sur le serveur et doit grer les intractions
entre 2 objets.
Plus tard, les object brokers ont rajout de nouvelles
fonctionnalits comme la transparence de localisation, des
techniques sophistiques de liaison, la gestion du cycle de vie
dun objet et la persistence.
Exemple dOB est labstraction dcrite par CORBA (Common
Object Request Broker Architecture). CORBA est la fois
une spcification et une architecture pour la cration et la
gestion dapplications OO distributes sur le rseau.

Dautres exemples dOB :

DCOM (Distributed Component Object Model),
COM+.
.Net
J2EE
Permettant lintroprabilit entre CORBA et Java
Un systme conforme CORBA est compos de trois pices principales
ORB : provides basic object interoperability function
CORBA services: are accessible through a standardized API and
provide functionality needed by most objects such as persistence,
lifecycle management and security.
CORBA facilities: provide high level services needed by applications
rather than by individual objects.
Examples: Document management, internationalization, support for
mobile agents, services for vertical market (education, health, ).

Vertical
facilities
CORBA facilities

ecommerc
e

Educati
on

Supply
chain

Horizontal
facilities
Distribut
ed
docume
nts

User-defined
objects

Informatio
n
managem
ent

Systems
managem
ent

Task
management

Object Request Broker

CORBA services
namin
g

trad
er

transactio
ns

concurren
cy

even
ts

quer
y

lifecyc
le

securi
ty

properti
es

collecti
on

relationshi
ps

externalizati
on

tim
e

startu
p

licensi
ng

persisten
ce

Fonctionnement de CORBA
Pour quun objet puisse tre accessible travers un ORB,
il doit dclarer son interface en utilisant un lIDL CORBA.
LIDL CORBA supporte plusieurs concepts OO (hritage,
polymorphisme).
Le compilateur dIDL gnre le stub et le skeleton.
Le stub est un objet proxy qui cache la distribution (les
appels de mthodes distantes sont faits comme sil sagit
dappels locaux.
Le code du stub inclue les dclarations de mthodes
offertes par limplmentation de lobjet et est li au code
client pour obtenir lapplication cliente excutable
Le skeleton, dcharge lobjet serveur de toute la
complexit de la distribution.

 Techniquement, pour dvelopper un objet client qui

va interagir avec un serveur donn, le programmeur
doit tout juste connatre linterface IDL du serveur.
Il doit cependant connatre la smantiqe des mthodes
dcrites par linterface (commentaires dans les IDL,
documents descriptifs).

Slection et invocation dynamique de services

Le mcanisme dinteroprabilit dj dcrit ncessite que
les clients soient statiquement lies une interface.
De plus, CORBA permet aux applications clients de
dcouvrir de nouveaux objets, rcuprer leurs
interfaces,et de construire des invocations la vole.
Cette fonctionalit est base sur deux composants :
Le rpertoire dinterfaces (Stoque les spcifications
IDL)
Interface dinvocation dynamique.
Un ORB peut avoir plusieurs rpertoires dinterfaces (au
moins un) et le mme rpertoire peut tre partag entre
plusieurs ORBs.

 Linterface dinvocation dynamique offre des operations

comme par exemple :
get_interface() ;
create_request()

Qui peuvent tre utiliss par les clients pour parcourir le

rpertoire et dynamiquement construire linvocation
de
mthode base sur linterfaceouvellement
dcouverte.
Mais reste le problme de lidentification du service en
fonction du besoin du client.

 Dans CORBA, les rfrences aux objets services sont

obtenus travers les services de nommage et de

ngociation (pages balnches et pages jaunes).
Les services de nommage permettent dobtenir une
rfrence un nom de service.
Le service de ngociation permet aux clients de rechercher
des services en fonction de leurs proprits (what type of
properties, non functional aspects, ).
Avec ce service de ngociation , les clients peuvent
galement demander des objets avec certaines valeurs
(companies selling archeology books).
Le problme avec CORBA pour la recherche de services est
le manque de smantique (le client doit comprendre le
sens des proprits des services) qui en retours ncessite
une ontologie partage entre les clients et les fournisseurs
de services.

LEncapsulation dans CORBA

Deux types dencapsulation :
Indpendance de la Plateforme et du langage : le client na besoin de
connatre que lIDL du serveur. Les dveloppeurs peuvent tout changer
condition que lIDL
reste le mme.

Indpendance de la localisation: Le rle de lORB est de maintenir la

correspondance entre la rfrence dun objet et sa relle
localisation.
La rfrence reste valide jusqu la destruction de lobjet et mme qd
lobjet change de localisation physique ou sexcute au dessus dun
autre ORB.
CORBA offre lintroprabilit entre les objets et travers des
ORBs. Chaque ORB conforme CORBA doit supporter le GIOP
(General Inter-ORB Protocol) au dessus de TCP/IP (Internet
Inter-ORB Protocol) ou dautres protocoles de transport.

Message Oriented Middleware

La plus part de grands efforts dintgration sont faits
au moyen des MOM o les interactions asynchrones sont
offertes.
Interoperabilit base sur les messages
Il sagit dun paradigme dinteraction o les clients et les
services communiquent par lchange de messages.
Actuellement les messages sont exprims en XML.
Les Middleware supportant lintroprabilit base sur
les messages sont appels MOM.
Vis vis du MOM tous les objets sont identiques: ils
envoient et recoivent des messages. La difference entre
clients et fournisseurs de services est juste
conceptuelle.
.

Les files dattente de messages

In a message queuing model, messages sent by MOM
clients are placed into a queue, which is identified by a
name and possibly bound to a specific intended recipient.
Whenever the recipient is ready to process a new
message, it invokes the suitable MOM function
to retrieve the first message in the queue.
Asynchronous treatment of messages
Queuing is more robust to failures with respect to RPC
or Objects Brokers (of course messaging infrastructures
must be reliable and robust).
Queues can also be shared between applications providing
equivalent services so as to distribute the load among
them and improve performance. Priorities to messages
could be also assigned.

Comment lintraction avec le systme de

file dattente
de message peut
tre
faite?

Ces systmes offrent une API qui peut tre invoque pour
toutes les oprations de traitement de messages.
Lenvoi dun message nest pas une opration blocante.
Cependant, la rception dun message est blocante : le
message rcepteur doit couter larrive des messages pour
les traiter. a new thread per message).
Exemple de MOM APIs: JMS.
JMS peut tre implment comme systme indpendant ou
intgr dans un serveur dapplications.
Exemples: JORAM (Java Open Reliable Asynchronous
Messaging), JBOSSMQ.

 Les files dattentes transactionnelles constituent une autre

fonctionalit importante permettant doffrir plus de
robustesse. Elle est appele reliable messaging.
Delivery of messages is guaranteed
Support for coping with failures (atomic unit of execution).

Client
application

Quotation
tool

queued messages
Inbound queue

MOM

MOM Core

Enterprise Application Integration

Introduction
Les Middleware constitutent linfrastructure de base
derrire nimporte quel SI distribu.
Ils peuvent tre utiliss quand les systmes sont
compatibles avec des fonctionnalits comparables.
Limitations des Middleware: ils font des suppositions
propose des systmes quils intgrent.
Quand ces systmes sont trs diffrents, leur intgration
par un middleware conventionnele est simplement
impossible.
Les EAI peuvent alors tre vus comme une tape vers
lavant dans lvolution des Middlewares, en tendant
ses capacits pour tenir compte de lintgration
dapplications.
Ces extensions facilitent une intgration grande chelle.

Le passage vers l integration dapplications

Aujourdhui les serveurs dinformation sont prsents
nimporte o dans lentreprise
A dbut les serveurs constitutent des lots dinformation
io ils peuvent communiquer avec des clients mais ils ne
communiquent pas ensemble.
Avec larrive des architectures 3-tiers et des middlewares
ceux ci se sont focaliss sur deux aspects:
La sparation de la logique applicative de la couche de
gestion de ressources.
Larchitecure rsultante est plus flexible.
Ils ont servis comme un mcanisme dintgration entre les
diffrents serveurs.
Cest le middleware qui joue le rle dinfrastructure
supportant le tier du milieur dans une architecture 3-tiers.

Le passage vers l integration dapplications

De
A
Avantages
Inconvnients
Mainfram Un ensemble Distribution
Les serveurs sont des lots
es
de serveurs Les entreprises dinformation sans communication
sont
plus entre eux.
dcentralises

Limitent

la

Communication

dvelopper de nouveaux services

avec les clients Inefficacit

est possible
Un
ensemble
de
serveurs

Une
multitude
services

possibilit
du

de

fonctionnement

global de lenterprise

Avec lutilisation Les architectures 3-tiers ont

de des middlewares facilit
lintegration
des
Prolifration diffrentes couches de gestion
des services
de resources ainsi lintgration
de

services donnant lieu un

autre service pouvant son

tre

intgr

pour

tour

former

service de plus haut niveau.

un

Rle de lEAI
Pour lintgration de serveurs, il y a eu des efforts de
standardisation des interfaces (exemple : les serveurs de
bases de donnes), mais ce nest pas le cas de services
plus gnriques.
Le problme a lieu quand lintgration de services offers
par diffrentes plataformes (middleware) est ralis.
Il nexitse pas dinfrastructure pour raliser cela.
Les EAIs sont alors apparus pour rpondre ce
besoin.

Les middlewares EAI : message brokers

Les platformes middleware sont des systmes trs complexes.
Les systmes traditionnels bass sur RPC et les MOM
permettent de crer des liaison point point entre les
applications (statiques ey non flexibles vis vis de la smlection
des files dattentes qui grent les changes de messages).
Les Message brokers rsolvent cette limite en agissant comme
un broker entre les entits du systme, en crant alors une
infrastructure de type hub and spoke (logique ou physique)
pour lintegration dapplications.
Les Message brokers offrent:
Une flexibilit dans le routage
Dautres fonctionnalits supportant lintgration dapplications
denterprise comme le filtrage et le traitement des messages lors de
leurs mouvement au niveau du systme
Adaptateurs qui masquent lhtrognit

Les middlewares EAI : message brokers

Send
er

Receiv
er

Message Broker Core

Dans les MOM de base,

cest lmetteur qui spcifie
lidentit du receveur.
Avec les message
brokers, une logique de
routage personalise et
spcifique peut tre
dfinie au niveau du
message borker ou au
niveau de la file dattente.
Cette logique de routage est
gnralement dfinie
moyennant un langage de
rgles.

Le modle publier/souscrire
Les applications communiquent en changeant des messages
characteriss par un type et un ensemble de
paramtres.
Les applications mettrices du message ne spcifient pas les
rcepteurs de ce message.
Par contre, elles publient simplement le message au niveau du
middleware.
Si une application est intresse par la rception de message
dun type donn, elle doit souscrire auprs du middleware qui
enregistre cet intrt.
La souscription peut tre base sur le type du message ou sur
ses paramtres.
Par exemple: la spcification JMS inclut une API du type
publish/subscribe API en plus dune API point point.

EAI utilisant un message broker

Pas de composants fondamentaux:

Adapteurs: Ils font le mapping des formats de
donnes htrognes, des interfaces et
protocoles dans un model et format communs.
Un adaptateur diffrent est ncessaire pour
chaque type dapplication aya besoin dtre
intgre.
Un Message broker: facilite linteraction entre
les adaptateurs et donc videmment entre les
systmes finaux qui doivent tre intgrs.

Architecture dun EAI

Integrating
application

Message
Borker

Applicatio
n1
adapter

Applicatio
n1

DBMS
adapter

DBM
S

Applicatio
n2
adapter

Applicatio
n2

e-mail
adapt
er

email

Applicatio
n3
adapter

Applicatio
n3

Utilisation dune platforme EAI

Si une platforme EAI est en place et tous les adaptateurs
sont dvelopps et dploys alors lintgration
dapplications ne nccessite encore que :
Le dveloppement dune application qui implmente la
logique dintgration. Cette application intragit avec le
message broker (et par consquents avec les systmes
finaux intgrer qui sont accessibles via le message
broker et les adaptateurs) en publiant et recevant des
messages.
La configuration des adaptateurs de telle sorte quils
souscrivent aux messages appropris et ralisent laction
approprie au niveau du systme terminal (back end
system)

Avantages

et
inconvnients des EAI
avec les messages
brokers

Avantages
Cot de dveloppement moindre
Cot dopportunit moindre
Moindre effort de maintenance

Inconvnients
Les licences de logiciels sont
extrmement chres
Chaque adaptateurs ncessit un
cot supplmentaire
Il faut du temps et des
comptences pour dvelopper la
logique applicative (celle
dintgration entre autres)
Dveloppement dadaptateurs
quand ils ne sont pas fournis

Les systmes de gestion de workflows

Les premires implmentations des WfMS avaient pour but
dautomatiser les processus administratifs bass sur des
documents papiers.
Plusieurs implmentations initiales taient bases sur la
messagerie lectronique puis plus tard elles ont t
ramplaces par des applications utilisant des formulaires
Web.
Le plus important aspect des WfMS est quils aident dfinir
la logique mdier ncessaire lintgration de systmes
distribues. Ces types de systmes sont appels des
workflow de production.

LIntgration de plateformes EAI et les WfMS devient

naturelle. Les WfMS permettent la dfintion de la loqique
dintgration dtre dfinie de manire aise au moyen dun
langage graphique au lieu dutiliser un langage de
programmation.
Exemples de WfMS : BEA WebLogic Integration,
Biztalk Orchestration, etc.

Dfinition de Workflows
Un processus mtier est une collection dactivits raliss par
une application ou par une personne dans le but datteindre
un objectif particulier.
Le terme processus constitue une reprsentation formelle de
la description excutable dun processus mtier.
Un systme de gestion de Workflow est une plateforme
logicielle
permetttant
la
dfinition,
le
dveloppement,
lexcution et lanalyse des
processus.

 Un workflow est spcifi par un graphe orient dfinissant

lordre dexcution des nuds du processus.
Les nuds peuvent tre :
Des nuds de travail
Des nuds de routage
Des nuds de dbut et de fin

Un workflow peut possder plusieurs instances qui peuvent

tre excutes de manire concurrente.

Excution de Workflow

Excution de Workflows
Les instances de Workflow sont executes par un moteur de
Workflows.
Le moteur agit en tant que planificateur qui affecte le travail
la ressource approprie (lexcutant).
Pour cela, le moteur de Workflow place le travail dans la file
dattente de la ressource slectionne.

 Un workflow est quivalent un programme

Il possde des variables pour le passage de donnes entre les
nuds
Les diffrences avec un programme cest que les procdures
ont une courte dure de vie alors quun processus peut
prendre beaucoup de temps.
Les activits sont dites gros grains.
De plus les ressources peuvent tre des personnes
Il existe aussi la possibilit de dfinir des rgles permettant
daffecter un travail une ressource (logique daffectation
dite ressource rules).
Le langage de workflow est considr comme le langage de
lEAI.

Des techniques spcifiques de gestion des erreurs

Forward recovery : ltat dexcution du processus est
sauvegard sur une mmoire permanente. Il est repris ltat
o il a t interrompu.
Backward recovery: Dans le cas o il est impossible de
continuer le workflow et il faut alors annuler leffet des
oprations dj excutes. Des activits de compensation sont
alors associes aux activits dont leffet ne peut pas tre
annul (envoi dun e-mail).
Exception handling languages : permettant dinsrer des nuds
de capture et de traitement dvnements quivalent aux bloc
try, catch
Deadlines: le moteur de workflow doit grer les cas o
lapplication invoque ne rpond pas aprs un certain temps et
donc une autre planification est ralise par le moteur ou
une notification est envoye ladministrateur

Intgration
dapplication pour le
Web

Les technologies du Web

Rappel :
Besoin dintgration dapplication pour lautomatisation de
processus mtiers
Lautomatisation des processus mtiers ne concerne pas
uniquement une seule entreprise mais elle peut engager
plusieurs entreprises
Inter-enterprise application intgration Vs Intra-enterprise
application integration
B2C, B2B, B2G

Le web est une technologie qui facilite :

Le partage dinformations
La connexion de clients distants avec des applications
Intgration des applications elles mme via Internet
surtout avec les SW.

Protocoles de lInternet
LInternet est bas sur les 2 protocoles :
TCP: pur convertir les messages en paquets et vice versa
IP: pour traiter laddressage des packages sur le rseau
TCP/IP est la technologie de lInternet parce quils
permettent aux paquets dtre mis sur des rseaux
diffrents

Avant le Web
Telnet, SMTP Diffrentes faon de connecter des
utilisateurs possdant des comptes sur des systmes
diffrents indpendamment du OS et des ordinateurs utiliss
SMTP a t tendu avec MIME (pour des fichiers de donnes
plus riches)
FTP : publier un ensemble de fichiers sur un serveur FTP
Avec FTP, plus besoin davoir un compte pour transfrer des
fichiers
Archie (Systme de fichiers distribu) et Gopher (C/S pour
des fichiers textes)

Avec larrive du Web

Le cur de la technologie est constitu de HTTP, HTML,
Services Web, et navigateurs
HTTP est un protocole gnrique sans tat
Gnrique car il permet laccs dautres protocoles comme
FTP ou SMTP

HTTP
HTTP est conu pour supporter lhypertexte (HTML).

Il se base sur lchange de documents via Internet

Les documents sont identifis par des URIs
Un document est soit dynamique soit statique
Chaque ressource est accessible via une URL (la localisation
de la ressource, le protocole).

Le mcanisme HTTP est bas sur le modle C/S en utilisant

des sockets TCP/IP.
Un client ouvre une connexion un serveur HTTP et lui envoie
une requte (message)

HTTP
Le message = request method, URI, la version du protocole+..
Le serveur retourne une rponse :Message avec une ligne
dtat+ message MIME contenant le document de rponse
Puis ferme la connexion.
A partir de la version HTTP 1.1, le serveur Web doit
maintenir la persistance de la connexion pour tous les
composants de la page.

 La mthode de requte (request method) indique les

oprations raliser sur le serveur :
1. OPTIONS: pour envoyer les informations sur les
options de communication supports par le serveur)
2. GET: rcupre le document spcifi ou rsultant de
lexcution du programme spcifi
3. POST: ajoute linformation de la requte la ressource
spcifie
4. PUT: stoke linformation spcifie dans la requte
lendroit spcifi dans la requte
5. DELETE: supprime
la ressource spcifie
dans la requte

Limites de HTTP
HTTP prsente des limites au niveau de la scurit SSL :
HTTPS
Le client et le serveur sauthentifient ensemble pour tablir
une liaison crypte

Client HTTPS

Serveur HTTPS
SSL
TCP/IP

Les technologies web pour supporter des

clients distants
Au dbut le web tait conu pour relier et changer des
documents
Avec la notion de wrapper au niveau des SI pour exposer la
couche de prsentation au format HTML, il est devenu
possible de penser des clients distants.
Besoins des clients distants : extranets, B2C, ATM
Avec les applets les clients web sont devenus plus
sophistiqus
CGI: une application est invoque via une URL (les
programmes sont placs dans des rpertoires spciaux pour
laccs CGI) Un Thread par programme
Les servlets :pour remplacer les CGI avec de meilleures
performances
JSP, ASP, PHP sont des technologies quivalentes

Les serveurs dapplication

Avec lInternet comme nouveau canal daccs aux SI, les
middlewares sont devenus forcs de supporter laccs Web.
Ce support est fourni sous la forme dun serveur dapplication
A- les middlewares pour les applications Web
Les serveurs dapplication sont quivalents aux middleware
dcrits auparavant
La seule diffrence : le web comme canal daccs aux services
implments au moyen du middleware
Importante application : la couche de prsentation devient
trs importante
Le middleware doit intgrer la gestion des documents
La dlivrance des contenus devient plus efficace

Les serveurs dapplication

B- J2EE est vu comme le noyau dun serveur
dapplication: J2EE ou .net
sont trs
similaires
Un aspect des serveurs dapplications est de fournir de plus
en plus de fonctionnalits.
Les limites ne sont pas claires entre les serveurs
dapplications et les autres middlewares
C- Le support fournis par le serveur dapplication la
couche dapplication : ce niveau le serveur
dapplication ressemble beaucoup aux autres
middlewares sert pour lEAI
Le but est davoir un support commun pour lintgration
Dans J2EE la logique dintgration est concentre sur les 3
spec: EJB, JNDI et JMS

 Les conteneurs dEJB fournissent diffrents services

La liaison (binding) aux EJB est faite via JNDI
D- le support des
serveurs dapplication la couche
de prsentation
Ils grent des documents # des middlewares
conventionnels
Diffrents types de clients peuvent tre supports (Web
browser, handheld devices, Web services clients)
formats diffrents
Les serveurs dapplications permettent denvelopper les
documents dans diffrents formats
Des outils de conversion existent pour passer dun format
lautre

 La personnalisation est un autre aspect qui a t intgr dans

les serveurs dapplication
Exemple ATG Dynamo

Remarque : Les serveurs dapplication peuvent tre vendus

indpendamment des serveurs web..

Les technologies Web pour lintgration dapplications

HTTP permet diffrents IS dintragir via Internet.
plusieurs limites mais cest une base
A- Les architectures pour une large intgration
Lintgration de systmes sur un rseau tendu doit suivre une
certaine stratgie.
Cette stratgie est le choix dune combinaison possible
dintgration :
Au niveau du client
Au niveau du middleware
Au niveau des managers de ressources.

Ceci dpend des protocoles et des standards utiliss

Les technologies Web pour lintgration dapplications

B- Lextension des middlewares
LInternet ncessite dautres couches middlewares entre les
clients et les serveurs ou entre serveurs.
Extension des middlewares existants pour supporter
linternet comme canal daccs additionnel
De plus :
Les entreprises grandissent avec des systmes
diffrents
B2B transactions deviennent ncessaires moins derreurs,
plus rapides, traces gardes pour lanalyse
Techniquement, il sagit dinvoquer des services rsidents sur
des serveurs des autres compagnies

Les technologies Web pour lintgration dapplications

Cette approche a pu tre ralise par CORBA en liant
diffrents ORBs : possible grce au protocole General Inter
ORB protocol : GIOP
IIOP traduit les appels GIOP en TCP/IP

GIOP

IIOP

Les technologies Web pour lintgration dapplications

Problmes :
1 Lexistence des Firewalls qui va empcher la communication
Inter-ORB
2 Il faut tre daccord sur le langage dIDL et les formats de
donnes
3 Il faut un serveur de rpertoire (Directory server) pour
permettre la dcouverte des services.
Question fondamentale : entre deux compagnies, o va rsider
le serveur, par qui va-t-il tre gr?

Les technologies Web pour lintgration dapplications

C- Les firewall et le tunneling travers HTTP
Des problmes de confiance ont forc lusage des firewalls
Pour laisser les firewall avoir confiance au trafic il faut faire
appel aux techniques de tunneling.
La technique du tunneling permet dencapsuler les protocoles
interdits aux firewalls dans des protocoles permis.
Le tunneling travers HTTP suppose la prsence dun serveur
Web chaque bout de la communication.

Les technologies Web pour lintgration dapplications

D- Le problme des formats de donnes et
la standardisation de leur
reprsentation
Lchange de donnes entre des entreprises diffrentes a
donn naissance une syntaxe et smantique communes
pour les donnes changes entre les applications :
Il sagit de EDIFACT (Electronic Data Interchange For
Administration, Commerce and Transport)
Un message EDIFACT possde un format bien particulier
Bien que EDIFACT apporte des solutions aux problmes
dchanges de donnes son inconvnients est quil ne peut pas
couvrir tous les messages possibles changer.!
Emergence de XML qui dfinit une manire standard de
dcrire des documents.

Les services
Web

Introduction
Les services Web constituent une manire dexposer les
fonctionnalits dun systme dinformation et de le rendre
disponible via des technologies Web standards.
Les technologies standard tendent rduire les problmes
dhtrognit et donc reprsentent une solution cl
lintgration

Dfinition 1:Un service Web est vu comme tant une

application accessible pour dautres applications travers le
Web
Dfinition 2: Ce sont des applications mtiers modulaires et
autonomes qui possdent des interfaces ouvertes, orientes
internet et bases sur des standards.

Dfinition 3 : Un service Web est une application logicielle

dfinie par une URI dont les interfaces et les liaisons sont
capables dtre dfinies, dcrites et dcouvertes comme des
artifacts XML. Un service Web supporte des interactions
directes avec dautres agents logiciels en changeant des
messages bass sur XML via des protocoles standard de
lInternet.
Ce sont des composants qui peuvent tre intgrs dans des
applications distribues complexes
Remarque : Le W3C souligne lomportance de XML
comme partie intgrante de la solution base sur les
SW.

3 Aspects important des services Web

La contribution des SW pour rsoudre les problmes des
middlewares conventionnels englobe 3aspects :
1. SO paradigme,
2. Reconception des protocoles des middlewares et
3. la standardisation

3 Aspects important des services Web

1.

Le paradigme dorientation services :

Un service est une procdure, mthode, objet

ayant une interface stable et pouvant tre
invoque par des clients.
Un client dun service est un programme.
Linvocation se fait via Internet entre diffrentes
entreprises.
Les concepteurs et dveloppeurs de services
pensent ce que tout soit considr comme tant
un service.
Les diffrents services sont indpendants et
autonomes.

3 Aspects important des services Web

2.

La reconception des protocoles des middlewares:

Les protocoles de middleware ont t reconus de

telle sorte quils puissent travailler en mode
peer- to-peer plus de coordinateurs centralis
nest ncessaire
Les protocoles doivent fonctionner de manire
dcentralise sur diffrents domaines de
confiance.

La re-conception des protocoles des middlewares

en mode

SW

peer-to-peer

SW

Entry Point

Chaque partie expose ses oprations

cture comme un services Web qui
Infrastru internes
Interne agit comme un point dentre au
Infrastructure
reste du systme dinformation
Interne
Au niveau interne les langages
et
protocoles sont standardiss liminant
le besoinSW
diffrents middlewares : le
seul middleware cest celui des
services
Web.
Infrastructure
Interne

3 Aspects important des services Web

3.

La standardisation :

Tout dabord cest une ncessit

Des efforts de standardisation ont t adopts
par des organismes telles que OASIS
(Organization for the Advancement of the
Structured Standards) et W3C.
Les aspects de standardisation touchent :
Les IDLs
Les formats de donnes changes
Les protocoles dinteraction

EAI et les services

Web
Integrating application

Message Borker
Web services
Broker

Applicatio
n1
adapter

Applicatio
n1

DBMS
adapt
er

DBM
S

Applicatio
n2
adapter

Applicatio
n2

e-mail
adapt
er

email

Applicatio
n3
adapter

Applicatio
n3

EAI et les services Web

Plus besoin dadaptateurs, les Services Web sont

considrs comme des adaptateurs standards car
ils offrent une interface standard

B2B et les services Web

SW

SW

SW
Middleware

Service

Service

Interne

Interne

Entreprise A

Client

Middleware

E
R
N
E
T

Service

Service

Interne

Interne

Entreprise B

Les technologies des services Web

1.Description

du service

2. Dcouverte

du service

3.Invocation
Interactions
service

du service ou
avec le

4. La combinaison
services

de

Les technologies des services Web

Description du service
Implique la rponse ces deux questions :
Quest ce quun service?
Comment peut-il tre dcrit?
Dans les solutions middlewares dj vus un service
est dcrit par une interface et par un IDL
LIDL est ncessaire pour gnrer automatiquement
les talons (souches) du client et du serveur et de
faire la liaison automatique au service.

Description du service
La smantique des diffrentes oprations ainsi
que lordre de leur invocation doit tre
connu par le dveloppeur du client
Ceci nest plus valable pour les services Web
les descriptions des services doivent tre
beaucoup plus riches et plus dtailles.

Stack de description et de dcouverte de services

Standards Verticaux
PouSr dmesantiques et

Interfaces

Rpertoires

proprits
spcifiquesdomaines
:
Protocoles mtiers
RosettaNet

Cost, QoS
(descrip
UDDI
WSCL
ou BPEL
ou
autres

Common base
language IDL and
WSDL

XML

Dcouverte de services
Une fois les services sont correctement dcrits,
ces descriptions doivent tre publies pour le
besoin de ses utilisateurs (rpertoires de
services)
Ces rpertoires de services permettent la
publication de nouveaux services, la
dcouverte (au design-time ou au runtime).
Ces rpertoires de services peuvent tre
hbergs par une tierce partie ou encore
chaque entreprise va avoir son propre
rpertoire (mode peer-to-peer).

Dcouverte de services
Ces rpertoires doivent offrir des APIs pour
permettre aux clients dinteragir avec eux
UDDI offre une API standard
Agrgation
de pointeurs
vers des
services

Interactions de services
Linteraction de services est concerne par la
liaison au service : un ensemble dabstractions
(standards) et doutils sont devenus
disponibles pour cela.
Ces protocoles sont implments par le middleware de
services Web: Ils sont transparents leurs
utilisateurs

Web Services Standard Stack

Web Services
composition:
WSFL,BPEL4WS
WS-CDL
WS-CAF

Web Services
Security:
XML-Encryption
XMLSignature WSSecurity

WS-SecureConversation

WSSecurityPolicy
WS-Trust

Web Services
Transaction:
WS-Coordination
WS-Transaction

Publishing and

WS-AtomicTransaction discovery:
UDDI,
WS-BusinessActivity

Web Services
Management:
WSDM, WSManageability
SPML, WS-Provisioning

WSIL
, WSDiscov
ery

Services Description Layer: WSDL, WSCL, WSCI,WS-MetadataExchange, WS- ol

P
XML messaging layer: SOAP , WS-Addressing, WS-Notification, WSEventing, WS-Enumeration, WS-MessageDelivery, WS-Reliability,WS Reliable
Messaging, WS-Resources WS-Transfer
Transport layer: HTTP, SMTP, FTP, etc.
132

Composition de services
Un service peut tre implment par linvocation
de plusieurs autres services appartenant mme
des compagnies diffrentes SW
composite
Les technologies de composition de SW mergent
Elles sont quivalentes celles des workflows
BPEL par exemple est un langage de composition de
services Web

Architecture des services Web (WSA)

Cette architecture permet de montrer comment
les lments prcdents sont combins dans
une architecture globale
Deux facettes :
1. Architecture interne
2. Architecture externe

WSA interne
Les services Web sont une manire dexposer
des oprations internes de telle sorte quelles
puissent tre invoques travers le Web.
Le systme reoit des requtes depuis le
Web et les passe au SI sous-jacent.
Cette infrastructure est offerte par un
middleware interne de SW larchitecture
est celle du middleware utilis.

WSA externe
Linfrastructure middleware pour intgrer
diffrents SW Middleware externe pour les
SW.
Cette architecture externe met en uvre trois
composants:
1. Brokers centraliss ( au middlewares
conventionnels)
2.Infrastructure de protocoles (pour grer les
interactions peer-to-peer)
3.Infrastructure de composition de services
(outils de dfinition et dexcution de services)

Architecture Interne et architecture externe

ws

Entreprise B
(Client)
WS interface

Client

Service
Web

Archi
Externe

Service
Web

Accs au Syst
interne
Archi
Interne

Service
Web

Middleware
Service

Service

Interne
Interne
Entreprise A (provider)

Service
Web

Service
Web

Entreprise B
(provider)

Entreprise C
(provider)

Architecture externe des services Web

WS Client

WS
Invoquer

Middleware
de SW
interne
Rechercher

Publier

Dautres Tiers,.

Middleware
de SW
interne
Dautres Tiers,.

Entreprise A (requester)

Services
descriptions

Entreprise B (provider)

Entreprise C
(provider)

Web service Middleware

Pratiquement le seul et plus important
composant des middlewares des services Web
est le service directory
En ignorant les protocoles et les mcanismes
sous-jacents ce modle sapplique dans
nimporte quelle architecture de middleware
mme celle base sur RPC.
De manire plus spcifique cest le name and
directory server.

Extension de lArchitecture externe des

services Web
WS
Client
Middle
ware
de SW
interne

WS
Gestion de
transactions
Dautres
protocoles
dinfrastruct
ure
Moteur de
composition

Dautres
Tiers,
.
Entreprise A
(requester)

Gestion de
transactions
Dautres
protocoles
dinfrastruct
ure
Moteur de
composition

Services
descriptions
Entreprise B (provider)

Middlew
are de
SW
interne
Dautres
Tiers,
.
Entreprise
C (provider)

Technologie de base
des services
Web

Les composants WSA

1.
2.
3.

Service requester (client)

Service provider
Service registry ou directory

Linfrastructure de base des services Web

ncessite :
4. Un moyen pour communiquer (SOAP)
5. Un moyen de dcrire les services
(WSDL)
6. Un name and directory server (UDDI)
SOAP, WSDL et UDDI
noyau des SW

constituent

le

Question :
Quels problmes rsoudre
pour invoquer un service via
Internet?
1. Une syntaxe commune est ncessaire pour
toutes les spcifications (XML)
2.Un mcanisme permettant des sites
distants dinteragir entre eux (messaging ou
RPC).
3.Un ensemble de liaisons (bindings) pour faire
correspondre les messages avec un
protocole de transport (TCP/IP ou HTTP (for
tunneling) ou SMTP (pour les messages
asynchrones).
SOAP, WSDL et UDDI constituent le
noyau des SW

Question :
Quels problmes rsoudre
pour invoquer un service via
Internet?
Pour tre gnral, le mcanisme de
communication doit fonctionner avec un large
ventail de protocoles de transport.
Avec
WSDL
lr
c
De lus linteraction doitoncepteur
veiller
spcifie linterfa ce
du au faible
p uplageWeb
Elles
entre
(lesapplications
mthoservice
des doivent se
bacser sur
messagessupports
comme unit principal e
parles
le SW)
o communication.
de

Les interactions dans les services Web

Le fichier WSDL est compil dans le langage
appropri pour gnrer les stubs et les
couches intermdiaire pour linvocation du
service dune manire transparente.
Linfrastructure des services utilise WSDL et
SOAP pour crer les objets proxy chez le
requester et le provider.
Lappel au service devient quivalent un appel
local de mthode.

Les interactions dans les services Web

Finalement lUDDI (Universal Description,
Discovery and Integration) va constituer le
service de naming et de repertoring des
services Web.
UDDI est standardis
Il offre :

Un UDDI registry

Une UDDI API

Notions de base des protocoles des SW

SOAP : Simple Object Access Protocol.
Plusieurs versions :
SOAP 1.0 : bas entirement sur HTTP
SOAP 1.1 et+ : Plus gnrique vis--vis des
protocoles de transport.
Buts de SOAP:
Organiser linformation avec XML de
manire structure de telle sorte quelle
puisse tre change entre peers.

Notions de base des protocoles des SW

De manire plus spcifique SOAP spcifie les
lments suivants :
1.
2.
3.
4.

Un format de message XML pour une

communication uni-directionnelle
Un ensemble de conventions pour utiliser les
messages SOAP pour implmenter une
interaction de type RPC
Un ensemble de rgles quune entit traitant
SOAP doit suivre
Une description de comment un message SOAP
peut tre transport via HTTP ou SMTP.

Notions de base des protocoles des SW

SOAP est un protocole de communication :
1.
2.

Uni-directionnel
Sans tat

SOAP a t cr pour supporter un faible

couplage Si la requte est de type
requte-rponse elle devrait tre gre par
les systmes communicants.
Un message SOAP pour la requte (HTTP
request)
Un message SOAP pour la rponse (HTTP
response)

SOAP 1.2 par exemple :

BPEL

Interface W S D L
Messag SOAP
1.2
e
Typ
XML
e
Schema
Dat
XM
a
L
Web Service
Standards

IBM
WebSphere
Microsoft
.Net
Sun
J2EE

Behavior

Implementation
Platforms

150

Structure dun message SOAP

Applicationspecific
message
vocabulary

SOAP Envelop
vocabulary

Structure dun message SOAP

SOAP suppose que chaque message possde :
1.
2.
3.

Un metteur
Un rcepteur
Des nuds intermdiaires (pour le routage du
message au rcepteur)

Un message SOAP est construit selon 2

manires:
4.
5.

Le style dinteraction (RPC,

Document)
Les rgles dencodage (comment une entit ou
une structure de donne est reprsent en
XML les applications se mettent daccord sur
le XML schema

Document style Interaction

SOAP Envelope
SOAP Body

Bon
de
commande
-Produit
Quantit

SOAP Envelope
SOAP Body

Accus
de
rception
-

Id

BC

RPC style Interaction

SOAP Envelope
SOAP Body
Nom de mthode :
Commander_produits
Paramtre1 :
produit_id
Paramtre 2 :
Quantit

SOAP Envelope
SOAP Body

Retour
mthode

de

Return value : BC
Id

Traitement dun message SOAP

Les headers des messages SOAP peuvent inclure
des blocks.
Chaque block peut dfinir le rle pour lequel il
est affect (none, next, ultimatereceiver)
Le traitement des blocks par les nuds
intermdiaires peut impliquer un changement
du header (lajout de blocks, la modification,
etc)

Liaison (binding) dun message SOAP

un protcole de transport
Le terme binding # binding un service:
Il signifie comment un message SOAP est
envelopp dans un protocole de transport.
Le message sera alors trait par les primitives
du protocole de transport.
Pour HTTP : SOAP est en envoy via HTTP
request.
Selon lopration avec le serveur SOAP peut
utiliser GET, POST ou dautres primitives
HTTP.
Par exemple POST pour une interaction RPC

RPC style Interaction over HTTP

HTTP POST
SOAP Envelope
SOAP Body
Nom de mthode :
C ommander_produits
aramtre1 :
P
roduit_id
p
P
aramtre
2 :
Quantit

LURL du receiver est

dan

Hs

SOAP Envelope

H T TP re q

T T P P OuesSt
SOAP Body

T
Retour de

mthode

Return value : BC
Id

Notions de base des protocoles des SW

WSDL : Web Service Description Language
Buts : aux IDLs.
La diffrence avec les IDLs conventionnels est que
WSDL ormis le fait quil spcifie les oprations
offerte par le service, il dfinit aussi le mcanisme
daccs au service.
Dans le contexte des SW, chaque service peut
tre rendu disponible en utilisant diffrents
protocoles (# des IDLs classiques)

Notions de base des protocoles des SW

SOAP supporte des liaisons avec diffrents
protocoles.
La deuxime diffrence cest que la description
doit prciser la localisation du service.
La sparation de linterface des bindings aux
protocoles permet que diffrents services
localiss sur des serveurs diffrents peuvent
implmenter la mme interface.

Notionsde base des protocoles des SW

Les interactions sont le plus souvent
asynchrones.
Les IDLs conventionnels sont en gnral utiliss
pour dcrire un seul point dentre au service
(une seule interaction RPC)# les services
Web ncessitent plusieurs interactions
WSDL supporte la dfinition de plusieurs
paradigmes dinteraction avec la possibilit de
combiner plusieurs oprations dans une mme
interface

Structure dun document WSDL

WSDL
Partie abstraite

Types
Messages
Operations
Ports
types
Partie concrte

Bindings

Services&
ports

LesLtLes
qeyuoprations
spivemasle sont
lDtypes
lceLeh: coned
oCnode
n4
satni
I
dsnestaegeasux
c( donoafppoprlmiacteai
lnaaaye)s,crlsoheigaqni
sccheowgm
s
snrs
srequestXTsp
M
roue
o(ybnLpassses,)
toinresponse,
nuqtsolicitgeureseersel

notification
Pour dfinir
les
protocoles et
dautres
infos

Description des oprations

Opration

Rle

one-way (asynch)

Un seul message
(invocation de service par
lenvoi de message)
Deux messages (le service
est invoqu, et la rponse
est envoye)
Deux messages (le service
sollicite une rponse)
Un seul message (le
service envoie un
message)

request-response (synch)
solicit-response (synch)
Notification (asynch)

Etapes de la dfinition de la partie abstraite

WSDL
Etape 1:
Dfinir toutes les structures de donnes qui vont
tre changes dans les messages entre les
applications
Etape 2:
Dfinir tous les messages. Chaque message est
un document typ divis en 2 parties contenant
chacune un nom et un type.

Etapes de la dfinition de la partie abstraite

WSDL
Etape 3:
Dfinir les oprations
Etape 4: finale
Grouper toutes les oprations dans des port
types
NB: WSDL 1.2 : il est possible dtendre un port
type partir dautres port types
(hritage+extension)

Pourquoi cest abstrait ?

La raison pour la quelle ces dfinitions sont
considres abstraites est quil ny a ni un
binding concret, ni un encodage ni encore un
service qui implmente lensemble des port
types.
Le mme port type peut tre implment en
utilisant diffrents bindings et peut tre
combins de manire diffrente avec dautres
implmentation de port types pour former
diffrents services.

Pourquoi cest abstrait ?

La dfinition des messages est aussi considre
abstraite puisque les informations
concernant leurs encoding et protocol binding
sont absentes.
Le mme type de donnes peut tre encod
dans un message en utilisant diffrentes
rgles et le mme message peut tre chang
via diffrents protocoles bindings .

La partie concrte
La dfinition de la partie concrte est faite en
utilisant les trois composants suivants :
1 InterfaceBindings : spcifie lencoding et le
protocole pour toutes les oprations et mes
messages dun port type donn.
2 Ports : nomms aussi EndPoints, combinent
linformation dInterfaceBindings avec une
adresse rseau (URI) dans laquelle
limplmentation du port type peut tre
accde.

La partie concrte
3- Les services : ce sont un groupement
logique de ports.

Web Service Definition Language (WSDL)

WSDL offre un cadre pour dfinir
Interface: oprations avec
input/output
Spcification dAccs: SOAP bindings (e.g., RPC)
Endpoint: la localisation du service

Supports
Port
Type
Formats & Protocols
Binding

Operatio
n
Input & Output

How to encode Message

Implements
Por
t

Provides

Servic
e

WSDL description
<?xml version="1.0"?> <!-- root element wsdl:definitions
defines set of related services --> <definitions
name="StockQuote" targetNamespace="
http://example.com/stockquote.wsdl" xmlns:tns="
http://example.com/stockquote.wsdl" xmlns:xsd1="
http://example.com/stockquote.xsd" xmlns:soap="
http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="
http://schemas.xmlsoap.org/wsdl/"> <!-- wsdl:types
encapsulates schema definitions of communication types;
here using xsd --> <wsdl:types>
WSDL description.docx

<!-- all type declarations are in a chunk of xsd --> <xsd:schema

targetNamespace="http://example.com/stockquote.xsd"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"> <!-xsd definition: TradePriceRequest [... tickerSymbol string ...]
--> <xsd:element name="TradePriceRequest">
<xsd:complexType> <xsd:all> <xsd:element
name="tickerSymbol" type="string"/> </xsd:all>
</xsd:complexType> </xsd:element>

<!-- xsd definition: TradePrice [... price float ...] -->

<xsd:element name="TradePrice"> xsd:<complexType> <xsd:all>
<xsd:element name="price" type="float"/> </xsd:all>
</xsd:complexType> </xsd:element> </xsd:schema>
</wsdl:types>

<!-- request GetLastTradePriceInput is of type

TradePriceRequest --> <wsdl:message
name="GetLastTradePriceInput"> <wsdl:part name="body"
element="xsd1:TradePriceRequest"/> </wsdl:message> <!-request GetLastTradePriceOutput is of type TradePrice -->
<wsdl:message name="GetLastTradePriceOutput"> <wsdl:part
name="body" element="xsd1:TradePrice"/> </wsdl:message>
<!-- wsdl:portType describes messages in an operation -->
<wsdl:portType name="StockQuotePortType"> <!-- the value of
wsdl:operation eludes me --> <wsdl:operation
name="GetLastTradePrice"> <wsdl:input
message="tns:GetLastTradePriceInput"/> <wsdl:output
message="tns:GetLastTradePriceOutput"/> </wsdl:operation>
</wsdl:portType>

<!-- wsdl:binding states a serialization protocol for this service

--> <wsdl:binding name="StockQuoteSoapBinding"
type="tns:StockQuotePortType"> <!-- leverage off
soap:binding document style @@@(no wsdl:foo pointing at
the soap binding) --> <soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/> <!-semi-opaque container of network transport details classed
by soap:binding above @@@ --> <wsdl:operation
name="GetLastTradePrice"> <!-- again bind to SOAP? @@@ -> <soap:operation soapAction="
http://example.com/GetLastTradePrice"/> <!-- furthur
specify that the messages in the wsdl:operation "" use
SOAP? @@@ --> <wsdl:input> <soap:body use="literal"/>
</wsdl:input> <wsdl:output> <soap:body use="literal"/>
</wsdl:output> </wsdl:operation> </wsdl:binding>

<!-- wsdl:service names a new service "StockQuoteService"

-->
<wsdl:service name="StockQuoteService">
<wsdl:documentation>My first service</documentation>
<!-- connect it to the binding "StockQuoteBinding" above
-->
<wsdl:port name="StockQuotePort"
binding="tns:StockQuoteBinding"> <!-- give the binding
an network address --> <soap:address location="
http://example.com/stockquote"/> </wsdl:port>
</wsdl:service> </wsdl:definitions>

Lutilisation de WSDL
WSDL sont
gnrs
partir des APIs

Notions de base des protocoles des SW

UDDI : Universal Description Discovery and Integratio
Buts : Un cadre pour dcrire et dcouvrir les services
Web.
Cest un Business registery : Naming and Directory
Service
UDDI a son tours des APIs spcifies en WSDL ave
des bindings SOAP UDDI est accessible comme un
SW.

Notions de base des protocoles des SW

UDDI concerne aussi la notion de UBR (universal
business registery) accessible tout le monde
supporte aussi les implmentation de rpertoires
privs et linteraction entre publics et privs

Les informations dans UDDI

La catgorisation des informations est faite selon
lusage:
Pages blanches : les informations des
providers ainsi que les listes des services
offerts. Les clients peuvent faire une
recherche par mtier.
Pages jaunes : classification des providers et
de leurs services selon une taxonomie donne.
Pages vertes: Cette information dcrit comment
un service Web donn peut-il tre invoqu. Il
sagit de pointeurs vers des documents de
description de services.

Les structures de donnes de UDDI

Les descriptions des services Web contiennent 4
types dinformations:
BusinessEntity: dcrit lorganisation qui fournit les
services Web (contact information).
BusinessService: dcrit un groupe de services Web
dpendants et offerts par une BusinessEntity.

Les

structures de donnes de UDDI

BindingTemplate: dcrit des informations

techniques ncessaires pour utiliser un SW
(adress, des rfrences des documents
(tModels), les paramtres et leurs valeurs, etc)
tModel :technical model reprsentant un
conteneur gnrique pour diffrentes
spcifications comme WSDL, une classification,
un protocole, la smantique dune opration

Les structures de donnes de UDDI

xmlversionwsdl_tmodel.docx

UDDI API

UDDI use case

UDDI API
3types dutilisateurs APIs spcifique chacun
1. Providers (Publishers API : save_business,
delete_business)
2. Requesters (Inquiry API :find_business,
find_...)
3. Dautres registries qui changent des
informations
Dautres API servent pour :
. La scurit (authentification)
. Transfert ou garde de la proprit des informations
dun provider un autre
. Abonnement aux nouvelles de lUDDI (pour voir ce qui
a t rajout, ce qui a t dtruit, )
. Replication dinformations dun UDDI

Fonctionnement global des services Web

scnario : Comment des services existants peuvent-ils tre exposs
comme des services Web?

1er

tModel

Service
implment

Gnrateur
WSDL

Service
Stub

Description
de service
WSDL

SOAP
Router

WSDL
compiler

HTTP
Engine

UDDI
publisher

2
Inquiry API

Publisher
API

UDDI Registery

Fonctionnement global des services Web

2me scnario :Une spcification WSDL est dj dfinie par un certain
consortium de standardisation et un provider veut implmenter un service
conforme cette spcification

Le processus est quivalent au prcdent sauf que

le WSDL est rcupr partir de lUDDI.
Ensuite le WSDL compiler va gnrer le code
ncessaire du ct serveur.
Il sagit dun template qui devrait tre complt
par le code dimplmentation.

Rest(Representational State Transfer)

Le REST repose sur dPeruoxtporcn

i ocilpees fondamentaux :

sans tat

U
tnTP
ouet (get,
est put,
accessible
travers l'interface
H
T
post,
pho
li s o ph

dchange

delete,etc.)
uni
qdressources
u'olfefre le
tfoirm
oeM
utee
so
les
sRoEntSd
i Ten
fiteset accessibles via un

Nouvelle
URSI (tUylneiform Ressource Identifier)
Nimpodrtae rqcuheillteeapplication web, q u e l q u e s o ti e
t e c h n o l o g ei l
ilangage,
mplmecntpeut
teurruen service
REST.

Avantage et inconvnient
Avantages

Limites

Moins de consommation de la
mmoire

Ncessit de conservation locale de

toutes les donnes ncessaire une
requte

Mise en place du serveur cache

grce aux URI

Pas de notion d'accus de rception,

de garantie de rception du message

Simple entretenir, liens mieux

Consommation lev de la bande

structurs
simplicit et ergonomie

passante rseau
Pas de gestion des transactions
distribues

Comparaison avec SOAP

Avantage REST

Avantage SOAP

Lger - pas beaucoup de

balisage XML supplmentaires

Facile utiliser

Rsultat lisible par lhumain

Rigides - la vrification de type,

adhre un contrat

Facile construire - sans outils

ncessaires

Ncessite les outils de

dveloppement

Comparaison avec SOAP

Flexibilit et simplicit de
lAPI

La bande passante

SOAP
exige des connaissances
spcifiques
besoin de plein doutils
SOAP pour former les
demandes et d'analyser
les rsultats.

REST
crit des services Web en
utilisant une interface qui
est dj bien connus et
largement utiliss: l'URI
Facile comprendre la
cration et la modification
des URIs

Enveloppe XML chaque

demande et rponse

Demande et rponse
court
Plus lger lutilisation de
la bande passante

Scurit

Utilise les WS-*

Utilise HTTPS
Peut assurer la l
authentification,
lintgrit, la confidentialit
(chiffrement HTTPS),et la
signature(certificats)

Synthse(SOAP/REST)
Beaucoup de dbats ont lieu sur le choix d'une architecture REST
ou SOAP.
La conclusion, c'est qu'il faut les deux, a dpend de ce qu'on a
besoin.
Si le consommateur de service est une application Web alors il faut
choisir dans un premier temps une architecture type REST.
Si le consommateur fait de l'EDI (Echange de donnes informatiss)
alors il faut choisir SOAP car il y a des mcanismes de scurit, de
transaction et d'accuss de rception de base.