Architectures

Orientées Service

teaching.bhiri@gmail.com

Sami BHIRI
 AOS - Plan

• Acknowledgement and credits

• Systèmes d’Information Distribués
– Interactions dans un SID
– Les problèmes basiques à résoudre lors d’intégration d’applications
– Techniques pré-WS / intergiciels pré-WS
– Limites des techniques pré-WS

• Les Architectures Orientées Services

– Vision, technologie et architecture
– Services Web : SOAP, WSDL, UDDI
– Les services REST

• Composition de services Web : BPEL

Page 1 26/09/2020 Sami BHIRI

 Web Services Concepts, Architectures and
Applications

• Material: Web Services Concepts, Architectures and Applications

• Authors: Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju
• Publisher: Springer Verlag 2004, ISBN 3-540-44008-9

Page 2 26/09/2020 Sami BHIRI

 IKS Education Material

• Material: Web services and Service Oriented Architectures

• Location: http://www.iks.inf.ethz.ch/education/ss08/ws_soa
• Author: Gustavo Alonso: ©Gustavo Alonso, D-INFK. ETH Zürich.

• Material: Enterprise Application Integration (Middleware)

• Location: http://www.iks.inf.ethz.ch/education/ws06/EAI
• Author: Gustavo Alonso and Cesare Pautasso: ©IKS, ETH Zürich.

Page 3 26/09/2020 Sami BHIRI

4 informations !
• Codage des paramètres
• Protocole applicatif
• Localisation
 Architecture C/S
 Développement d’applications C/S
 Modes d’intégration d’applications
 La notion de services
 Services et standardisation

Page 4 26/09/2020 Sami BHIRI

 4 Informations

 Communication par échange de messages

 Message
• Structure = contenu abstrait
• Codage
 Protocole
• Les messages (structure) correct
• ? Séquencement de messages (logique d’échange)
 4 informations !
• Interface (abstraite)  strcuture des messages
• Codage des paramètres  codage des messages
• Protocole applicatif sousjacent  comment livrer les messages?
• Localisation  où livrer les messages?

Page 5 26/09/2020 Sami BHIRI

 Invocation d’une méthode

res = obj.op(5,’’bonjour’’) ;

equiv

j’envoie le message suivant à obj

| invoke | op | 5| bonjour |

Page 6 26/09/2020 Sami BHIRI

 SID - Plan

• Systèmes d’Information Distribués

– Organisation de SID
– Interactions dans SID
• Interactions d’applications
• Problèmes à résoudre
• Systèmes RPC
• De RPC aux intergiciels
• Limites des intergiciels classiques
• Services web Vs intergiciel classique

Page 7 26/09/2020 Sami BHIRI

 SID - Plan

• Acknowledgement and credits

• Systèmes d’Information Distribués
– Interactions dans DIS
• Interactions des applications
• Problèmes à résoudre
• Systèmes RPC
• De RPC aux intergiciels
• Limites des intergiciels classiques
• Services web Vs intergiciels classiques

Page 8 26/09/2020 Sami BHIRI

 Interactions dans les SID

 Comment connecter les différentes

couches et modules d’un SID

 Comment les différentes parties du

système interagissent

  à travers des interactions entre les

modules logicielles …

Page 9 26/09/2020 Sami BHIRI

 Communication inter processus (IPC)

 Permet la communication entre des processus

• Transférer des données
• Invoquer une action dans un autre processus
(éventuellement s’exécutant dans une autre machine
distante)

Page 10 26/09/2020 Sami BHIRI

 Appelle de procédure à distance -
Remote Procedure Call (RPC)
 Une représentation de haut niveau de IPC à distance

 Utilisele même métaphore et style de programmation que

l’appel de procédure classique

 Appel une procédure dans un autre processus

 Masque/fait abstraction des mécanismes de communication

Page 11 26/09/2020 Sami BHIRI

 Appel de procédure locale

int main() int add_numbesr(int a, int b)

{ {
int a = 10; 3 return a+b;
int b = 20;
}
int result;
2

1
result = add_numbers(a,b)

…
4
}
Processus X

Taken from Chris Greenhalgh

Page 12 26/09/2020 Sami BHIRI

 Appel de procédure à distance

int main() int add_numbesr(int a, int b)

{ {
int a = 10; 3 return a+b;
int b = 20;
}
int result;
2
1
result = add_numbers(a,b)
…
} Processus X
4 Processus Y

• Flot 1 et 3 sont les mêmes dans les deux cas (local et à distance)
• Mais dans deux processus différents thread/processus
• Flot 2: l’appel passe de X à Y
• Flot 4: le retour passe de Y à X Taken from Chris Greenhalgh

Page 13 26/09/2020 Sami BHIRI

 IP, TCP, UDP and Sockets

 Le protocole IP est le plus utilisé pour  Cependant, les sockets sont encore
la communication entre machines: de bas niveau pour plusieurs
envoie non fiable et livraison de applications  systèmes de RPC
paquets ont émergé pour
 IP est conçu pour être enfoui derrière • Masquer les détails de
d’autres couches logicielles: communication dans un appel de
• Le protocole TCP qui implémente un procédure
échange de messages connecté et • Réconcilie des environnements
fiable hétérogènes
• Le protocole UDP qui implémente un
échange (datagram) de messages non
fiable
 TCP/IP et UDP/IP sont visibles aux Applications
applications via les sockets: SOCKETS
similaire à l’abstraction de fichier
dans UNIX TCP, UDP
IP

©IKS, ETH Zürich.

Page 14 26/09/2020 Sami BHIRI

 SID - Plan

• Acknowledgement and credits

• Systèmes d’Information Distribués
– Organisation de SID
– Interactions dans SID
• Interaction des applications
• Problèmes à résoudre
• Systèmes RPC
• De RPC aux intergiciels
• Limites des intergiciels classiques
• Services web Vs intergiciels classiques

Page 15 26/09/2020 Sami BHIRI

 Interactions dans SID: comment interagir
dans un système distribué (1)
 Pour permettre à deux modules logiciels distribués de communiquer, il faut
résoudre 4 problèmes principaux:

1. Comment intégrer les primitives de communications dans les langages de

programmation
• Comment communiquer
• Paradigme sous-jacent du langage

2. Comment réconcilier différentes représentations machines des donnés et

faire l’appariement de différentes représentations des structures de
données complexes
• Différence au niveau machine
• Représentation des types de données abstraits

©IKS, ETH Zürich.

Page 16 26/09/2020 Sami BHIRI

 Interactions dans SID: comment interagir
dans un système distribué (2)

3. Comment trouver le module avec qui on veut communiquer

• Mode d’adressage (qui connait l’adresse et quand la déterminer)

4. Comment traiter les erreurs qui peuvent surgir durant le processus de

communication entre les modules
• … et comment recouvrir de ces erreurs

Page 17 26/09/2020 Sami BHIRI

 Interactions dans SID: le langage de
programmation (1)
 Communication implicite
• Les primitives de communication sont cachées derrières des constructions
de programmation normales
• Quand on invoque ces constructions, le système sous-jacent prend en
charge de transformer telle invocation à une interaction avec un module
logiciel distant
• Typiquement, cette forme de communication est bloquante (l’appelant doit
attendre l’appelé)
• Avantage: le programmeur n’a pas besoin de changer son mode de
programmation pour développer une application distribuée
• Inconvénient: quand des problèmes surgissent, c’est difficile au
programmeur de les traiter
• Exemples: mémoire partagée, Appel de procédure à distance (RPC), appelle
de méthode à distance (RMI)

©IKS, ETH Zürich.

Page 18 26/09/2020 Sami BHIRI

 Interactions dans SID: le langage de
programmation (2)
 Communication explicite
• Cette communication s’effectue via des primitives explicites
• Nécessite un modèle pour spécifier comment la communication se déroule
• Typiquement, ces formes de communications sont non bloquantes
• Avantage: les patrons de communications sont beaucoup plus flexibles
• Inconvénient: le programmeur doit connaitre comment la communication se
déroule
• Exemples: intérgiciel orientés message, queues persistants, systèmes à
base d’événements

Page 19 26/09/2020 Sami BHIRI

 Interactions dans SID: La
représentation intermédiaire (1)
 Pour comprendre les messages échangés, les parties doivent se mettre d’accord
comment représenter ces données:
• Ordre des octets et bits: Little-endian vs Big-endian
• Représentation des types de données complexes (tableaux. Arbres, structures, objets)
• Format des messages

 Marshalling: le processus de transformation d’une représentation de donnés

particulière vers une autre représentation plus adéquate à la communication (et le
stockage persistant)

 Serialisation: le processus de transformation de données en des chaines d’octets

qui peuvent être envoyées comme des paquets dans le réseau

©IKS, ETH Zürich.

Page 20 26/09/2020 Sami BHIRI

 Interactions dans SID: La
représentation intermédiaire (2)

 Il ya deux options pour résoudre ce problème de représentation de données

hétérogènes:
• NxN représentations intermédiaires
• Adopter une représentation intermédiaire comprise par tout les systèmes

 Une représentation intermédiaire doit être standardisée pour être vraiment utile

 Une représentation intermédiaire non standard est typiquement dépendante du

système. Par exemple:
• SUN RPC: XDR (External Data Representation)

Page 21 26/09/2020 Sami BHIRI

 Interactions dans SID: La
représentation intermédiaire (3)

 Les langages de définition d’interfaces (IDL) sont généralement utilisés:

typiquement utilisés dans des approches de communications implicites.

• Un langage de déclaration d’interfaces.

• Représentation de données intermédiaire: Correspondance entre les
représentations de données dans des langages particuliers et une
représentation intermédiaire.
• Une approche de (dé)sérialisation des données transmises.

 Utilisés par les compilateurs et les éditeurs de lien coté client (stubs) et
sereveur (skeleton) pour savoir comment procéder pour le (dé)marshalling et
la (dé)sérialisation lors d’un appel de procédure à distance.

Page 22 26/09/2020 Sami BHIRI

 Interactions dans SID : localiser un
module (1)

 Pour qu’un module communique avec un autre, il doit le

localiser (dans le réseau).

 Leprocessus de détermination de l’adresse d’un module à

invoquer est appelé liaison (binding).

Page 23 26/09/2020 Sami BHIRI

 Interactions dans SID : localiser un
module (2)
 La liaison (binding) peut être:

 Statique: l’appelant possède l’adresse de l’appelé et lui transmet les données directement
• La liaison statique est très efficace (pas d’indirection)
• La liaison statique conduit au couplage fort entre les différentes parties (assez
mauvais en général)

 Dynamique: est implémenté via un module intermédiaire (registre de service, service de

nommage, routeur)
• Adresse: l’appelant connait certaines informations sur l’appelé qu’il veut invoquer et
demande au module intermédiaire son adresse.
• Interface et adresse: l’appelant possède quelques informations sur ce qu’il veut
appeler et demande au module intermédiaire l’interface et l’adresse.
• La liaison dynamique est utilisée pour le balancement de charges, améliorer la
tolérance aux pannes, flexibilité de conception, et le découplage des parties
impliquées
• … comment trouver le service de nommage?
©IKS, ETH Zürich.

Page 24 26/09/2020 Sami BHIRI

 SID - Outline

• Acknowledgement and credits

• Systèmes d’Information Distribués
– Organisation de SID
– Interactions dans SID
• Interactions des applications
• Problèmes à résoudre
• Systèmes RPC
• De RPC aux intergiciels
• Limites des intergiciels classiques
• Services web Vs intergiciels classiques

Page 25 26/09/2020 Sami BHIRI

 RPC en pratique

©IKS, ETH Zürich.

Page 26 26/09/2020 Sami BHIRI

 RPC: comment ça marche en pratique

©IKS, ETH Zürich.

Page 27 26/09/2020 Sami BHIRI

 RPC: comment ça marche en pratique

Souche module annuaire de module Souche

client client comm. noms / services comm. serveur Serveur
appel
de proc. demande d’inscription
locale de service

bind Ack Ack

demande de résolution

adresse du module
marshalling

envoie
appel de procédure à distance

26/09/2020
 RPC: comment ça marche en pratique

Souche module annuaire de module Souche

client client comm. noms / services comm. serveur Serveur

unmarshalling
appel
local

ret. rslt

marshalling
unmarshalling

resultat

ret. envoie
rslt

26/09/2020
 RPC en pratique

 Le programmeur ne peut pas implémenter toutes les mécanismes nécessaires à

chaque fois il développe une application distribuée. Plutôt , ils utilisent/reposent
sur un système de RPC (premier exemple d’intergiciel de bas niveau)

 Un système RPC
• Fournit un langage de définition d’interface (IDL) pour décrire les services
• Génère tout le code additionnel nécessaire pour faire un appel de procédure à
distance et traiter les différents aspects de communication
• Fournit un “binder” en cas il utilise un service de nommage distribué

Applications
RPC
SOCKETS
TCP, UDP
IP
©IKS, ETH Zürich.

Page 30 26/09/2020 Sami BHIRI

 IDL (Interface Definition Language)

 Tous les systèmes RPC fournissent un langage, IDL, pour décrire

les services d’une manière abstraite / intermediaire
(indépendamment des langages de programmation)

 IDL définit aussi une représentation intermédiaire des données.

 Un compilateur d’interface est alors utilisé pour générer des

‘’stubs’’ pour les clients et ‘’skeletons’’ des serveurs. Il peut aussi
générer des entêtes de procédures que les programmeurs
peuvent utiliser et étendre pour compléter l’implémentation des
serveurs et des clients.

©IKS, ETH Zürich.

Page 31 26/09/2020 Sami BHIRI

 IDL (Interface Definition Language)

• Étant donné une spécification IDL, le compilateur d’interface

achève un ensemble de tâches pour générer les ‘’stubs’’ et
‘’skeletons’’ dans des langages de programmation particuliers
(comme JAVA, C) :
1. Génère la procédure de stub du client pour chaque procédure
dans l’interface. Le stub va alors être compilé et lié avec le code
du client.
2. Génère le skeleton du serveur. Il peut aussi générer une
ébauche du code de serveur. Ce code peut être alors complété
par le développeur pour implémenter les procédures.
3. Il peut aussi générer des fichiers (d’entête *.h/des classes) des
types à importer par les clients et serveurs.

©IKS, ETH Zürich.

Page 32 26/09/2020 Sami BHIRI

 De RPC aux intergiciels

Application
servers

Object Message
TP-Monitors
brokers brokers

Transactional Object Asynchronous

RPC oriented RPC messaging

Remote Procedure Call

Sockets

TCP, UDP

Internet Protocol (IP)

©IKS, ETH Zürich.

Page 33 26/09/2020 Sami BHIRI

 SID - Plan

• Acknowledgement and credits

• Systèmes d’Information Distribués
– Organisation des SID
– Interaction dans SID
• Interactions des applications
• Problèmes à résoudre
• Systèmes de RPC
• De RPC aux intergiciels
• Limites des intergiciels classiques
• Services web Vs intergiciel classique

Page 34 26/09/2020 Sami BHIRI

 Modes d’intégration d’applications

 Intégration top-down
• Les applications à intégrer n’existent pas déjà
• Elles sont développées en même temps que l’application
principale
• Spécification, conception et développement tout en tenant
compte de la répartition
 Intégration bottom-up
• Les applications à intégrer existent déjà
• Elles sont opérationnelles sous différentes entités de
gouvernance
• Elles ont des protocoles et des formats de données
hétérogènes
Page 35 26/09/2020 Sami BHIRI
 Exercice

 Est-cequ’on peut utiliser (de point de vue technique)

CORBA pour intégrer des composants logiciels
existants

Page 36 26/09/2020 Sami BHIRI

 Problèmes des intergiciels
traditionnels

 Interfaces non standard.

• Les intergiciels pré-WS souffrent de manque de standardisation  assez difficile et
couteux de construire des systèmes distribués impliquant différents intergiciels

 Manque de confiance.
• Développer des systèmes intégrés impliquant différents domaines de confiance est
souvent assez difficile.
• Avec les services Web, l’API d’une entreprise est exposé sur le Web. Comment faire
confiance aux clients?

 RPC vs. Messaging

• Les interactions inter-organisationnelles peuvent être de longues durées et devraient
être traitées d’une façon asynchrone.

Page 37 26/09/2020 Sami BHIRI

 Problèmes des intergiciels
traditionnels  vers les services Web

 Une connexion directe entre les différentes organisations n’est pas permise
(mesures de sécurité et confidentialité) et parfois pas possible (intergiciel
incompatible).

 Conceptuellement, il est possible d’utiliser un intergiciel global. Cependant, en

pratique, ceci n’est pas envisageable. Qui le détient?

 Les solutions point-à-point sont couteuses et ne passe pas à l’échel avec le

nombre de systèmes à intégrer.

 Publier les systèmes à intégrer comme des services Web simplifie l’intégration et
garde les différentes parties faiblement couplées.

Page 38 26/09/2020 Sami BHIRI

 Interopérabilité des composants

 À cause de manque d’interopérabilité, il n’est pas toujours possible de

développer des systèmes distribués en utilisant des composants
hétérogènes.

Eiffel
Java DCOM
.NET
Bean Object
Assembly

Legacy
CORBA COBOL
Object Program

Page 39 26/09/2020 Sami BHIRI

 Interopérabilité avec les services Web

 Si les composants sont publiés comme des services Web, ils peuvent
inter-opérer à travers différents environnements de composants.
(Interoperability through Wrapping)

Eiffel
Java DCOM
.NET
Bean Object
Assembly

Web Legacy
CORBA COBOL
Services
Object Program

©IKS, ETH Zürich.

Page 40 26/09/2020 Sami BHIRI

 Les services Web et les intergiciels

 Les services Web peuvent être vus comme une évolution naturelle des
intergiciels existants.

 Les standards de services web permettent l’interopérabilité des

intergiciels existants.

 L’intégration d’applications d’entreprise est plus facile avec les services

Web.

 L’intégration interentreprises (B2B) est plus facile/réaliste grâce à des

interfaces basées sur des standards.

Page 41 26/09/2020 Sami BHIRI