Support de Cours: Ervice Riented Rchitecture

Support de cours
SOA
SERVICE ORIENTED ARCHITECTURE
Options IQL et TI
Filière Génie Informatique – EMI
Préparé par :
Pr. Fatima-Zahra BELOUADHA
Objectifs du cours
  Comprendre le concept service et les principes de

l’architecture SOA
  Comprendre l’intérêt de l’architecture SOA
  Comprendre le concept service Web et apprendre

à utiliser ou interpréter les standards des services
Web
  Maîtriser le développement de services Web par
l’utilisation de l’API JAX-WS
Fatima-Zahra BELOUADHA. SOA. 3ème année. Options IQL et TI. Filière Génie Informatique. 1
  Le concept Service
Plan
  L’architecture SOA
  Le concept Service Web
  Les standards des services Web
  L’API JAX-Web
Ch1. Le concept Service
  Evolution des paradigmes de développement
  Qu’est ce qu’un service?
  Orchestration des services
  Types de services
  Propriétés du service
Evolution des paradigmes de
développement
  La conception d’un programme informatique s’effectue
conformément à un paradigme de développement (PD)
  Un PD définit un concept pour représenter le monde et des

techniques pour traiter ce concept
  Différents PD ont vu le jour et ont évolué du binaire, à

différents modèles de programmation puis à Service
l’architecture SOA Composant

þ  SOA

þ  Brique composable þ  …

þ  Groupe d’interfaces
Objet þ  Gros grain autonome
+s’autodécrivant
þ  Classe þ  Interac-on d’applica-on
Procédural þ  Encapsula-on
Binaire þ  Propriétés NF…
þ  Fonc-ons þ  Héritage…
01001 þ  Modularité
11001
Concept Service
  Composant logiciel qui exécute une action pour le

compte d’un client
  Il traduit le niveau logique d’accès aux traitements,

plutôt que le niveau physique d’implémentation (EJB,
Servlet…)
Définition du Service
  Composant logiciel :
-  Mutualisé (partagé puisqu’il est réutilisable et interopérable)

-  Référencé dans un annuaire (où il est identifié)
-  Normalisé (toutes ses fonctions sont appelés de la même façon
via des paramètres, conformément à un contrat)
-  Décrit par une interface d’appel (par un langage indépendant
des technologies)
-  Communicant avec le client par le biais de messages (E/S)
-  Neutre (son utilisation est indépendante de son implémentation
ou évolution tant que le contrat est respecté)
-  Couplage faible : interface isole le client du service
-  Déployé (physiquement) sur un serveur
Orchestration des services
  Les services peuvent être composés (agrégés) dans le but
de réaliser un processus donné
  L’orchestration leur permet de communiquer sans avoir à
se connaître pour préserver leur couplage lâche (leur
indépendance)
  Un moteur d’orchestration se charge d’appeler les
services selon l’enchaînement désiré
Types de services
  Applicatif
  Fonctionnel
  Entité (CRUD) : Create, Read, Update and Delete
  Transverse (Infrastructure)
  Host
Service Applicatif
  Il traduit la logique applicative d’une application,
exprimée par les uses cases ou les processus métier
-  C’est un service de la couche applicative, qui n’est en général
utilisé que dans le contexte de l’application où il a été créé
  Il peut être modélisé par :

-  UML : Uses cases et Diagramme d’activité
-  MERISE : Modèle Organisationnel de Traitements
-  BPMN (Business Process Modeling Notation)
  Ses opérations peuvent être déclenchées selon que des

préconditions sont vérifiées ou non
  Ses résultats peuvent être émises selon que des
postconditions sont vérifiées ou non
  Il est context-aware (son comportement s’adapte aux
besoins des clients et au contexte d’exécution)
Service CRUD, Transverse et Host
  CRUD : service élémentaire permettant de créer,

rechercher, lire, màj ou exporter vers un format (pdf,
excel…), un objet métier
  Transverse (Infrastructure) : exécute un traitement

métier spécifique (ex : services de log, gestion du
Contexte Utilisateur…)
  Host : permet aux applications distribuées d’utiliser

une application Mainframe du Host de l’entreprise
-  Il peut être encapsulé dans et rendu accessible par
des logiciels d’infrastructure destinés à la Gestion
ou Contrôle d’information (ex : IMS, CICS…)
Service fonctionnel
  C’est un service de la couche Services, réutilisable dans
des contextes variables
  Il exécute un traitement métier (fonction), et peut être

invoqué par différent services applicatifs
  Il invoque des services CRUD et/ou Transverses pour

pouvoir manipuler des objets métiers
  Il peut aussi invoquer des services plus élémentaires ou

externes (partenaires) pour assurer l’orchestration (gérer
leur enchaînement de manière à réaliser un processus qui
apporte une valeur ajoutée)
  Il peut aussi servir à la gestion de la sécurité, des règles

métiers, etc.
Propriétés des services
  Réutilisables et possèdent des contrats standardisés
  Communiquent par messages à travers des interfaces
adressables
  Abstraits et prédictibles
  Modulaires et de large granularité
  Autonomes et sans état (stateless)

  Moyens pour assurer une haute Interopérabilité
  Faiblement Couplés
  Découvrables (dynamiquement)
  Composables
Réutilisabilité par contrat
  Le service est réutilisable conformément à un contrat entre
le fournisseur et le consommateur
  Le contrat décrit :
-  La syntaxe du service : opération, input, output, format, protocole…
-  La sémantique de son utilisation: pré-conditions, post-conditions…
-  Sa QOS : temps de réponse attendu, temps de reprise après
interruption…
  Le contrat est généralement décrit au moyen du standard

WSDL
  Plusieurs contrats peuvent être définis pour répondre aux
besoins différents des consommateurs (ex : service avec
haute disponibilité/disponibilité normale)
  Le contrat est utilisé au design-time (génération de code) et
au run-time (contrôle du respect du contrat)
Interface adressable et
communication par message
  Chaque consommateur peut invoquer un service via son

adresse dans le réseau à n’importe quel moment
-  Le consommateur peut accéder localement au service pour
augmenter la performance, s’ils sont hébergés dans la même
machine
  Les services communiquent uniquement par messages

-  Appels via le réseau vu que les services sont distribués en SOA
  Pour augmenter la performance, les concepteurs doivent

penser à augmenter la granularité des interfaces de
services pour diminuer le nombre d’appels réseau
Abstraction et Prédictibilité
  Le service fonctionne en « boîte noire »

-  Seul le contrat du service (informations nécessaires pour
l’invocation) est exposé au consommateur du service
-  le fonctionnement interne du service (sa logique métier et son

implémentation) ne sont pas visibles
  Il est Prédictible
-  Son comportement et sa réponse lors de la réception d’une
requête ne varient pas
Large granularité et modularité
  Large granularité : Le service est un gros grain qui

regroupe un ensemble d’interfaces cohérentes se
rapportant à un même module fonctionnel
-  Principe à respecter lors de la conception
  Modularité : Il peut être déployé de façon atomique

bien avant le développement ou déploiement
d’applications consommatrices
-  Principe différent du principe du paradigme OO où un
programme OO est une unité indivisible
Autonomie et statelessness
  Autonomie :
-  Le service est Indépendant des services externes :
son comportement est indépendant du contexte
fonctionnel et technique dans lequel il a été invoqué
  Statelessness : Il est sans état (stateless) càd il

n’intègre pas la gestion de contexte (puisqu’il est
autonome)
-  But : Ne pas compliquer la maintenance, préserver la
réutilisabilité (Indépendance d’un enchaînement
particulier) et assurer la performance (minimiser la
consommation de ressources systèmes, utilisées
pour le stockage d’états)
Interopérabilité
  Possibilité de communiquer avec un système
hétérogène
  Le service précise un type de connecteur (càd protocole

et format de données) que ses clients potentiels doivent
utiliser pour pouvoir invoquer l’interface qu’il fournit
  Une spécification de médiation permettra de réaliser le

mapping au cas où le client adopte un format et types de
données hétérogènes
-  Mapping entre deux jeux de caractères comme l'ASCII et
EBCDIC, et mapping de types de données
-  Exemples de spécification de médiation : Les API JAX-RPC et
JAXM pour le mapping des types de données Java aux types de
données SOAP et XML dans le cas d’un service Web
Couplage faible (lâche)
  Dépendance faible entre le consommateur et le

service
-  Dépendance du contrat et non pas de l’implémentation
-  Echange à travers des messages
-  Orchestration assure l’indépendance des services vu
qu’elle leur permet de communiquer pour réaliser un
processus, sans avoir à se connaître
  Avantage : Maintenance facile
-  un changement dans le service suscite peu de changements
dans ses consommateurs (juste ceux relatifs au respect du
contrat)
Découvrabilité
  Il est publié par le fournisseur dans un annuaire : décrit

par un ensemble de métadonnées qui permettent de
l’identifier et qu’il est possible de màj
  Le consommateur peut chercher un service selon un

ensemble de critères à partir de l’annuaire :
-  L’annuaire renvoie au consommateur la liste des services
(adresses, frais…) qui répondent à sa requête
-  Tous les arguments nécessaires à l’exécution du service

sélectionné (opérations, paramètres…) sont accessibles à partir
de son contrat
Composabilité
  Un service peut participer à des compositions

de services
-  Un ensemble de services peuvent être composés à
travers leur orchestration pour répondre à un besoin
complexe
  Avantages :
-  Apport de valeur ajoutée (répondre à un nouveau
besoin complexe)
-  Augmentation de la modularité : vu qu’un service
complexe peut être décomposé en services simples
pouvant être déployés chacun de façon atomique
CH2. Architecture SOA
  Motivations et Enjeux
  Définition et Fondamentaux
  Couches et Méthodes de conception
  Intégration et ESB
  SOA Vs Architectures classiques
  SOA et urbanisation
Architecture distribuée
  Architecture où le traitement des données des applications
est distribué sur plusieurs machines en réseau
-  Exemples : Architectures client-serveur, N-Tiers, Web
  Limites dues à leurs technologies de base :

–  Utilisation de composants provenant d’un même constructeur,
–  Utilisation d’un langage de programmation spécifique,
–  Complexité des technologies utilisées
–  Incapacité de répondre au besoin d’interopérabilité
–  Evolution des AD vers SOA
SOA et Interopérabilité
  L’interopérabilité exprime le besoin d’échanger des
données (d’1 facture par ex) entre 2 systèmes distribués
et éventuellement hétérogènes pour un besoin
d’intégration
  SOA, proposée par Gartner Group (2003-2008), se prête

comme solution au problème d’interopérabilité, en
répondant aux questions :
-  Quel transport de communication (TCP/IP ? quelle version?) ?
-  Quel protocole applicatif (HTTP, FTP, SFTP...) ?
-  Quel type d’encodage de données (ASN.1, MIME,
BASE-64...) ?
-  Quel est le format de données à adopter ? (bureautique,
structuré avec EDI ou XML)
-  …
Enjeux de la SOA
  Elle est devenue une solution incontournable pour
gagner d’autres enjeux :
-  Métier : Produire des SI ouverts (à la fois interopérables +
évolutifs)
Ø  Proposer une solution utilisant des standards et
assurant un couplage faible
-  Métier : Réduire le Time to Market (le temps entre le besoin
et la mise en production)
Ø  Proposer des moyens pour réduire le temps du cycle
projet
-  Technique : Fédérer les technologies
Ø  Proposer des moyens pour rendre les solutions
techniques réutilisables
-  Financier : Maîtriser les coûts et les délais
Ø  Coût important mais retour sur investissement à long
terme
Architecture SOA
  Architecture orientée service (Service Oriented Architecture)
  Style d’architecture distribuée qui permet de fournir ou
consommer un processus métier en tant que service
  Offre des services réutilisables et interopérables via des
interfaces standards (construites autour de XML)
  Plusieurs partenaires peuvent

communiquer et échanger des
données dans le contexte de
SOA indépendamment des
Plateformes et langages
Technologies d’implémentation de SOA
  L’architecture SOA peut être implémentée par différentes
Technologies :
-  CORBA,
-  DCOM (Microsoft),
-  APIs : RMI ou JMS (combinées aux Interfaces Java),
-  Services Web (protocole SOAP)
  Les Services Web demeurent la technologie émergente

pour l’implémentation de l’architecture SOA puisqu’ils
sont :
-  multiplateormes,
-  multilangages,
-  relativement faciles à implémenter
-  Disposent de standards : WSDL, BPEL…
Paradigme SOA
  Fournisseur de service :
-  Fournit un service accessible via une adresse
-  publie son contrat dans le registre de services
-  et exécute les requêtes des consommateurs (un Proxy et un cache peuvent être
utilisés du côté consommateur pour délocaliser le traitement et réduire le nombre
d’appels réseau)
  Consommateur de service : application, service…
-  Cherche le service dans le registre (son adresse)
-  Se lie dynamiquement au service (binding)
-  Invoque le service via une requête conforme au contrat
  Registre de services : Annuaire des contrats de services
-  Le Contrat décrit le format d’échange (format des requête/réponse, les pré et post
conditions du service et sa QoS, ex: temps de réponse)
-  Le contrat est renouvelable par demande de nouveau bail à partir du registre
Annuaire et Référentiel de services
  Annuaire (Registry) : permet de publier les

métadonnées des services (ex : UDDI, ebXml…)
  Référentiel (Repository) : stocke les définitions

des services de l’entreprise, les dépendances entre
services et gère la localisation et le routage
  L’annuaire et le référentiel peuvent être fusionné en

1 seul outil (ex : WSSR d’IBM).
Endpoints et Binding
  Le Endpoint est le port ou point d’accès au service
-  Il est décrit par un triplet : l’adresse du service, un binding et la
liste des opérations du service accessibles à partir de ce endpoint
  Le Binding indique le modèle à utiliser pour communiquer

avec le service
-  Protocole de transport : http, https (sécurité SSL/TLS), Sockets
TCP/IP (adaptés au transfert de données volumineuses : son ou
vidéo), Canaux nommés (utilisés lorsque les clients et le service
sont sur la même machine), MSMQ (File d’attente de message
pour le transfert de messages fiables et persistants)
-  Format des messages : format des données à utiliser pour
formuler les requêtes du client et à considérer pour interpréter les
réponses du serveur (format textuel basé sur XML ou binaire pour
transmettre des flux volumineux : vidéo…)
-  Il peut aussi définir les Paramètres de sécurité (cryptographie…) et
la manière de Gérer les Transactions par le service…
Le modèle en Couches de la SOA (1/3)
  Présentation : renseigne les types de Clients (services
Web, servlets ou pages JSP) des services
  Orchestration : assure la coordination des services

composés et gère leur enchaînements
-  Services réutilisés pour organiser un processus métier, un
workflow ou un flux de services
  Services : héberge et organise les services par

domaine métier
  Composants : héberge les composants utilisés par les

services pour assurer une fonctionnalité métier
  OS/Données : représente les sources de données
(SGBD, CICS…), les EAI ou ERP déployés par
l’entreprise
  Intégration : comprend des services techniques
-  Gestion de configuration
-  Gestion des traces
-  Gestion des erreurs et des exceptions
-  Moteur de transformation des flux (ex : XML/PDF ou XML/HTML)
-  Gestion de batchs
-  Utilitaires (parsing XML, lecture de fichiers…)
  QOS (souvent intégrée dans un ESB) : assure, contrôle et

gère la QoS en termes de sécurité, performance
disponibilité
-  Sécurité : contrôle l’accès aux couches et leurs composants
-  Management : assure l’administration, la configuration et la
gestion des applications et serveurs d’applications
-  Monitoring : contrôle et surveille les processus
Exemple e-store : couches
AccountController CartController
Default
SignOut SignIn Search Category Items Item Shopping Help Error
Details Cart
Presentation
Layer Check Order Order Order
My Edit Create
out Billing Shipping Process
Account Account Account
Account Profile Product Item Inventory Cart OrderInsert OrderRead

Business
Logic
Layer
IAccount IProfile IProduct IItem IInventory IOrder

Data
Access
Layer
Exemple e-store : Domaines
Default
SignOut SignIn Search Category Items Item Shopping Help Error
Details Cart
Presentation
Layer Check Order Order Order
My Edit Create
out Billing Shipping Process
Account Account Account
Account Profile Product Item Inventory Cart OrderInsert OrderRead

Business
Logic
Layer
1.0 1.0 10.0 5.1 1.0

1.1 2.0 11.2 5.2 6.0
1.2 3.5 11.5 5.3 7.0
IAccount IProfile IProduct IItem IInventory IOrder
Data
Access
Layer
Customer Catalog Inventory Shopping Billing
Exemple e-store : Services
Presentation
Layer
Business
Logic
Layer
Service Manage Show Make

Shop Bill
Layer Customer Catalog Inventory
Mise en œuvre de la SOA
  SOMA
-  Service Oriented Modeling and architecture
-  Proposée par IBM pour l’analyse, conception,
implémentation et développement d’architecture SOA
  Praxeme
-  Unilog Management et Orchestra Networks
-  Initiée par la société SAGEM et déposé par le
Praxeme Institute pour couvrir tous les aspects de
l'entreprise, de la stratégie au déploiement
Modélisation des services et Outils
d’Implémentation pour la SOA
  Modélisation :
-  UML 2.0 (version qui intègre des composants logiciels)
  Implémentation :
-  JEE à travers l’utilisation de JEE beans - EJB for Web apps et du
serveur d’application JEE (conteneur moins lourd que J2EE)
-  Framework Spring à travers l’utilisation des spring Beans et du
conteneur léger tomcat (serveur Web)
-  IBM WebSphere pack for SCA, Apache Tuscany SCA, FraSCati
(open source)… qui implémentent le modèle SCA (Service
Component Architecture)
-  Modèle proposé par IBM/Oracle/TIBCO pour la composition
d’applications selon les principes de SOA
-  OpenCCM qui implémente le modèle CCM (CORBA Component
Model)‫‏‬, modèle de composant CORBA
ESB (Enterprise Service Bus)
  Solution d’intégration qui reprend les principes

de l’EAI en se basant sur des standards : XML,
SOAP, WSDL, WS-*, UDDI, BPEL, JSR Java
(J2CA+JBI) pour intégrer des applications dans le
cadre d’une architecture SOA
Archi. point à point Archi. Basée sur un EAI
Enterprise Application Integration
Intérêt de l’ESB
  Ilimplémente une architecture distribuée et fournit
des services de transformation de données,
routage, orchestration de services, sécurité,
transaction et interopérabilité
  Ilpermet en fait aux applications hétérogènes de
communiquer de façon simple, mais standardisée
à la différence des EAI basés sur une logique
d’intégration propriétaire
  Ilest donc recommandé pour éviter le couplage
fort entre fournisseur et consommateur, mais il
n’est pas obligatoire
  Il n’est pas, mais intègre un moteur d’orchestration
Connectivité de l’ESB
  L’ESB est connecté aux applications par des
connecteurs d’adaptation de formats et spécificités
-  Connecteurs techniques vers des formats d’échange :
fichiers CSV, formats XML, RMI, RPC…
-  Connecteurs métiers pour intégrer des progiciels
-  Connecteurs propriétaires conformes à J2CA
Solutions ESB
  IBM Websphere ESB

  Celtix hosted on ObjectWeb/IONA Technologies
  OpenESB (java.net)
  Mule (codehaus.org)
  Sonic ESB
  EBM Web Sourcing Distributed Petals Bus
(consortium OW2)
Autres formes d’implémentation d’un
ESB
  Les services assurés par l’ESB dépendent de

l’implémentation choisie
-  Intergiciels de type MOM (Message Oriented
Middleware)
-  Intergiciels de type Bus (ex : CORBA)
-  Intergiciels de type EAI (Message Broker avec
connecteurs propriétaires liés au moteur d’intégration)
-  Routeurs services Web (ex : WebSphere Web
Services Gateway)
SOA Vs Client/serveur
Architecture Client/ SOA
Serveur
Intra-entreprise Inter_entreprises
Limitée à un ensemble de Indépendante du langage
langages de programmation de programmation
Procédurale, OO Pilotée par les messages
Protocole de transport Protocole de transport au
propriétaire choix
Fortement couplé Faiblement couplé
Traitement efficace Traitement lourd
SOA Vs Architecture Web
Architecture Web SOA

Interaction Programme/Utilisateur Interaction Programme/Programme
Integration statique des Integration dynamique des services
composants
Service monolithique (1 bloc) Plusieurs services réutilisables et
composables
Référencement via des annuaires Annuaires standardisés
de sites non standardisés
SOA Vs architecture OO
Archi. OO (ex : CORBA) SOA
Grain trop fin (Pb de scalabilité) Grain plus gros
Conçue pour durer (Évolu;on / Conçue pour changer (couplage

modifica;on difficile) faible)
Orientée fonc;onnalité Orientée processus
Orientée objet Orientée message
Cycle de développement long Développement et déploiement
interac;f
Couplage fort (réu;lisa;on Couplage faible
difficile et système complexe)
Langage de programma;on Mul;langage (indépendance)
spécifique
Applica;ons monolithiques Services réu;lisables
Applica;ons C/S isolées Services intégrables
Avantages de la SOA
  Métier :
-  Améliorer l’agilité et la flexibilité du métier (évolutivité)
-  Réduire en temps le cycle de développement
-  Faciliter la gestion des processus métier
-  Améliorer le retour sur investissement
  Techniques :
-  Réduire la complexité de la solution
-  Construire les services une seule fois et les utiliser
fréquemment
-  Garantir une intégration standardisée permettant de
communiquer avec des clients hétérogènes
-  Faciliter la maintenance
SOA/BPM et urbanisation
  AméliorerL’urbanisation du SI vise à le rendre
optimisé et agile, construit autour des processus
et fondé sur une architecture ouverte et à base de
composants :
-  Le couple BPM/SOA constitue pour l’urbanisation un
socle qui contribue à l’atteinte de ses objectifs, vu qu’il
est source d’optimisation et d’agilité pour le SI
-  Les processus métiers déployés sur l’architecture SOA
sont implémentés par des composants réutilisables,
contribuant à l’optimisation du SI
-  Le fait que les processus métier soient implémentés
sous forme de services dans le contexte de l’architecture
SOA, fait que leur implémentation et le SI soit faiblement
couplés, et que le SI soit par la suite flexible
CH3. Le concept Service Web
  Ce que le service Web pour SOA
  Définition
  Types de services Web
  Protocoles des services Web
  Intérêts et avantages
SOA et Services Web
  Les services Web sont une technologie

d’implémentation de la SOA
  Les services Web constituent la meilleure solution

disponible (standardisée)
-  Sont définis par des standards : OASIS, W3C,
IETF et WS-I
  Il est possible de mettre en œuvre une SOA sans

services Web (Interface Java+spécification JBI) et
d’utiliser des services Web sans une SOA
Service Web
  Selon W3C :
Application logicielle identifiée par un URI, dont les
interfaces et le binding peuvent être définis, décrits et
découvert par des artifacts XML, et supportent des
interactions directs avec d’autres applications logicielles
utilisant des messages à base de XML via des protocoles
à base d’Internet
  Composant logiciel :
-  modulaire implémenté dans n’importe quel langage
-  déployé sur n’importe quelle plateforme
-  enveloppé dans une couche de standards dérivés du XML
-  ne nécessitant pas une configuration réseau particulière
-  publié, localisé et invoqué de n’importe quel point du Web
-  accessible via des protocoles standards Internet
Protocoles des services Web
  Protocole de description des services (méthodes,

signatures…) : WSDL…
  Protocole pour l’écriture des messages : SOAP…
  Protocole de transport pour faire circuler les données sur
Internet (http, SMTP, FTP, TCP/IP, POP3, NNTP…)
Types de services Web
  Etendus : utilisent les standards UDDI (annuaire)/ WSDL

(contrat) / SOAP (consommation)
  REST (Representational State Transfer) utilisent :

-  directement HTTP au lieu d’une enveloppe SOAP
-  un URI pour nommer et identifier une ressource
-  les méthodes HTTP (POST, GET, PUT et DELETE) pour effectuer
les opérations de base CRUD
  Mais :
-  REST n’est pas un remplacement générique de SOAP (ne couvre
qu’une partie des besoins)
-  REST utilise WADL (Web Application Description Language) pour
décrire les Contrats, et qui est non standardisé : initiative isolée de
SUN
Services Web étendus
Cycle d’utilisation des services
Web étendus
Avantages des services Web
  Offrir
une technologie adaptée aux applications
B2B, EAI (Enterprise Application Integration), P2P
  Rendre possible et plus facile l’interconnexion et
l’interaction des systèmes et composants
hétérogènes
  Garantirl’interopérabilité et donner lieu à des

systèmes plus ouverts que ceux utilisant des
protocoles tels que RPC, DCOM, RMI…
  Garantir un couplage lâche
  Constituer une brique vers le Web sémantique

CH4. Les Standards des
services Web
  HTTP
  SOAP
  WSDL
  UDDI
  BPEL
  WS-Security
Pile des standards des services
Web étendus
HTTP (HyperText Transfer Protocol)
  Protocole de communication sur Internet
  Disponible sur toutes les plateformes
  Simple (a besoin de peu de support pour fonctionner)
  Sans connexion (peu de paquets sont nécessaires
pour l’échange d’informations)
  Niveau de sécurité simple et effectif
  Le seul protocole utilisable à travers des pare-feu
SOAP (Simple Object Access Protocol)
  Protocole d’échange d’informations XML entre client et
serveur HTTP (standard de W3C, initié par Microsoft et IBM)
-  De rôle similaire à RPC
  Protocole minimal pour l’appel des méthodes sur des
serveurs, services, composants, objets, et qui n’impose pas
l’utilisation de :
-  API ou Runtime (API)
-  ORB (CORBA,DCOM…) ou serveur Web particulier (Apache, IIS…)
-  Modèle de programmation
  Porté sur toutes les plateformes et technologies
  Extensions : SOAP sur SMTP/FTP, MOM …
Requête et réponse SOAP
  Peuvent servir à échanger par exemple :
-  Des Messages : appel sérialisé d’une méthode sur un

objet (Rq) / retour sérialisé d’un appel de méthode sur
un objet (Rp)
-  Appel (obligatoire), Réponse (optionnel), Erreur/fault
(optionnel)
-  Des Documents : Document XML (Rq) et sa version

transformée (Rp)
-  Paramètres In, InOUT (Req)/Inout, OUT (Rép) comme

dans le cas d’objets RPC
Exemple : requête SOAP (1/2)
  Appel du service hel (opération : HelloWorld)
Message SOAP pour appeler
l’opération makeHelloWorld
avec un paramètre value
Exemple : requête SOAP (2/2)
  Appel du service hel (opération : HelloWorld)
Message SOAP pour appeler
l’opération simpleHelloWorld,
sans de paramètre

Exemple : Réponse SOAP
  Messages de Réponses aux appels du service HelloWorld
Les réponses sont

sensiblement iden-ques

Structure d’un message SOAP
transporté par HTTP
Structure de l’enveloppe SOAP
  Elément racine du message identifié par la balise
<soapenv:Enveloppe>
  Il spécifie les espaces de désignation et de
codage de données (namespaces)
Ou contenu
de la réponse
Entête SOAP (Header)
  Elément facultatif du message identifié par la
balise <SOAP-ENV:Header>
-  Utilisé surtout quand le message est traité par plusieurs
intermédiaires avant le récepteur final
  Rajoute des info. non applicatives (supplémentaires)
-  Indique à l’application réceptrice que le Message est
optionnel/obligatoire (attribut mustUnderstand=0 ou 1)
-  Indique des Transactions, sessions, l’émetteur (cas de
FTP)…
Exemple : Entête SOAP dans un
transfert successif de message
Corps SOAP (Body)
  Elément facultatif du message identifié par la
balise <SOAP-ENV:Body>
  Il comprend des informations applicatives :
-  Structure Opération (Nom d’opération (suivi de Response) et
ses paramètres sous forme de structures s’ils sont de type
complexe (valeurs d’entrées ou de retour), fault (<SOAP-
ENV:Fault>)…
-  Ces informations respectent un encodage déterminé dans le

binding au niveau du fichier WSDL
u  Attribut style (Document et RPC)
u  Attribut use (encoded et litteral)
u  Les namespaces utilisés pour l’encodage sont :

- SOAP-ENC http://schemas.xmlsoap.org/soap/encoding/
- xsd : XML Schema Description
Exemple de Corps SOAP appelant une
opération d’un service Web (1/2)
Service Web Notebook

Appel de l’opéra-on

addPersonWithSimpleType

3 paramètres
Exemple de Corps SOAP appelant une
opération d’un service Web (2/2)
Service Web Notebook

Appel de l’opéra-on

addPersonWithComplexType

Parameètre de type

complexe défini sous
forme de structure
newPerson
Exemple de Corps SOAP contenant une réponse
d’une opération d’un service Web (2/2)
Exemple de réponse SOAP
transportée par http
  Codes de retour : 2xx (message reçu), 500 (message fault).
Exemple de requête SOAP
transportée par http
  Méthode POST avec Attribut SOAPAction (intention de la Rq)
Règles d’encodage de données (1/3)
  Types primitif
  Structure
  Enumération
  Référence
  Tableau
  Tableau creux
  Tableau d’octets
Encodage des faults
  Faultcode (obligatoire) : utilisé par un logiciel
pour identifier des faults (ex : switch (faultcode) …
-  4 groupes de code : Client, Serveur,
MustUnderstand, VersionMismatch
-  Ex : Client.authentification
  Faultstring (obligatoire) : description du fault

  Faultactor (optionnel) : firewall, proxy, MOM
(en cours de cheminement du msg)
  Detail : non lié au corps du message
  Autres : peuvent être ajoutés mais doivent être
associés à des namespaces
Exemple : Erreur SOAP (Fault)
Echanges SOAP via HTTP
Faut-il connaître SOAP ?
  Non : Utiliser des APIs fournissant une abstraction des
messages SOAP
  Oui (mais il faut connaître XML et XML Schema) pour :
-  Débugger une application
-  Réaliser des tests via l’outil graphique SOAP UI
-  Intercepter les messages bas niveau SOAP (via les
handlers)
  SOAP UI (www.soapui.org)
-  Disponible en Standalone ou intégré (Eclipse, Intellij,
Netbeans, Maven...) et indépendant de la plateforme
de développement
-  Supporte les Services Web étendus ou REST
-  Permet d’inspecter, invoquer, développer et simuler
des Services Web via des bouchons (mocks), et
d’effectuer des tests QoS (temps de réponse...)
SOAP et concurrents
RMI RPC DCOM CORBA SOAP
Organisme Sun SUN/ Microsoft OMG W3C
OSF
Plateforme Multi Multi Win32 Multi Multi
Langage de java C, C++ C++, VB, VJ, Multi Multi
développement … Opascal…
Langage de Java RPCGE ODL IDL WSDL
description N
Transport TCP, TCP, IP/IPX GIOP, HTTP,
HTTP, UDP IIOP HTTPR,
IIOP SMTP
transaction Non Oui Oui Oui
Sécurité SSL, - - SSL SSL
JAAS
SOAP Vs RMI, DCOM et CORBA
(Avantages et inconvénients)
RMI DCOM CORBA SOAP
-‐  Monolang. -‐  Mul;langage -‐  Mul;langage -‐  Mul;langage
-‐  Mul;-‐plate. -‐  Monoplateforme -‐  Mul;plat. -‐  Mul;plaforme
-‐  Problème de -‐  Protocole orienté -‐  Installa;on -‐  Spécifica;on non
performance connexion (+eurs coûteuse (si propriétaire (W3C)
et sécurité paquets doivent un ORB est à -‐  Requêtes/réponses
être échangés acheter) en XML
pour créer ou -‐  Implémenta;on
maintenir une facile sur différents
session) protocoles de
-‐  Faible diffusion transport
(Non disponible -‐  Capable de franchir
sur Mac OS, NT les farewalls (mais
3.51, Win95, le contrôle d’accès
WinCE2, coûteux à faible granularité
sur Unix, MVS, sera perdu)
VMS ou NT)
WSDL (Web Service Description
Language)
  Standard W3C basé sur XML pour la

description d’interfaces des services Web
-  Opérations du service
-  Paramètres d’entrée et sortie des opérations
-  Types de données des paramètres
-  Points d’entrée (URL) des opérations
-  Manière d’invoquer le service (Comment?)
Eléments WSDL
  <definitions> : racine du document
  <types> : Types de données sous format schéma XML
  <Part>
  <Message> : paramètre, valeur de retour, exception

  <Operation>
  <portType> : ensemble d’opérations

  <binding> : détail technique (protocoles…)
  <port> : point d’accès
  <service> : ensemble de port at leur binding associés
Exemple 1 : service Carnet d’adresses
  3 opérations
-  addPerson : Entrée (Person) + Sortie (booléen pour
indiquer l’état de création)
-  addPerson : Entrées (3 string : name, address et
birthyear)
-  getPersonByName : Entrée (string) + Sortie (Person)
-  getPersons : Sortie (tableau d’objets Person)
  Protocole SOAP : pour décrire les messages

  Protocole HTTP : pour l’échange de messages
WSDL : l’élément types
  2 variantes :
-  Contient la définition des types de données
(Schéma XSD, schéma XML…)
•  Facultatif si les types sont simples (Integer,
Boolean... )
-  Importe un fichier Schéma XML contenant la
définition des types
•  Avantage : réutiliser des types et d’alléger
le fichier WSDL
Exemple WSDL : définition des types
Exemple WSDL : Import d’un fichier
de types
WSDL : l’élément message
  Décrit un message échangé par le service et est

défini par les attributs :
-  Name : nom du message
-  1 ou plusieurs éléments <part> : inputs/outputs ou
exception d’une opération
  Chaque élément <part> est défini par les attributs :

-  name : nom du paramètre
-  type : type de données du paramètre
Exemple WSDL : l’élément message
WSDL: les éléments portType et opération
  Interface contenant les prototypes
d’opérations fournies par le service et définie
par les attributs :
-  Name : nom du portType
-  <opération> : 1 ou +eurs décrivant chacun le
prototype d’une méthode fournie par le service
  Chaque élément <opération> est défini par les
attributs :
-  name : nom de l’opération
-  <input message>/<output message>/ <fault> :
référence à 1 message décrivant les paramètres d’E/
S et le message d’erreur de l’opération
Exemple WSDL : l’élément portType
Types d’échanges assurés par une
opération
  One-way : Message input sans réponse
  Notification : Seul un message <output> est utilisé
  Request/Response : <input>, <output> et <fault>
Ø  Le service reçoit un message du client et répond à sa

requête
  Solicit - response : <input>, <output> et <fault>
Ø  Le client reçoit un message du service et répond au

service
Exemples des différents Types d’échanges
  One-way :
  Notification :
  Request/Response :
  Solicit - response :
WSDL : l’élément binding
  Décrit un portType du point de vue technique
-  Protocole (SOAP 1.1 ou 1.2, HTTP GET & Post : ex,
transfert d’images) utilisé pour manipuler un <portType>
  Est défini par les attributs :
-  name : nom du binding
-  type : portType concerné
  Sa structure (éléments qu’ils contient) dépend du
protocole utilisé
  Plusieurs <binding> peuvent être définis pour
appeler un portType de différentes manières
WSDL: Structure de l’élément binding
WSDL : Binding SOAP
  A généralement la forme <soap:binding> et est

défini par l’espace de noms :
-  http://schemas.xmlsoap.org/wsdl/soap/
  Utilise les principales balises suivantes :

-  <soap:binding>
-  <soap:operation>
-  <soap:body>, <soap:header>, <soap:headerfault>
-  <soap:fault>
WSDL : les éléments service et port
  Un élément <service> définit les ports (points

d’accès) du service
-  Chaque <port> spécifie 1 adresse pour 1 binding donné
  Un élément <port> est défini par les attributs :

-  name : nom du port
-  binding : nom du binding (défini précédemment)
  La structure de l’élément <port> est spécifique au

protocole utilisé dans le binding
-  <soap:address> : URI du port dans le cas d’un binding
SOAP
WSDL : les éléments service et port
Le portType Notebook est accessible

en SOAP/HTTP via cette URL
Exemple 2 : service HelloWorld
  2 opérations
-  makeHello : Entrée (string) + Sortie (string)
-  simpleHello : Sortie (string)
  Protocole SOAP : pour décrire les messages
  Protocole HTTP : pour l’échange de messages
Exemple 2 : service HelloWorld en WSDL
Exemple 2 : service HelloWorld en WSDL
Organisation d’un document WSDL
  Partie abstraite (types+Messages+portTypes) : réutilisable
  Partie concrète (binding+services)
Outils pour manipuler des documents
WSDL
  Edition
-  Notepad++ (texte : XML)
-  Eclipse JavaEE
-  Netbeans
-  Visual Studio
-  Environnements de développement de SW
  Validation
-  www.validwsdl.com
  Test
-  SOAPUI
UDDI (Universal Description,
Discovery and Integration)
  Annuaire mondial de services d’entreprises décrits en
WSDL et accessibles via des requêtes SOAP
-  Proposé en 2000 (Microsoft, Ariba et IBM, puis SUN, Oracle,
HP…), V2 (2002), V3 (2003) adoptée en 2005
  Contient 3 types d’infos :

-  Pages Blanches : fournisseurs de services (nom de l'entreprise,
ses coordonnées, sa description…)
-  Pages Jaunes : catégories de services fournis par les entreprises
-  Pages Vertes : description technique des WS (contrats WSDL,
informations de liaison…)
Modèle UDDI
Nom, desc., contact, Nom, desc. text, Desc., point d’accès,
catég., adresse, iden-f… catégorie… paramètres…
Schéma UDDI
  Le modèle UDDI est défini sous forme de schéma W3C XML
Pages blanches:
Providers (clé)
Pages jaunes:
info sur le service
+binding Templates
Coordonnées du
service :
Pt d’accès+tModels
Desc. Technique des

services
(format : XHTML,
WSDL…)
Exemple de Binding template
Exemple de TModel
Interface UDDI
  Implémentée sous forme de service Web SOAP, elle
permet :
-  Interrogation : rechercher des informations dans l’UDDI

-  Publication : publier des informations dans l’UDDI
-  Sécurité : assurer l’authentification pour l’accès
aux enregistrements protégés dans l’UDDI
-  Contrôle d'accès et propriété : transférer la propriété d’info
(attribuée à l’origine à l'utilisateur l’ayant publié) et de gérer les
droits d'accès associés
-  Abonnement : Assurer l’abonnement à des informations (ce qui
permet d'être averti lors de leur modification)
-  Réplication interne : synchroniser les noeuds d'un même UDDI
-  Réplication externe : dupliquer les informations entre différents
UDDI (par interrogation + publication + abonnement pour
propager les modifications)

BPEL
  Standard (V2) de OASIS, fondé sur XML pour

la description des processus
  Modélise un processus sous forme d’activités

qui s’enchaînent selon des instructions de
contrôle : séquence, parallélisme, choix
(décision), loop… et suite à d’éventuels
événements
BPEL et services Web
  Recommandé pour la composition des

services Web
-  Orchestration : seul un service « chef d’orchestre

connaît la logique de composition et appelle les
autres pour effectuer un service complexe
-  Chorégraphie : chaque service contribuant au

service composite doit connaître sa logique (ex :
attendre 50 s quand il est invoqué par le service X
avant d’envoyer un message au service Y)
Processus BPEL
  Service Web, chef d’orchestre, du point de vue
client
  Synchrone
-  Le client se connecte au service (processus) et attend sa
terminaison
  Asynchrone
-  Le client se connecte au service (processus) qui l’informe de sa
terminaison (procédé callback)
Eléments BPEL : Partner Links (1/2)
  2 types :
-  Invocation : Le processus BPEL invoque des

opérations d’autres services Web
-  Client : Le processus BPEL est invoqué par des

services Web clients
Eléments BPEL : Partner Links (2/2)
  Attributs :
-  name : nom du partnerLink
-  myRole : rôle du processus
-  partnerRole : rôle du partenaire
-  partnerLinkType : type du partnerLink défini dans la
description WSDL
  myRole défini seul (sans partnerRole) è seules

les interactions vers le processus sont autorisées
  partnerRole défini seul (sans myRole) è seules

les interactions vers le partenaires sont autorisées
Eléments BPEL : Activités (1/3)
  « Invoke » : pour appeler un service
  « Receive »: pour recevoir un message (initie le processus)
  « Reply » : pour renvoyer un message
  « Throw » : pour émettre une exception (message d’erreur)
Eléments BPEL : Activités (2/3)
  « Terminate » : pour terminer le processus
  « Wait » : pour suspendre le processus pendant une durée

déterminée
  « Assign » : pour manipuler des données

-  Ex : copier des valeurs entre variables ou utiliser des expressions
XPath 1.0 pour effectuer des traitements (manipuler des strings…)
Eléments BPEL : Structures de contrôle
(1/2)
  « Sequence » : pour exécuter une activité

séquentiellement après une autre
  « Switch » : structure de branchement selon des

conditions booléennes écrites sous forme d’expressions
XPath 1.0
  « While » : structure de boucle
Eléments BPEL : Structures de contrôle
(2/2)
  « Pick » : pour que le processus attende simultanément

plusieurs types de messages avec un délai maximum
d’attente, et effectue un traitement différent selon le cas
  « Flow » : pour paralléliser des activités (fork et join du

diagramme d’activités UML)
Eléments BPEL : Variables
  Permettent de manipuler des messages

envoyés et reçus par des partenaires
  Définies par des attributs :

-  name : nom de la variable
-  type ( ex : type schéma XML) ou messageType
déclarés dans un fichier WSDL
Eléments BPEL : Exemples de
variables
Exemple illustratif d’un processus BPEL
Conception et déploiement de
processus BPEL
  Outils :
-  Editeur graphique
-  Moteur BPEL
  Solutions :
-  OpenESB (via Glassfish 2.1) et Netbeans 6.7.1
-  Apache ODE et Eclipse BPEL Editor
-  JBoss jBPM (uniquement le moteur BPEL)
-  Oracle BPEL Process Manager (Weblogic + Jdeveloper)
-  Orchestra
-  IBM (Weblogic+Workshop)
-  BPEL for Windows Workflow Foundation (Visual Studio
et Biztalk)
-  …
Bibliographie
  Yves Caseau, Urbanisa;on, SOA et BPM, Le point de vue d’un DSI 3ème
édi;on, Dunod, Paris, 2008
  Mark D. Hansen. SOA Using Java Web Services. Pren;ceHall. Edi;on April
2007
  L. Maesano, C. Bernard et X. Le Galles. Services Web en J2EE et .NET :
concep;on et réalisa;on. Eyrolles 2003
  J. McGovern, S. TyaGI, M. E. Stevens, S. Mathew. Java Web services
architecture. Morgan Kauffmann. 2003.
Webographie
Livres Blancs :
  Cyrille Devaux. Urbanisa;on et architecture orientée service (SOA) :
Quelques bonnes pra;ques pour leur mise en œuvre. Livre blanc. Aubay.
2008. Consulté le 10 Juin 2013.
hqp://www.aubay.com/en/news/publica;ons/publica;ons/urbanisa;on-‐
et-‐architecture-‐orientee-‐service-‐soa-‐2008/
  David A. Chappell. Enterprise Service Bus. O’Reilly & Associates. June 2004.
Mickaël BARON. SOA – Services Web Etendus : Développer Services Web.
hqp://petals.ow2.org/docs/Livre-‐Blanc-‐ESB-‐fr.pdf
  EBM. Nouvelles technologies pour l’intégra;on : les ESB. Janvier 2006.
hqp://download.forge.objectweb.org/petals/Livre-‐Blanc-‐ESB-‐fr.pdf
  Adrien Louis. Bus de Service -‐ESB-‐ Nouvelle technologie pour l’intégra;on .
Version 1.4 – Novembre 2008. Petalslink.
hqp://www.needocs.com/document/professionnel-‐tutoriel-‐informa;que-‐
graphisme-‐integra;on-‐bus-‐service-‐esb-‐nouvelle-‐technologie-‐l-‐integra;on,
2363
Webographie (suite)
Cours et blogs :

  Occello Audry. Introduc;on à l’Architecture-‐Orientee-‐Service. Cours.
hqp://fr.scribd.com/doc/163299396/Introduc;on-‐a-‐l
%E2%80%99Architecture-‐Orientee-‐Service
  Mickaël BARON. SOA – Services Web Etendus : Développer des Services
Web étendus avec Java : JAX-‐WS.
hqp://mbaron.developpez.com/soa/jaxws/
  FABRICE CLARI. Web services. XML, SOAP, WSDL, RPC avec SOAP, AXIS,
SOA... hqp://dep;nfo.unice.fr/~baude/WS/WebServices-‐2008.pdf
  Propriétés services (autonomie et stateless, découvrabilité, compos) :
Christophe Heubès. SOA : Du composant au service : Sans état (Stateless).
hqp://blog.xebia.fr/2009/06/04/soa-‐du-‐composant-‐au-‐service-‐sans-‐etat-‐
stateless/
Webographie (suite)
Spécifica-ons
  OASIS. UDDI Version 2.04 API Specifica;on, UDDI Commiqee Specifica;on,
19 July 2002.
hqp://uddi.org/pubs/ProgrammersAPI-‐V2.04-‐Published-‐20020719.pdf
  OASIS. Web Services Business Process Execu;on Language Version 2.0. 11
April 2007.
hqp://docs.oasis-‐open.org/wsbpel/2.0/OS/wsbpel-‐v2.0-‐OS.html
  W3C. Simple Object Access Protocol (SOAP) 1.1.W3C Note 08 May 2000.
hqp://www.w3.org/TR/2000/NOTE-‐SOAP-‐20000508/#_Toc478383514
  W3C. Web Services Descrip;on Language (WSDL) 1.1. W3C Note 15 March
2001. hqp://www.w3.org/TR/wsdl
  W3C. Web Services Descrip;on Language (WSDL) Version 2.0 Part 1: Core
Language. W3C Recommenda;on 26 June 2007.
hqp://www.w3.org/TR/wsdl20/

Support de Cours: Ervice Riented Rchitecture

Transféré par

Droits d'auteur :

Formats disponibles

Support de Cours: Ervice Riented Rchitecture

Transféré par

Informations du document

Titre original

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

Support de Cours: Ervice Riented Rchitecture

Transféré par

Droits d'auteur :

Formats disponibles

Support de cours

 Comprendre le concept service et les principes de

 Comprendre l’intérêt de l’architecture SOA

 Comprendre le concept service Web et apprendre

 Qu’est ce qu’un service?

 Orchestration des services

 Un PD définit un concept pour représenter le monde et des

 Différents PD ont vu le jour et ont évolué du binaire, à

þ Brique composable þ …

 Composant logiciel qui exécute une action pour le

 Il traduit le niveau logique d’accès aux traitements,

- Mutualisé (partagé puisqu’il est réutilisable et interopérable)

 Entité (CRUD) : Create, Read, Update and Delete

 Il peut être modélisé par :

 Ses opérations peuvent être déclenchées selon que des

 CRUD : service élémentaire permettant de créer,

 Transverse (Infrastructure) : exécute un traitement

 Host : permet aux applications distribuées d’utiliser

 Il exécute un traitement métier (fonction), et peut être

 Il invoque des services CRUD et/ou Transverses pour

 Il peut aussi invoquer des services plus élémentaires ou

 Il peut aussi servir à la gestion de la sécurité, des règles

 Modulaires et de large granularité

 Autonomes et sans état (stateless)

 Le contrat est généralement décrit au moyen du standard

 Chaque consommateur peut invoquer un service via son

 Les services communiquent uniquement par messages

 Pour augmenter la performance, les concepteurs doivent

 Le service fonctionne en « boîte noire »

- le fonctionnement interne du service (sa logique métier et son

 Large granularité : Le service est un gros grain qui

 Modularité : Il peut être déployé de façon atomique

 Statelessness : Il est sans état (stateless) càd il

 Le service précise un type de connecteur (càd protocole

 Une spécification de médiation permettra de réaliser le

 Dépendance faible entre le consommateur et le

 Il est publié par le fournisseur dans un annuaire : décrit

 Le consommateur peut chercher un service selon un

- Tous les arguments nécessaires à l’exécution du service

 Un service peut participer à des compositions

 Limites dues à leurs technologies de base :

 SOA, proposée par Gartner Group (2003-2008), se prête

 Plusieurs partenaires peuvent

 Les Services Web demeurent la technologie émergente

 Annuaire (Registry) : permet de publier les

 Référentiel (Repository) : stocke les définitions

 L’annuaire et le référentiel peuvent être fusionné en

 Le Binding indique le modèle à utiliser pour communiquer

 Orchestration : assure la coordination des services

 Services : héberge et organise les services par

 Composants : héberge les composants utilisés par les

 QOS (souvent intégrée dans un ESB) : assure, contrôle et

Account Profile Product Item Inventory Cart OrderInsert OrderRead

IAccount IProfile IProduct IItem IInventory IOrder

Account Profile Product Item Inventory Cart OrderInsert OrderRead

1.0 1.0 10.0 5.1 1.0

Customer Catalog Inventory Shopping Billing

Service Manage Show Make

 Solution d’intégration qui reprend les principes

  Comprendre le concept service et les principes de

  Comprendre l’intérêt de l’architecture SOA

  Comprendre le concept service Web et apprendre

  Qu’est ce qu’un service?

  Orchestration des services

  Un PD définit un concept pour représenter le monde et des

  Différents PD ont vu le jour et ont évolué du binaire, à

þ  Brique composable þ  …

  Composant logiciel qui exécute une action pour le

  Il traduit le niveau logique d’accès aux traitements,

-  Mutualisé (partagé puisqu’il est réutilisable et interopérable)

  Entité (CRUD) : Create, Read, Update and Delete

  Il peut être modélisé par :

  Ses opérations peuvent être déclenchées selon que des

  CRUD : service élémentaire permettant de créer,

  Transverse (Infrastructure) : exécute un traitement

  Host : permet aux applications distribuées d’utiliser

  Il exécute un traitement métier (fonction), et peut être

  Il invoque des services CRUD et/ou Transverses pour

  Il peut aussi invoquer des services plus élémentaires ou

  Il peut aussi servir à la gestion de la sécurité, des règles

  Modulaires et de large granularité

  Autonomes et sans état (stateless)

  Le contrat est généralement décrit au moyen du standard

  Chaque consommateur peut invoquer un service via son

  Les services communiquent uniquement par messages

  Pour augmenter la performance, les concepteurs doivent

  Le service fonctionne en « boîte noire »

-  le fonctionnement interne du service (sa logique métier et son

  Large granularité : Le service est un gros grain qui

  Modularité : Il peut être déployé de façon atomique

  Statelessness : Il est sans état (stateless) càd il

  Le service précise un type de connecteur (càd protocole

  Une spécification de médiation permettra de réaliser le

  Dépendance faible entre le consommateur et le

  Il est publié par le fournisseur dans un annuaire : décrit

  Le consommateur peut chercher un service selon un

-  Tous les arguments nécessaires à l’exécution du service

  Un service peut participer à des compositions

  Limites dues à leurs technologies de base :

  SOA, proposée par Gartner Group (2003-2008), se prête

  Plusieurs partenaires peuvent

  Les Services Web demeurent la technologie émergente

  Annuaire (Registry) : permet de publier les

  Référentiel (Repository) : stocke les définitions

  L’annuaire et le référentiel peuvent être fusionné en

  Le Binding indique le modèle à utiliser pour communiquer

  Orchestration : assure la coordination des services

  Services : héberge et organise les services par

  Composants : héberge les composants utilisés par les

  QOS (souvent intégrée dans un ESB) : assure, contrôle et

  Solution d’intégration qui reprend les principes

  IBM Websphere ESB

  Les services assurés par l’ESB dépendent de

  Les services Web sont une technologie

  Les services Web constituent la meilleure solution

  Il est possible de mettre en œuvre une SOA sans

  Protocole de description des services (méthodes,

  Etendus : utilisent les standards UDDI (annuaire)/ WSDL

  REST (Representational State Transfer) utilisent :

  Garantirl’interopérabilité et donner lieu à des

  Garantir un couplage lâche

  Constituer une brique vers le Web sémantique

-  Des Messages : appel sérialisé d’une méthode sur un

-  Des Documents : Document XML (Rq) et sa version

-  Paramètres In, InOUT (Req)/Inout, OUT (Rép) comme

-  Ces informations respectent un encodage déterminé dans le

u  Attribut use (encoded et litteral)

u  Les namespaces utilisés pour l’encodage sont :

  Faultstring (obligatoire) : description du fault

  Standard W3C basé sur XML pour la

  <Message> : paramètre, valeur de retour, exception

  <portType> : ensemble d’opérations

  Protocole SOAP : pour décrire les messages

  Décrit un message échangé par le service et est

  Chaque élément <part> est défini par les attributs :

  Notification : Seul un message <output> est utilisé

  Request/Response : <input>, <output> et <fault>

Ø  Le service reçoit un message du client et répond à sa

  Solicit - response : <input>, <output> et <fault>