Présentation SOA

Dr.
Dehimi Nour El Houda

2
Introduction
 Depuis le début de la programmation, on cherche à réutiliser ce qui a été
déjà fait afin de le combiner, de l’intégrer.
 Au départ, le seul moyen de réutiliser du code était de le recopier dans notre

programme.
 Dans ce sens plusieurs paradigme de programmation ont été proposés
 Chaque paradigme de programmation propose un modèle de description

et un ensemble de stratégies d'analyse.
3
Introduction
4
Introduction
5
6
La programmation procédurale
 Avantages
 la possibilité de réutiliser le même code à différents emplacements dans le
programme sans avoir à le retaper (factorisation),
 la réduction de la taille du code source
 localité rapide des modifications  une amélioration de la maintenabilité

 compréhension plus rapide  réduction du risque de régression
 une façon plus simple de suivre l'exécution du programme
 la programmation procédurale permet les « effets de bord », c'est-à-dire la

possibilité pour une procédure de modifier des variables extérieures à la
procédure auxquelles elle a accès (variables de contexte plus global que la
procédure).
7
La programmation procédurale
 Inconvénients
 L’évolution d’une application développée suivant ce modèle n’est pas
évidente car la moindre modification des structures de données d’un
programme conduit à la révision de toutes les procédures manipulant ces
données.
 Pour de très grosses applications, le développement peut être très long
8
9
La programmation orienté objet (POO)
10
 Historique
 La notion d'objet a été introduite avec le langage de programmation
Simula, créé à Oslo (1962) dans le but de faciliter la programmation
de logiciels de simulation.
 Simula (1966) regroupe données et procédures.
 Simula I (1972) formalise les concepts d'objet et de classe. Un

programme devient une collection d'objets actifs et autonomes.
 Smalltalk (1972) : généralisation de la notion d'objet.
 C++ (1983) : Extension du C s'inspirant de Simula
11
 Définition
 La programmation orientée objet (POO) est un type de programmation qui a
pour avantage de posséder une meilleure organisation, surtout dans les gros
programmes.
 Ces derniers seront agencés de façon plus logique et seront donc plus
facilement modifiables.
 Un programme orienté objet est un ensemble d'objets autonomes et
responsables qui s'interagisses pour résoudre un problème final.
12
 L’évolution du POO
 Tout est objet! : chaque objet encapsule des données et des méthodes
agissant sur ces données.
 L’encapsulation réalise une abstraction des données : vu de l’extérieur de
l’objet, les détails d’implémentation sont cachés.
 Le concept de classe généralise la notion de type : tous les objets d’une
certaine classe sont des instances de cette classe.
 Des classes peuvent hériter d’autres classes (classe mère - classes
filles). La notion d’héritage permet d’établir une hiérarchie entre les
classes.
 Avec l’héritage, il devient possible de redéfinir des méthodes au sein des
classes filles. On parle de polymorphisme.
13
 Les limites du POO
 Pas de vue globale de l’architecture d’une application

 Interactions entre objets enfouies dans le code
 Évolution / modification difficile
 Peu d’outils pour le déploiement et l’administration
 Gestion de la consistance d’un changement délicate.
 Beaucoup de tâches doivent être gérées manuellement
• définition des instances
• références directes entre les instances + appels explicites de
méthodes
• gestion des dépendances entre classe
14
15
La programmation orienté composant (POC)
 Définition
 Les composants sont des entités logicielles indépendantes utilisant des ports
pour permettre leur communication au sein d’une même application ou à
travers un réseau
 Programmation orientée composant = programmation par assemblage,
plutôt que par développement (cas de la POO)
 Un composant = un ensemble d’objets + des ports (Ports offerts, Ports

requis)
16
 Notion de port
 Un composant interagit avec le monde extérieur via des ports offerts et
requis
 Ports offerts = exportation vers le monde extérieur
 Implantés dans le code du composant
 Ports requis = importation depuis le monde extérieur
 Utilisés depuis le code du composant
 Assemblage de composant = Liaison entre

1 port requis et 1 port fourni
17
 Avantages
 Encapsulation (Réaliser plusieurs implantations du même port)
 Composabilité (un assemblage de composants est un composant).
 Encore plus de réutilisabilité
 Une vue globale de l’architecture d’une application
 Évolution / modification facile
 Gestion de la consistance d’un changement très facile.
18
 Les limites de la POC

 Cependant, cette architecture, bien qu’utilisant un modèle objet distribué,
impose sa propre infrastructure et une liaison forte et figée entre les
fonctionnalités offertes par les composants et leurs clients.
 Les applications construites à base de cette architecture sont donc

monolithiques. L’architecture à base de composants est incompatible
avec l’ouverture de l’infrastructure Internet.
 Ils présentent une vision particulière de comment développer des logiciels.

 Ils ne disent pas comment programmer : l’approche orientée objet est
complémentaire.
 Analogie avec l’approche orientée objet et la programmation structurée
19
20
La programmation orienté service (POS)
21
 Définition
 SOA présente un modèle d’architecture informatique basée sur l’émergence
d’une couche de services.
 Ces services offrent une vue logique des traitements et données

existant déjà ou à développer, et chaque service encapsule ces traitements et
données et masque ainsi l’hétérogénéité du système d’information.
22
 Définition
 La couche présentation ne manipule plus directement les objets métiers, mais passe
par des services.
 Les services agissent comme des boites noires faisant abstraction de la complexité
du modèle objet,
 présentant un ensemble de fonctionnalités restreintes et permettant de réduire les
échanges entre les couches.
23
Notion de service
 Dans une SOA, un service représente une brique logicielle dont les
fonctionnalités, les propriétés non fonctionnelles ainsi que les conditions
d'utilisation sont définies de manière déclarative par un descripteur de
service.
 Un service peut être publié et rendu disponible pour être utilisable par des
tiers.
 Ainsi des services peuvent être utilisés tels quels ou bien être composés
pour exécuter une fonctionnalité de plus haut niveau, voire orchestrés pour
mener à terme un processus complexe et atteindre un objectif précis.
 Grâce aux mécanismes d'encapsulation et de liaison retardée, un service
peut-être décrit et utilisé indépendamment de sa réalisation.
 La liaison proprement dite n'est effectuée qu'au moment de l'exécution, juste
avant que le service requis ne soit utilisé.
 De ce fait on a un couplage extrêment faible entre services et
l'interopérabilité de systèmes en environnements hétérogènes,
24
 Caractéristiques d’un service :
 Modularité (l'architecture orientée service s'expriment par une tendance à
modulariser les fonctionnalités en un ou des service(s)).
 Boite noire (séparation interface/implémentation).
 Indépendance de la localisation.
 Neutralité vis-à-vis des protocoles de transport.
 Faiblement couplé (indépendant des autres services).
25
 Les composants techniques d’un service
 Les éléments techniques qui composent un service sont:
26
 1 L’interface : L’interface de service permet de définir les modalités d’accès au
service (nom, les données d’entrée et de sortie des opérations publiques). Ceci pour
encapsuler l'implémentation et l’exécution physique de service. La fonctionnalité du
service est exposée par l'interface aux clients.
 2 Le contrat : Le contrat de service joue un rôle majeur : il détaille les conditions
d’utilisation du service sous forme de pré et post conditions, protocoles, et contraintes.
 Un contrat de service est un document organisé en plusieurs parties qui sont :
 - L’identification des parties
 - La description des fonctions du service.
 - La description de l’interface du service.
 - La description de la qualité du service.
 - La description du cycle de vie du service et du contrat.
 - La description des termes de l’échange (s’il y’en a).
 3 L’implémentation : L’implémentation de service fournit physiquement la logique
d'affaire exigée et les données appropriées. C'est la réalisation technique qui accomplit le
contrat de service.
 4 Données : Un service peut également inclure des données.
 5 La logique métier : Il se compose des règles de service, les exécutions et les
résultats d’un service dans la réalité.
27
Propriétés d’un service
 Un service doit posséder les caractéristiques suivantes:
28
 Propriétés d’un service
 L’autonomie
 Un service doit être autonome et indépendant dans le contexte de
l’architecture SOA.
 Granularité
 Un enjeu de la SOA est de trouver la bonne granularité des services
proposés par une application.
 En effet, un service à granularité trop fine n’offre que peu d’intérêt
au niveau métier (des services renvoyant uniquement le nom
d’un client, ou juste son adresse …. )
 Des services à granularité plus forte, créés à partir de plusieurs
composants structurés, offrent plus d’intérêt dans la réalisation d’un
processus global.
29
 Couplage faible
30
 Interopérabilité
 Elle est considérée comme propriété fondamentale, dans le sens où l’appel
au service fonctionne quel que soit le langage de programmation et le
système d’exploitation.
 Réutilisabilité
 Les services sont conçus de façon à ce qu'ils puissent être réutilisés
ultérieurement. Le but est de minimiser la redondance et rendre le service
réutilisable par les différentes applications du système d’information.
 Composabililté
 Les services peuvent invoquer ou utiliser d’autres services, le principe
est la décomposition des processus métiers en un certain nombre
d’unités d’activités sous forme de service.
31
 La qualité de service
 L’interaction entre un fournisseur et un consommateur de services se fait à
travers une interface selon un contrat d’utilisation, évidemment on
échange des données de nature métier.
 Découvrabilité
 Pour invoquer un service on doit connaitre que le service existe, donc
il y a un domaine publique là où on peut trouver tous les services
ainsi que la description de chaque service.
32
 Acteurs de la SOA
33
 Acteurs de la SOA
 Fournisseur de service (Service Provider) :
 Application s'exécutant sur un serveur et comportant un module logiciel
invocable de l’extérieur par envoi de message.
 Description de l’interface de l’application suivant une spécification (X).

 Registre de service (Service Registry) :
 Annuaire des services publiés par les fournisseurs (providers).
 Géré sur un serveur niveau application, entreprise ou mondial (destiné à un
monde ouvert) (Z).

 Demandeur de service (Service Requester) :
 Application cliente se liant à un service et invoquant ses fonctions
 par échange de messages suivant un format (Y).
34
 Principes d’une SOA
 Le principe d’une SOA repose sur les 4 principes suivants :
 La définition du service est explicite :

 Un service est une classe exposée à travers les réseaux.
 Le but de ce service est de fournir une prestation bien définie.
 Les détails d’un service sont contenus dans un document standardisé, qui fait
office de contrat entre le client et le serveur.
 Les services sont autonomes :

 Un service implémente ses propres composants et ses propres méthodes d’accès
aux données, il ne doit dépendre d’aucun élément externe.
 On doit pouvoir le remplacer ou le déplacer sans que cela affecte d’autres
services.
35
 Principes d’une SOA
 Les clients et les services ne partagent que des contrats :

 Les services exposent des contrats aux clients sous forme d’une interface de
fonctionnalités et de la manière de les utiliser.
 Cette interface est la seule chose que le serveur partage avec le client. En aucun
cas, le service et le client ne doivent partager du code.
 La compatibilité est basée sur les règles :

 Les applications consomment des services distants, pouvant réaliser des tâches
métiers, en s’échangeant des messages.
 Chaque service possède un contrat qui fournit des spécifications sur les
opérations qu’il propose (signature, données à fournir entrée, données
retournée…).
 Chaque contrat possède un schéma, qui décrit des messages échangées entre les
services et les applications qui les consomment.
36
 L’objectif principal d’une architecture orientée services est de :
 Le point clé à comprendre en la matière, c’est qu’on n’écrit pas des applications de type
«service», on développe plutôt des services autour des applications existantes, pour les
rendre aptes à communiquer entre elles.
 Décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées services.
 Fournir ces services par des composants et de décrire finement le schéma d'interaction
entre ces services.
 L'idée sous-jacente est donc de cesser de construire une architecture logicielle globale
décomposées en services correspondant aux processus métiers .
 Ces services peuvent être assemblés et liés entre eux selon le principe de couplage faible
pour exécuter l’application désirée.
37
 Avantages :

 Les SOA disposent de tous les avantages d’une architecture client-serveur. C'est à dire
une plus grande modularité, on peut facilement remplacer un composant (service) par un
autre.

 Ils offrent également la réutilisation des composants, des meilleures possibilités
d’évolutions, une plus grande tolérance aux pannes ainsi qu'une maintenance plus facile.

 La réutilisation de composants existants réduit le risque d’introduction de nouveaux
échecs dans le processus d’amélioration ou de création de nouveaux services.

 Ces services sont réutilisables, il est donc possible de bâtir de nouvelles applications
faisant appel à des services tiers.

 Les SOA ont une architecture n-tiers, c'est-à-dire la séparation de la présentation des
données du traitement et de la base de données, où chaque serveur peut avoir une fonction
unique.
38
 Inconvénients :
 Mise en place d’une SOA a un coût élevé à la fois financier et humain :

 Former une équipe d'experts en conception ainsi que plusieurs équipes pour
développer et administrer les différents services.
 Dans le cas idéal, l’activité de l’entreprise doit être pensée autour des services.
 Si le fonctionnement de l’entreprise n’est pas organisé autour des services alors
il est difficile d’utilisé une SOA et donc le coût de fonctionnement sera élevé.

 Les SOA ont un intérêt limité si l’entreprise ne base pas ses processus sur
l’exploitation des services.

 Difficulté de migrer d’une architecture monolithique vers une architecture SOA

sans étude préalable efficace.
39
40
Les Services Web
 L’architecture SOA offre un avantage évident qui est l'interopérabilité. Les

services peuvent ainsi s'invoquer et interagir mutuellement indépendamment
des plates-formes sous-jacentes et des langages dans lesquels ces services
ont été développés.
 Lorsque les interactions s'appuient sur Internet et sur les standards Web, on
parle de services Web.
 Un service web désigne une application mise à disposition sur internet par un
fournisseur de service, et accessible via son interface par les clients à travers des
protocoles Internet standard.
 Ces fonctionnalités peuvent être découvertes, invoquées et composées pour

fournir une solution ou une réponse à un problème ou à une requête d’un utilisateur
qui y accède via l’ubiquité des protocoles Web.
41
Les Services Web
 Principaux acteurs du service Web
 Le fournisseur de service (serveur) : celui qui crée le

service Web et publie toutes ces caractéristiques
dans l’annuaire de service.
 Le demandeur de service (consommateur) : quant à
lui, accède à l’annuaire pour rechercher le service
Web dont il a besoin et avec lui la normalisation à
obtenir.
 L’annuaire : rend disponible les interfaces d’accès
aux services et donnant le contrat et l’architecture
employée pour permettre les interactions.
 Les services web reposent sur une collection de normes
et de protocoles appelée Web Services Protocol Stack
et qui contient entre autre :
 XML et SOAP pour les requêtes et les réponses .
 WSDL pour la description des services Web.
 UDDI pour la recherche des services Web nécessaires
au bon fonctionnement des applications.
42
Les Services Web
 Fonctionnement des services Web
43
Les Services Web
 Le scénario complet d’un service web :
 Etape 1 : définition et description de service

 On doit décrire d’un point de vue informatique ce que fait le service, la
solution qu’il propose.
 La définition est faite par WSDL au sein du fournisseur de services (i.e. le
serveur d’applications).
 Etape 2 : publication de service

 Une fois le service définit et décrit, il peut être déclaré dans un annuaire, on
parle alors de publication du service afin de rendre accessible aux clients.
 La publication sera effectuée au sein d’un annuaire dédié UDDI.
 Etape 3 : recherche du service

 Le client se connecte, sur un annuaire UDDI pour effectuer une recherche
de service.
44
Les Services Web
 Le scénario complet d’un service web :
 Etape 4 : enregistrement au service web

 Une fois le service trouvé par le client ce dernier doit s’enregistrer auprès du
fournisseur associé au service.
 Cet enregistrement indique au fournisseur l’intention du client d’utiliser le
service suivant les conditions décrites dans la publication.
 Etape 5 : mise en œuvre du service

 Le client peut invoquer le service suivant les conditions inscrites au sein de
l’annuaire lors de la publication du service web (étape 2).
 Etape 6 : composition
 C’est la possibilité de combiner plusieurs services. En fait un service peut
devenir le client d’un autre service.
45
Les Services Web
 Technologies Associées aux services web
46
Les Services Web
 SOAP ( Simple Object Access Protocol)
 SOAP est un protocole de dialogue par appels de procédures à distance
entre objets logiciels.
 Sa syntaxe d’utilisation est fondée sur XML et ses commandes sont

envoyées sur Internet par l’intermédiaire du protocole http mais aussi SMTP
et POP sous forme de texte structuré.
 Il est indépendant du langage d’implémentation des applications client et

serveur. En plus, il peut potentiellement être utilisé avec une variété de
protocoles (e.g. HTTP, SMTP, HTTP Extension Framework).
47
Les Services Web
 Fonctionnement SOAP
 Fonctionnement côté client :

 Ouverture d’une connexion http.
 Requête SOAP est un document
XML décrivant :
 Une méthode à invoquer sur une
machine distante.
 Les paramètres de la méthode.

 Fonctionnement côté serveur :
 Récupère la requête.
 Exécute la méthode avec les
paramètres.
 Renvoie une réponse SOAP
(document XML) au client.
48
Les Services Web
 Syntaxe de SOAP
 Un message SOAP est un document

XML ordinaire contenant les éléments
suivants:
 Une enveloppe : élément indispensable

qui identifie le document XML comme
un message SOAP.
 Un header : élément qui contient des
informations d'entête (optionnel).
 Un body élément qui contient les
informations d'appel et de réponse, qui
est aussi indispensable.
 Un fault élément qui fournit des
informations sur une erreur qui
surviendrait lors du traitement du
message.
49
Les Services Web
 Syntaxe de SOAP « L’enveloppe SOAP »
50
Les Services Web
 Syntaxe de SOAP « L’enveloppe SOAP »
 L’enveloppe SOAP définit l’espace de nom (namespace : URI permettant

de connaître la provenance de chaque balise) précisant la version supportée
de SOAP.
 Cet espace de nom est standard et permet de différencier les éléments du

schéma (e.g. http://www.w3.org/2001/06/soap-envelope/ ).
 L’enveloppe SOAP est constituée d’un en-tête facultatif (SOAP header) et

d’un corps obligatoire (SOAP body).
51
Les Services Web
 Syntaxe de SOAP «L’en-tête SOAP »
 L’en-tête peut avoir plusieurs fils (SOAP blocks). Ces fils sont utilisés pour
ajouter les fonctionnalités au message comme l’authentification et la
gestion des transactions.
 L’en-tête peut utiliser les attributs mustUnderstand et/ou SOAP actor

pour indiquer comment traiter l'entrée et par qui.
 L'attribut mustUnderstand peut être utilisé pour indiquer si une entrée d’en-
tête est obligatoire ou facultative pour être traité par le destinataire.
 Le destinataire d'une entrée d’en-tête est défini par l'attribut d'acteur de

SOAP. La valeur de l'attribut de mustUnderstand est "1" ou "0".
52
Les Services Web
 Syntaxe de SOAP «Le corps SOAP»
 Le corps SOAP contient l’information destinée au receveur. Il doit fournir

le nom de la méthode invoquée par une requête, ou le nom de la méthode
pour générer la réponse.
 Il doit aussi, fournir l’espace de nom correspondant au nom du service.
 Le corps SOAP peut contenir un SOAP fault. Ce bloc est utilisé pour
transmettre l’information des erreurs durant le traitement du message.
53
Les Services Web
 Syntaxe de SOAP «Exemple»
 Exemple de requête : Quel est le prix des pommes ?

 <?xml version="1.0"?>
 <soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:Body>
 <m:GetPrice xmlns:m="http://www.w3schools.com/prices">
 <m:Item>Apples</m:Item>
 </m:GetPrice>
 </soap:Body>
 </soap:Envelope>
54
Les Services Web
 Syntaxe de SOAP «Exemple»
 Le prix des pommes est 1,90. Une réponse SOAP est le suivant :

 <?xml version="1.0"?>
 <soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:Body>
 <m:GetPriceResponse
 xmlns:m="http://www.w3schools.com/prices">
 <m:Price>1.90</m:Price>
 </m:GetPriceResponse>
 </soap:Body>
 </soap:Envelope>
55
Les Services Web
 Syntaxe de SOAP L’élément SOAP Fault
Un message d’erreur est porté par cet élément. L’élément Fault a les éléments fils
suivants :
56
Les Services Web
 Syntaxe de SOAP L’élément SOAP Fault
 Les codes des erreurs
Pour décrire une erreur l’élément faultcode utilise les valeurs suivantes
dépendamment de l’erreur qui s’est produite :
57
Les Services Web
 WSDL : Web Service Desciption Language
 Le langage WSDL est une syntaxe XML utilisée pour définir l'interface générale des
services web. Cette définition intègre les composants fondamentaux suivants :
 Informations sur toutes les fonctions disponibles publiquement.

 Définitions abstraites des données à transmettre.
 Informations sur le type de données pour tous les messages XML.
 Informations obligatoires sur le protocole de transfert à utiliser spécifiquement.
 Informations de type Adresse pour localiser le service à spécifier.

 Les définitions WSDL facilitent l'application des services web en les rendant "auto
descriptifs". Autrement dit, WSDL permet aux services web de décrire, de manière
abstraite et indépendante du langage de programmation, ce qu'ils font, comment ils
le font et comment les clients peuvent les exploiter.
58
Les Services Web
 Structure d’un document WSDL
 WSDL décrit un service web en deux étapes fondamentales: une
abstraite et une concrète.
 La description abstraite (La description de l’interface du service)
contient :
 <types>
 <message>
 <port type>
 <operation>
 La description concrète (La description de l’implémentation du

service) contient des informations relatives à l’endroit où est
publié le service:
 <binding>
 <service>

59
Les Services Web
60
Les Services Web
 Un document WSDL contient les entités suivantes:
 Types: précise les types de données complexes, pour lequel WSDL emploi XML Schema.
 Message: l’abstraction décrivant les données échangées entre services Web.
 Operation: l’abstraction décrivant une action implémentée par service Web.
 Type de port: Cet élément définit de manière abstraire une collection d’opérations ou
d’actions, chaque opération est déclenchée par une requête, puis génère une réponse.
 Liaison (binding): un protocole concret d’accès à un port et un format de spécification des

messages et des données pour ce port. (exemple : SOAP1.1, HTTP, MIME (Multipurpose
Internet Mail Extension), …)
 Port: un point de terminaison identifié de manière unique par la combinaison d’une adresse
Internet et d’une liaison.
 Service Web: une collection de ports. En général ; il correspond à une URL invoquant un
service SOAP.
61
Les Services Web
62
Les Services Web
63
Les Services Web
64
Les Services Web


65
Les Services Web
66
Les Services Web
67
Les Services Web
 UDDI Universal Desciption, Discovery and Integration :
 L’objectif principal d'UDDI est la spécification d'un canevas pour décrire et
découvrir des services Web.
 Il définit des structures de données et APIs pour publier les descriptions des services
dans le registre et pour interroger le registre afin de chercher des descriptions
publiées.
 Parce que les APIs de l’UDDI sont aussi spécifiés en WSDL avec une attache SOAP,
le registre peut être invoqué comme un service Web (en conséquence, ses
caractéristiques peuvent être décrites dans le même registre, comme un autre
service).
 Les spécifications du « registry » UDDI ont deux buts principaux en ce qui concerne
la découverte d'un service:
 Le premier, soutenir les développeurs dans la découverte d'informations sur les
services.
 Le deuxième, permettre la liaison dynamique et en conséquence habiliter les clients
pour interroger le registre et obtenir des références aux services d’intérêt
68
Les Services Web
 L’annuaire UDDI est composé de :
 a-Pages blanches (BusinessEntity)
 Décrites sous la forme d’un schéma XML, elles contiennent les éléments relatifs à
l’entreprise qui propose le service (nom, coordonnées, secteur d’activité, l’adresse
du siteweb…)
 b-Pages jaunes ( BusinessService )
 C’est un ensemble de services proposés répondant à un besoin métier spécifique,
elles contiennent des informations relatives au métier de l’entreprise, ainsi q’une
description des services web proposés par ce dernier (nom du service, description,
code…).
 Une entreprise peut avoir plusieurs métiers et donc plusieurs businessService.
69
Les Services Web
 L’annuaire UDDI est composé de :
 c-Pages vertes (bindingTemplate)
 Contiennent les informations techniques sur un service web, et les références aux
tmodels (spécification des interfaces des services web)

 d-Les tModels
 Représentés par un schéma XML, Ils contiennent des informations permettant de
connaître les normes que respectent le service web, le format des messages, le
protocole de transport utilisé et d’identifier la catégorie à laquelle appartient le
service.
70
Les Services Web
71
Les Services Web
 Relation entre WSDL et UDDI :
 Le WSDL contient deux parties :
 La description de l’interface du service.
 La description de l’implémentation du service.
 La description de l’interface d’un service correspond aux informations techniques du
service, c’est en quelque sorte une classe abstraite qui sera utilisée pour implémenter
un ou plusieurs autres services. Elle regroupe : types, import, message, portType,
binding.
 La description de l’implémentation du service correspond aux informations relatives
à l’endroit où est publié le service. Elle regroupe : Documentation, import, service,
port.
 Ce qui signifie que l’interface du service dans le WSDL correspond aux parties
tModel dans UDDI et que l’implémentation du service corresponde au Business
Service de l’UDDI comme illustré sur la figure suivante :
72
Les Services Web
73
74
Le protocole de transfert hypertexte (HTTP, Hypertext
Transfer Protocol)
 Le protocole de transfert hypertexte (HTTP, Hypertext Transfer Protocol) est un protocole de niveau
application pour les systèmes d’information multimédia distribués et collaboratifs.
 Ce protocole a été créé au début des années 1990 par l’initiative mondiale d’informations de la
Toile (World-Wide Web).
 Le but est de fournir au Web un protocole de transfert simple capable d’accéder aux fichiers
situés sur le réseau Internet.
 Le protocole HTTP fonctionne selon un principe de requête/réponse où le client transmet une requête
comportant des informations sur le document demandé et le serveur renvoie le document si ce dernier
est disponible, dans le cas échéant, un message d’erreur est renvoyé.
 HTTP offre un ensemble ouvert de méthodes et d’en-têtes qui indiquent l’objet d’une requête [1].
75
Transfer Protocol)
Les versions du protocole HTTP
 a. La première version de HTTP, est apparue en 1990, elle portait la référence HTTP/0.9, et
était un simple protocole pour le transfert de données brutes sur l’Internet. Cette version était
caractérisé par :
 - Impossible d'envoyer des données vers les serveurs, la communication est unidirectionnelle
(seule la méthode GET existe);
 - Il n'existe aucun type de fichier : seul le texte (text/plain) est géré ;
 - Il n'existe aucun code de statut HTTP, si le document n'existe pas, une page blanche est
servie ;
 - La notion d'en-tête HTTP n'est pas définie ;
 - Le serveur ferme la connexion pour signaler la fin de la réponse.
76
Transfer Protocol)
 b. La deuxième version, normalisée en 1996, est HTTP/1.0 [13]. Cette version est caractérisé
par :
 - Les messages sont au format de messages du style MIME, contenant des métas
informations sur les données transférées et des modificateurs de la sémantique des
requête/réponses ;
 - L’introduction de la méthode POST : le client peut envoyer des données vers le serveur qui
exécutera alors un script CGI pour traiter ces données, apparaissent alors les formulaires ;
 - La gestion de l'authentification est aussi intégrée dans HTTP 1.0, avec 2 modes : basic ou
digest ;
 - Les connexions persistantes sont ajoutées, mais non utilisées par défaut par les clients et les
serveurs.
77
Transfer Protocol)
 C. La version HTTP/1.1 est caractérisé par :
 Support de l'hébergement virtuel par nom : en-tête Host ;
 Prise en charge du relai bout-à-bout dans le transport de la version du protocole via proxies : en-
tête Via ;
 Découverte de version : Méthode OPTION et en-tête Upgrade ;
 Prise en charge des requêtes partielles
 Les connexions persistantes sont devenues les connexions par défaut, en-tête Connection ;
 Prise en charge du pipelining (plusieurs requêtes par connexion TCP), en-tête Content-Length et
segmentation des réponses : chunked ;
 Amélioration dans la gestion du cache : Etags, Cache-Control, Age, max-age, If-None-Match... ;
 Ajout du support de la négociation de contenu, en-têtes Vary, Accept-* ;
 24 nouveaux codes de réponse : 100, 206, 409... ;
 Amélioration de la compression avec une compression bout-à-bout, en-tête Transfert-Encoding.
78
Transfer Protocol)
 Requête et réponse HTTP
 Requête HTTP
 Structure d’une requête HTTP
 La requête transmise par le client au serveur comprend :
 Une ligne de requête (request-line) contenant la méthode utilisée, l’URL du

service demandé, la version utilisée de http ;
 Une ou plusieurs lignes d'en-têtes, chacune comportant un nom et une

valeur.
79
Transfer Protocol)
- Selon la première ligne le protocole est HTTP v.1.1 et le
 Exemple : fichier demandé se trouve dans un répertoire « images ».
 GET /images/lapin.jpg HTTP/1.1 - Les trois lignes suivantes indiquent le type de document
 Accept: image/jpeg, text/html, */* que le client attend de la part du serveur. Ici il est
 Accept-Language: fr indiqué que le client voudrait une image au format jpeg,
 Accept-Encoding: gzip, deflate ou un fichier html ou bien à défaut n’importe quel type
 User-Agent: Mozilla/5.0 de fichier. Par ailleurs il préfère les documents en langue
(Macintosh; U; PPC Mac OS X; fr) française (fr) et accepte que le fichier soit compressé à
AppleWebKit/418.9.1 (KHTML,
like Gecko) Safari/419.3 l’aide de l’un des algorithmes gzip ou deflate.
 Connection: keep-alive - Le champ User-Agent donne des informations sur le
 Authorization: Basic client (navigateur utilisé, système d’exploitation, etc.).
bGFwaW46dG9ydHVl
- Le champ Connection indique que la socket utilisée
 Host: localhost:7777
pour la connexion doit être maintenue ouverte après la
réponse du serveur.
80
Transfer Protocol)
- Le champ Authorization permet de s’identifier auprès du serveur.
 Exemple : Dans l’exemple ci-dessus, on utilise la méthode Basic qui consiste
simplement en l’envoi d’un identifiant et d’un mot de passe. Ces deux
 GET /images/lapin.jpg HTTP/1.1
données sont encodées en base 64 afin de s’assurer que les symboles
 Accept: image/jpeg, text/html, */* spéciaux pouvant apparaître ne poseront pas de problème. Dans
 Accept-Language: fr l’exemple, la chaîne de caractères bGFwaW46dG9ydHVl est
 Accept-Encoding: gzip, deflate l’encodage en base 64 de la chaîne lapin:tortue. Notons que
 User-Agent: Mozilla/5.0 l’information n’est pas cryptée puisque tout le monde peut décoder
(Macintosh; U; PPC Mac OS X; fr) cette chaîne (en utilisant un algorithme standard) et que cela
AppleWebKit/418.9.1 (KHTML,
représente donc un risque de sécurité (quiconque intercepte la requête
like Gecko) Safari/419.3
HTTP peut connaître l’identifiant et le mot de passe).
 Connection: keep-alive
 Authorization: Basic - En général on crypte alors la connexion avec le serveur http en
bGFwaW46dG9ydHVl utilisant le protocole SSL afin que le mot de passe ne puisse pas être
 Host: localhost:7777 intercepté.
- Le champ Host indique le nom du serveur web que le client veut

contacter.
81
Transfer Protocol)
1. Réponse HTTP
1. Structure d’une réponse HTTP
 La réponse transmise par le serveur au client comprend :

- Une ligne de statut (status-line) contenant la version de HTTP utilisée et un
code d’état ;
- une ou plusieurs lignes d’en-têtes, chacune comportant un nom et une
valeur ;
- Le corps du document retourné (les données HTML ou binaires par
exemple). Une réponse ne contient pas obligatoirement un corps
(exemple : sil s’agit d’une réponse à une requête HEAD, seule la ligne
de statut et les en-têtes sont retournés.
82
Transfer Protocol)
- - On trouve donc l’en-tête de cet exemple la date (et
 Exemple : l’heure) à laquelle la réponse à été envoyée, le type du
 Exemple : serveur web, la date de dernière modification du fichier

 HTTP/1.1 200 OK demandé, la langue du document, le code MD5 du fichier, la
 Date: Thu, 08 Feb 2007 20:48:45 taille du fichier en octets ainsi que le type MIME du
GMT
document (ici un fichier de type text, dont le sous-type est
 Server: Apache
html) et le jeu de caractères dans lequel il est encodé.
 Last-Modified: Thu, 08 Feb 2007
19:20:26 GMT
 Content-Language: fr
 Content-MD5:
d72f9499b1b0a9c5c611186e0f9837
6e
 Content-Length: 68975
 Content-Type: text/html;
charset=iso-8859-1

83
Transfer Protocol)
- - La dernière ligne d'en-tête est suivie

-
Exemple :
d'un double CRLF marquant le début du corps du document
 retourné (les données HTML ou binaires par exemple).
 <!DOCTYPE html PUBLIC "-
//W3C//DTD XHTML 1.0 - - Le corps correspond exactement au corps du fichier
 Transitional//EN" demandé (ici un fichier html mais ce pourrait également être
 "http://www.w3.org/TR/xhtml1/DTD/x le contenu d’une image ou tout autre type de fichier). C’est
html1-
ce qu’avait demandé le client.
 transitional.dtd">
 <HTML>
 <HEAD>
 <TITLE>Lapin</TITLE>
 </HEAD>
 <BODY>
 Ce matin un lapin a tué un chasseur...
 </BODY>
 </HTML>
84
85
Web Service Sémantique
 Les Services Web tels qu’ils sont conçus et mis en œuvre actuellement ne
sont exploitables que par des utilisateurs humains, qui interviennent à
différentes phases pour la réalisation d’une activité donnée.
 Ils sont dénués de toute sémantique, leur permettant d’être exploités d’une
manière intelligible par la machine.
 Cette insuffisance des services web est prise en charge par l’introduction des
aspects sémantiques dans les services.
 C’est justement l’apport du web service sémantique qui permettra

d’introduire de la sémantique dans les services Web ou un web sémantique
pour les services.
86
 Donc, l’objectif visé par la notion de services web sémantiques est de créer
un Web sémantique de services dont les propriétés, les capacités, les
interfaces et les effets sont décrits de manière non ambiguë et exploitable
par des machines et ce en utilisant les couches techniques.
 La sémantique ainsi exprimée permettra l’automatisation des fonctionnalités

suivantes qui sont nécessaires pour une collaboration inter-services efficace :
 Processus de description et de publication des services ;

 Découverte des services ;
 Sélection des services ;
 Composition des services ;
 Fourniture et administration des services ;
 Négociation des contrats.
87
 Les services web sémantiques se situent à la convergence de deux domaines
importants qui concernent les technologies de l’Internet :
 Web sémantique
 Les services web.
 Le Web sémantique s’intéresse principalement aux informations statiques

disponibles sur le Web et les moyens de les décrire de manière intelligible
pour les machines.
 Les services web, quant à eux, ont pour préoccupation première

l’interopérabilité entre applications via le Web en vue de rendre le Web
plus dynamique.
88
89
 Le Web sémantique
 Le Web sémantique est une initiative du W3C. Son but est de donner un sens
aux informations transitant sur Internet, et ce afin d’automatiser, intégrer,
partager et réutiliser les ressources disponibles sur le Web.
 Le Web sémantique cherche à obtenir une meilleur interopérabilité, et pour

cela, on doit redéfinir les informations pour quelles soient compréhensibles
par les machines dont le but de coopérer entre elles.
 Afin de supprimer les ambiguïtés pouvant intervenir entre les différents

éléments échangés, le Web sémantique s’appuie sur des formalisations
explicites de conceptualisations : ce sont les ontologies.
90
 Le Web sémantique « Les Ontologies »
 Une ontologie, est une description des concepts et des relations qui peuvent
exister entre ces concepts. Ces relations peuvent être sémantiques, de
composition ou d’héritage Elles ont pour but, de remplir deux rôles :
 • Définir ou fournir une sémantique formelle à l’information permettant son

exploitation par un ordinateur ;
 • Définir ou fournir une sémantique du domaine du monde réel

(réutilisabilité et partage) permettant de lier le contenu exploitable par la
machine avec sa signification pour les humains, fondée sur un consensus.
91
92
93
 Technologies du Web sémantique
 la partie transport (qui fait référence aux
URI et à UNICODE).
 Au-dessus apparait la partie métalangage
permettant de définir les langages du
Web sémantique et où trouver les
espaces de nommage (XML et
Namespaces).
 XML Schéma qui est l’équivalent au

format XML d’une DTD (Définition de
Type de Document).
 Ensuite, on retrouve les langages du Web
sémantique (RDF, etc.).
 Le Web sémantique s’appuie sur

plusieurs standards basés sur le langage
XML, parmi lesquels RDF Resource
Description Framework, et OWL Web
Ontology Language.
94
 Le Web sémantique « XML »
Un document XML est représenté physiquement sous la forme d'un fichier texte
structuré en éléments, à l'aide de balises éventuellement imbriquées
95
 Le Web sémantique « RDF »
 RDF est un langage formel qui permet d’affirmer des relations entre des
«ressources». Il sera utilisé pour annoter des ressources définies par des
langages structurés XML. Un document RDF est un ensemble de triplets de
la forme:
Les éléments de ces triplets peuvent être des URIs, des littéraux ou des variables.
Objet
Prédicat
Mouhamed Auteur_de La guerre des

Mondes
Sujet
96
 Le Web sémantique « RDFs »
 RDFS (pour RDF Schéma) a pour but d’étendre le langage RDF en

décrivant plus précisément les ressources utilisées pour étiqueter les
graphes.
 Pour cela, il fournit un mécanisme permettant de spécifier les classes dont

les ressources seront des instances, comme les propriétés RDFS s’écrit
toujours à l’aide de triplets RDF, en définissant la sémantique de nouveaux
mots clés.
 RDF, langage dédié à l’expression d’assertions sur les relations entre objets,
s’est heurté à la nécessité de définir les propriétés des classes dont ces objets
sont instances. Cependant, l’extension à RDFS ne fournit que des
mécanismes primitifs pour spécifier ces classes.
97
 Le Web sémantique « OWL»
 OWL est, tout comme RDF, un langage XML profitant de l'universalité
syntaxique de XML. Fondé sur la syntaxe de RDF/XML, OWL offre un
moyen d'écrire des ontologies web.
 OWL se différencie du couple RDF/RDFS en ceci que, le langage OWL,
quant à lui, est dédié aux définitions de classes et de types de propriétés, et
donc à la définition d’ontologies
 OWL intègre, en plus, des outils de comparaison des propriétés et des

classes : identité, équivalence, contraire, cardinalité, symétrie, transitivité,
disjonction, etc.
 Ainsi, OWL offre aux machines une plus grande capacité d'interprétation du
contenu web que RDF et RDFS, grâce à un vocabulaire plus large et à une
vraie sémantique formelle.
98
Le Web sémantique
99
Le Web sémantique
100
 L’ajout de la couche sémantique
 L’infrastructure de base autour des standards SOAP, WSDL, UDDI est suffisante pour
mettre en place des composants interopérables et intégrables mais insuffisante pour rendre
automatique et efficace plusieurs tâches liées au cycle de vie des services web, par
exemple : la composition et aussi la découverte des services requis.
 En particulier, WSDL fournit une description concrète mais de bas niveau d’un service
Web, en termes de sa localisation, des opérations disponibles et des messages associés
ainsi que des types de données et formats de leurs paramètres d’E/S.
 Ces descriptions sont insuffisantes pour qu’un agent logiciel puisse interpréter la
signification réelle des opérations WSDL.
 Par conséquent, les technologies du web sémantique telles que les ontologies peuvent
jouer un rôle prépondérant pour permettre d’expliciter la sémantique des services en
facilitant ainsi leur utilisation automatique.
 Une des principales approches qui avaient conduit le développement des cadres
sémantiques des services Web, l’approche OWL-S (Ontology Web Language for Web
Service)
101
 L’ajout de la couche sémantique (OWL-S)
 OWL-S (OWL for Web-Services) est une ontologie qui est basée sur OWL,
Elle ajoute une notion de service. Les anciennes versions d’OWL-S
s’appelaient DAML-S, qui lui-même est basé sur DAML+OIL.
 OWL-S a pour but de permettre aux utilisateurs humains et agents logiciels
de réaliser quatre tâches :
 • Découverte automatique de services Web ;
 • Invocation automatique de services Web ;
 • Composition et inter opération de services Web ;
 • Moniteur d’exécution automatique de services Web (surveillance des
ressources) .
 OWL-S a été développé pour fournir des descriptions de services, avec des
informations sémantiques qui permettent la description de services en
utilisant le formalisme d’OWL.
102
Les différentes ontologies qui caractérisent OWL-S.
103
 Il y a donc trois sous ontologies :
 Le Profile : fournit une description générale du Web Service pour qu'il
puisse être publié et partagé afin de faciliter sa découverte.
 Les profils peuvent inclure non seulement les propriétés fonctionnelles

(entrées, sorties, conditions préalables, et résultats) mais aussi les propriétés
non fonctionnelles (nom de service, description des textes, information de
contact, catégorie de service, et paramètres additionnels de service).
 Cette section est utilisée à la fois par les fournisseurs pour publier leurs
services et par les clients pour spécifier leurs besoins.
 Par conséquent, elle constitue l’information utile à la découverte et à la

composition se services.
104
 Le Processus (ServiceModel) : qui représente le travail du service en terme
de processus internes; c à d décrit comment un service accomplit ses tâches.
 Il inclut des informations sur :
 les entrées, les sorties (contenant une spécification des conditions dans
lesquelles les diverses sorties ont lieu),
 les conditions préalables (circonstances qui doivent se tenir avant qu'un

service puisse être employé),
 les résultats (changements provoqués par un service). Le modèle de

processus a trois types: les processus composés, atomiques, et simples.
105
 La Base (Grounding) : Le "ServiceGrounding" établit une correspondance
entre une spécification abstraite et une spécification concrète.
106
107
Architecture Orientée Evènements
Exemple SOA
 Service 1: Planicateur, un outil de planification de routes qui détermine la
route et le remplissage optimal pour chaque camion en fonction des
livraisons à effectuer.
 Cet outil peut être vu simplement comme une boîte noire qui reçoit en entrée
la liste des camions (et leur contenance) et des paquets (volume, lieu de
prise en charge, lieu de livraison, priorité) et renvoie en sortie un planning
pour la journée et, le cas échéant, la liste des camions inutilisés ou la liste
des paquets qui n’ont pas pu être inclus ;
 Service 2: Commandes, un outil de gestion de clients qui s’occupe

d’enregistrer les clients et leurs commandes ;
 Service 3: Flotte, un outil de gestion de flotte utilisé dans leurs garages

pour savoir quels camions sont disponibles, quelle est leur capacité, etc.
108
109
 Supposons que, suite à l’adoption de cette architecture, un outil de gestion de

ressources humaines, que nous appellerons RH est ajouté
 Dès lors, la disponibilité des chauffeurs devient une information disponible, ce

qui permet de la prendre en compte dans la gestion du planning.
 On peut aussi vouloir savoir quel chauffeur a conduit quel camion, ce qui justifie
également une jonction entre Flotte et RH.
 Pour chacune de ces interactions, il faudra que le composant s’intégrant avec

RH soit modifie pour être capable de communiquer avec ce dernier.
 Ceci impose de savoir à quelles requêtes RH sait répondre, et comment il y

répond.
110
111
 Pour qu’un composant ajouté puisse interagir avec tous les composants existants, il faut le
relier à ces derniers. Ainsi, pour le composant n , il faut mettre au point n − 1 connecteurs.
 Le code d’un connecteur dépendant des deux composants qu’il relie, aucun de ces
connecteurs n’est réutilisable.
 Une grande quantité de travail est donc nécessaire pour pouvoir intégrer un nouveau
composant.
 De plus, beaucoup d’interdépendances se créent. Chaque outil dépend d’une interaction

directe avec les autres outils pour fonctionner, et cette interaction est décrite directement
dans le code.
 Si un outil modifie la manière dont il expose ses services, ce changement devra être
répercuté sur tous les autres outils qui en ont l’usage.
 Cette duplication de code se traduit par un surcoût élevé en terme de maintenance.

112
Inconvénients de SOA
 Le défaut le plus fréquemment attribué à l’architecture orientée services est
de ne pas permettre réellement de découpler les composants.
 L’objectif central de SOA était d'avoir un couplage faible entre les services :
malheureusement, le fonctionnement par requête-réponse impose à chaque
service de définir de manière rigide les requêtes auxquelles il sait répondre
et quelles réponses il enverra.
 Il y a donc, malgré tout, une forte dépendance entre les services en termes
de préconception
113
 Inconvénients de SOA
 En SOA , un service bien identifié s'adresse à un autre service bien identifié
pour lui demander une information. En réponse, son correspondant lui
renvoie l'information (ou un motif de refus, qui est en soi une information).
 Le principe de décomposer en services distincts les différentes composantes

d'une application permet, en SOA, de découpler fortement ces éléments et
de limiter la connaissance qu'ils doivent avoir l'un de l'autre.
 Temps réel
114
Définition de EDA
 L'EDA est une architecture logicielle reposant sur le principe d'un découpage de
l'application en plusieurs parties, interagissant entre elles uniquement par la diffusion
d'évènements en temps réel
 On peut donc voir un EDA exactement comme le système nerveux. Pour être efficace, il
doit détecter correctement les évènements et les transmettre de manière fiable aux
composants concernés.
 De plus, pour pouvoir y réagir intelligemment, il aura besoin d'être capable de faire
efficacement les liens entre les différents évènements reçus :
 Le composant chargé de cette tâche sera appelé processeur d'évènements.
115
116
117
 Avantages EDA
 l'EDA permet de s'adapter plus efficacement à l'évolution des besoins
 l'EDA propose de repenser les interactions entre les différents éléments qui le composent.
 En EDA, les seuls messages envoyés sont des évènements et ils sont diffusés, c'est à dire qu'ils
sont envoyés sans destinataire précis, donc sans qu'il y ait de nécessité pour la source de savoir
à qui ils s'adressent.
 Entre autres, cela signifie que les différents composants ne conserveront plus d'informations
sur leur état ni sur celui du système
 Toutes les informations d'état doivent alors être contenues dans les évènements diffusés.
 Par ailleurs, un autre aspect à relever est la nécessité que l'ensemble du système fonctionne en
temps-réel (ou assimilé).
 l'objectif d'une architecture EDA est de savoir ce qui ce passe dans le présent afin de pouvoir y
réagir
118
 Avantages EDA « Analyse systémique »
 L’architecture proposée par l’EDA est modulaire et découplée ; les différents composants
interagissent entre eux simplement par la diffusion d’évènnements.
 La caractéristique descomposants d'un système EDA est d'être sans état, c'est-à-dire dénués
d'informations sur l'état global du système.
 L'ensemble des informations d'état sont contenues dans les évènements, qui représentent le
passage d'un état vers un autre. Ceci permet donc d'adopter une approche systémique : au lieu
de devoir définir un ensemble de processus métier,
 Il est possible de s'intéresser simplement à l'état global tel que défini à un instant donné par
l'ensemble des évènements apparus.
 Cette approche est particulièrement utile lorsque le système, trop complexe, ne peut être
modélisé simplement comme un ensemble de processus où chacun de ces processus est
constitué d'une séquence d'actions.
 L'approche systémique permet de prendre en compte l'ensemble des variables du système
plutôt qu'un sous-ensemble restreint de celles-ci : en effet, chaque évènement est diffusé sans a
priori sur l'usage qui va en être fait.
119
 Avantages EDA « Agilité»
 l'un des avantages majeurs de l'EDA est de
permettre un couplage extrêmement faible entre
les différents composants.
 Ce découplage est rendu obligatoire par la

communication par évènement,
 Cette architecture permet de mieux faire évoluer

le système, on peut toucher à un composant du
système sans que cela n'ait d'impact majeur sur
les autres.
 On quitte les aspects techniques et on constate

que la facilité d'évolution et de maintenance rend
le système agile,
 C'est à dire capable d'être adapté rapidement et

efficacement aux conditions changeantes
120
 Avantages EDA «Réutilisabilité»
 L'EDA facilite la réutilisabilité en incitant les développeurs à concevoir ces

composants de manière isolée les uns des autres, encore plus qu'avec une
architecture SOA.
 En effet, tout ce qu'un agent doit savoir est ce qu'il veut recevoir comme évènement
et quelle information il désire diffuser.
 En quelque sorte, les composants n'ayant pas d'interface de programmation publique,

ils n'ont pas à rendre des comptes aux autres composants et n'ont pas besoin de
savoir comment s'interfacer avec ces derniers.
121
 Composants de L’EDA
 L’architecture EDA se composait de différents éléments :

 Des évènements, bien sûr.
 Leur production se fera au moyen de générateurs d'évènements.
 Ils seront ensuite diffusés à tous les éléments concernés.
 Cette diffusion se fera au moyen d'un messaging backbone (ou event collector, ou
encore event channel),
 la puissance de l'EDA réside dans la capacité à pouvoir traiter des évènements et y
réagir intelligemment, il faut pour cela un ou plusieurs event processors.
 Les agents sont les éléments qui vont réellement effectuer le travail dans
l’architecture
122
 Évènement
 On peut le voir comme quoi que ce soit de notable survenant à l'intérieur ou à l'extérieur du
système.
 Plus formellement, un évènement sera défini comme un changement d'état, c'est à dire une
variation suffisamment significative des paramètres définissant l'état système.
 N'importe quelle donnée apportant une information inédite peut donc être considérée comme
un évènement.
 Cette définition permet d'inclure n'importe quelle occurrence ou non-occurrence d'une action,
n'importe quelle variation d'une valeur …….
123
 Diffuseur de messages
 L'efficacité d'une EDA repose entièrement sur la bonne diffusion des évènements. Le
composant utilisé pour gérer cette tâche est appelé messaging backbone.
 Cet élément crucial et essentiel de l'architecture EDA doit pouvoir efficacement transmettre un
flux important d'informations (on veut pouvoir gérer de nombreux évènements, et chaque
évènement doit contenir l'ensemble de l'état du processus associé) depuis et vers les différents
services.
 Il doit être omniprésent, afin de recueillir le plus d'informations possibles : au plus le système
reçoit d'évènements, au mieux il pourra agir.
 De plus, il est recommandé d'éviter l'écueil d'un backbone trop centralisé. Une structure en
réseau décentralisé est à préférer..
 Il recommande aussi de minimiser les services offerts par le gestionnaire de messages. Tout ce
qui n'est pas essentiel peut être isolé dans un service séparé, qui sera alors plus facilement
activable, désactivable ou remplaçable.
124
 Agents
 Reliés au messaging backbone, les agents sont les éléments qui vont réellement e_ectuer le
travail dans l'architecture.
 On considère trois types d'agents : ceux qui produisent, ceux qui consomment et ceux qui
transforment les évènements sont présentés ici de manière distincte.
 En pratique, un agent sera souvent une combinaison de ces éléments, tour à tour consommateur
et producteur d'évènements. Ils correspondent aux services d'une architecture SOA.
125
 Processeur d'évènements
 C'est ici que se situe toute la puissance et l'intérêt d'une solution EDA : le traitement
des évènements.
 Une distinction est fréquemment faite entre trois types de traitements :
 le simple event processing reçoit un seul évènement notable et réagit à un
changement de condition précis.
 l'Event Stream Processing (ESP), quant à lui, réagit à plusieurs évènements, mais
travaille sur un (et un seul) flux de données.
 Le Complex Event Processing (CEP), enfin, consiste à corréler les évènements entre
eux (de manière causale, temporelle ou spatiale).
 À partir d'un ensemble d'évènements pouvant venir de plusieurs flux, on tente
d'inférer l'occurrence d'un évènement complexe. Ceci implique notamment la
reconnaissance de motifs.
126
127
128
129

Présentation SOA

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Présentation SOA

Transféré par

Droits d'auteur :

Formats disponibles

Dr.

Dehimi Nour El Houda

 Au départ, le seul moyen de réutiliser du code était de le recopier dans notre

 Dans ce sens plusieurs paradigme de programmation ont été proposés

 Chaque paradigme de programmation propose un modèle de description

 la réduction de la taille du code source

 localité rapide des modifications  une amélioration de la maintenabilité

 une façon plus simple de suivre l'exécution du programme

 la programmation procédurale permet les « effets de bord », c'est-à-dire la

 Simula (1966) regroupe données et procédures.

 Simula I (1972) formalise les concepts d'objet et de classe. Un

 Smalltalk (1972) : généralisation de la notion d'objet.

 C++ (1983) : Extension du C s'inspirant de Simula

 Pas de vue globale de l’architecture d’une application

 Un composant = un ensemble d’objets + des ports (Ports offerts, Ports

 Assemblage de composant = Liaison entre

 Les limites de la POC

 Les applications construites à base de cette architecture sont donc

 Ils présentent une vision particulière de comment développer des logiciels.

 Analogie avec l’approche orientée objet et la programmation structurée

 Ces services offrent une vue logique des traitements et données

 Boite noire (séparation interface/implémentation).

 Neutralité vis-à-vis des protocoles de transport.

 Faiblement couplé (indépendant des autres services).

 La définition du service est explicite :

 Les services sont autonomes :

 Les clients et les services ne partagent que des contrats :

 La compatibilité est basée sur les règles :

 Décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées services.

 Mise en place d’une SOA a un coût élevé à la fois financier et humain :

 Difficulté de migrer d’une architecture monolithique vers une architecture SOA

 L’architecture SOA offre un avantage évident qui est l'interopérabilité. Les

 Ces fonctionnalités peuvent être découvertes, invoquées et composées pour

 Le fournisseur de service (serveur) : celui qui crée le

 Etape 1 : définition et description de service

 Etape 2 : publication de service

 Etape 3 : recherche du service

 Etape 4 : enregistrement au service web

 Etape 5 : mise en œuvre du service

 Sa syntaxe d’utilisation est fondée sur XML et ses commandes sont

 Il est indépendant du langage d’implémentation des applications client et

 Fonctionnement côté client :

 Un message SOAP est un document

 Une enveloppe : élément indispensable

 L’enveloppe SOAP définit l’espace de nom (namespace : URI permettant

 Cet espace de nom est standard et permet de différencier les éléments du

 L’enveloppe SOAP est constituée d’un en-tête facultatif (SOAP header) et

 L’en-tête peut utiliser les attributs mustUnderstand et/ou SOAP actor

 Le destinataire d'une entrée d’en-tête est défini par l'attribut d'acteur de

 Le corps SOAP contient l’information destinée au receveur. Il doit fournir

 Il doit aussi, fournir l’espace de nom correspondant au nom du service.

 Informations sur toutes les fonctions disponibles publiquement.

 La description concrète (La description de l’implémentation du

 Message: l’abstraction décrivant les données échangées entre services Web.

 Operation: l’abstraction décrivant une action implémentée par service Web.

 Liaison (binding): un protocole concret d’accès à un port et un format de spécification des

 - Il n'existe aucun type de fichier : seul le texte (text/plain) est géré ;

 - La notion d'en-tête HTTP n'est pas définie ;

 - Le serveur ferme la connexion pour signaler la fin de la réponse.

 Une ligne de requête (request-line) contenant la méthode utilisée, l’URL du

 Une ou plusieurs lignes d'en-têtes, chacune comportant un nom et une

- Le champ Host indique le nom du serveur web que le client veut

 La réponse transmise par le serveur au client comprend :

 Exemple : serveur web, la date de dernière modiﬁcation du ﬁchier