SOA - Architectures Orientées Services

Rappels d’Architecture
XML, Services Web, SOAP, WSDL, UDDI
REST, HATEOAS et micro-services
Principes des architectures SOA
Fonctionnement d’un bus ESB
Modèles d’architectures SOA et patterns
Extensions WS-X
Modélisation SOA - BPMN

Leuville Objects
3 rue de la Porte de Buc
F-78000 Versailles
FRANCE

tel : + 33 (0) 1 39 50 2000

fax: + 33 (0) 1 39 50 2015

www.leuville.com
[email protected]
(c)Leuville Objects

 Leuville Objects
29 rue Georges Clémenceau
F-91310 Leuville sur Orge
FRANCE

http://www.leuville.com

Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des
pages publiées dans le présent ouvrage, faite sans l’autorisation de Leuville Objects, est illicite et
constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété intellectuelle du 1er juillet
1992, articles L 122-4, L 122-5 et L 335-2).
Les marques citées sont des marques commerciales déposées par leurs propriétaires respectifs.
CETTE PUBLICATION EST FOURNIE "EN L'ETAT" SANS GARANTIE D'AUCUNE SORTE,
NI EXPRESSE NI IMPLICITE, Y COMPRIS, ET SANS QUE CETTE LISTE NE SOIT
LIMITATIVE, DES GARANTIES CONCERNANT LA VALEUR MARCHANDE, L'APTITUDE
DES PRODUITS A RÉPONDRE A UNE UTILISATION PARTICULIERE, OU LE FAIT QU'ILS
NE SOIENT PAS CONTREFAISANTS DE PRODUITS DE TIERS.
(c)Leuville Objects
 Table des matières
Modèles d’architectures multi-niveaux ................................................ 1
Architecture centralisée ....................................................................... 1-3
Client - serveur..................................................................................... 1-5
Architecture multi-niveaux .................................................................. 1-7
Architecture multi-niveaux ouverte au web......................................... 1-9
Sécurité des architectures multi-niveaux Internet.............................. 1-11
Introduction aux architectures orientées services (SOA) ................. 13
Quiproquos......................................................................................... 2-15
Premières définitions ......................................................................... 2-17
Définitions d’un service et d’une architecture SOA .......................... 2-19
Plus sur la notion de service .............................................................. 2-21
Avant SOA......................................................................................... 2-23
SOA ................................................................................................... 2-29
Le nouveau modèle induit par SOA .................................................. 2-33
Avantages des stratégies SOA ........................................................... 2-35
Pièges liés à l’adoption de SOA ........................................................ 2-37
Le bus ESB ........................................................................................ 2-41
Le bus ESB : mise en place incrémentale.......................................... 2-47
Le routage des messages par le bus ................................................... 2-49
Web Oriented Architecture (WOA)................................................... 2-51
La standardisation .............................................................................. 2-53
Synthèse ............................................................................................. 2-57
Introduction aux microservices........................................................... 59
Constats.............................................................................................. 3-61
Microservices..................................................................................... 3-63
Liens avec SOA ................................................................................. 3-71
Modèles d’architectures ..................................................................... 3-73
Utilisateurs ......................................................................................... 3-77
Introduction aux Services Web ........................................................... 79
Les services WEB .............................................................................. 4-81
Bénéfices des services WEB.............................................................. 4-83
Les constituants d’une architecture à base de services WEB ............ 4-85
Principes de fonctionnement.............................................................. 4-87
Pile Web Services .............................................................................. 4-89
SOAP ................................................................................................. 4-95
Structure d’un message SOAP........................................................... 4-97
Un exemple de message SOAP ......................................................... 4-99
WSDL .............................................................................................. 4-101
Exemple WSDL ............................................................................... 4-105
UDDI ............................................................................................... 4-111
Historique des services WEB .......................................................... 4-113

Version 5.1
 (c)Leuville Objects

Les enjeux ........................................................................................ 4-115

Representational state transfer ......................................................... 117
Representational state transfer (REST)............................................ 5-119
Elément architecturaux de REST..................................................... 5-141
Services REST vs Services SOAP................................................... 5-143
HATEOAS (Hypermedia as the Engine of Application State)....... 145
Le modèle de maturité de Richardson ............................................. 6-147
REST / HATEOAS .......................................................................... 6-151
Hypermedia...................................................................................... 6-153
Implémentations disponibles ........................................................... 6-157
Enterprise Service Bus ....................................................................... 159
MOM ............................................................................................... 7-165
MOM : domaines de messagerie ..................................................... 7-167
MOM : exemple JMS ...................................................................... 7-171
Web Services ................................................................................... 7-175
Routage Intelligent des messages .................................................... 7-177
Routage Intelligent des messages: exemple..................................... 7-183
Transformations XML ..................................................................... 7-189
Transformations XML : insertion .................................................... 7-193
Transformations XML : remplacement ........................................... 7-195
Transformations XML : suppression ............................................... 7-197
Architecture logique d’un bus ESB ................................................. 7-199
Déploiement d’un bus ESB.............................................................. 7-201
Exemple de bus ESB........................................................................ 7-203
Les architectures et modèles SOA..................................................... 205
Architecture SOA ............................................................................ 8-207
Modèle trois couches de Thomas Erl............................................... 8-209
Modèle BEA .................................................................................... 8-213
Services d’accès et d’information.................................................... 8-215
Services métier partagés .................................................................. 8-217
Services de présentation................................................................... 8-219
Applications composites .................................................................. 8-221
Services d’infrastructure .................................................................. 8-223
Le pattern VETO ou VETRO .......................................................... 8-225
Enterprise Integration Patterns : système de messagerie............... 229
Enterprise Integration Patterns......................................................... 9-231
Styles d’intégration .......................................................................... 9-235
Système de messagerie .................................................................... 9-245
Messaging Channels ........................................................................ 9-259
Les extensions WS-X .......................................................................... 281
Les spécifications Web Services.................................................... 10-283
Extensions courantes...................................................................... 10-307

Architectures Orientées Services Version 5.1

(c)Leuville Objects

WS-MetadataExchange ................................................................. 10-309

WS-Coordination ............................................................................... 311
Les transactions et les Services Web ............................................. 11-313
WS-Coordination ........................................................................... 11-315
WS-Coordination : activation et enregistrement ........................... 11-319
WS-Coordination : fin d’activité ................................................... 11-321
Deux types de coordinations.......................................................... 11-323
WS-Coordination : implémentation............................................... 11-325
Exemple de contexte WS-Coordination ........................................ 11-327
La sécurité au sein des Web Services ............................................... 329
Spécifications................................................................................. 12-331
WS-Security................................................................................... 12-333
WS-Policy ...................................................................................... 12-335
WS-SecurityPolicy......................................................................... 12-337
SAML ............................................................................................ 12-339
WS-Security ........................................................................................ 341
Présentation de WS-Security ......................................................... 13-343
Terminologie.................................................................................. 13-345
Cryptage et signature numérique ................................................... 13-347
Structures des en-têtes Security ..................................................... 13-349
Gestion des erreurs......................................................................... 13-351
Exemple de message ...................................................................... 13-353
Autre exemple................................................................................ 13-355
Implémentations de WS-Security .................................................. 13-357
Expression des besoins ....................................................................... 359
Démarche générale ........................................................................ 14-361
Etude de faisabilité......................................................................... 14-363
Repérage du domaine..................................................................... 14-365
Découverte des informations ......................................................... 14-369
Modélisation des workflows .......................................................... 14-371
Diagnostic ...................................................................................... 14-375
Scénarios de reconfiguration du SI ................................................ 14-377
L’établissement du cahier des charges........................................... 14-379
Analyse, conception et modélisation des services ............................ 383
Expression des besoins d’un projet SOA....................................... 15-385
Phases du développement .............................................................. 15-387
Sorties des différentes phases ........................................................ 15-389
Analyse SOA ................................................................................. 15-393
Définir les services candidats ........................................................ 15-395
Les qualités attendues d’un service ............................................... 15-397
Définir des services d’orchestration .............................................. 15-399
Conception préliminaire SOA ....................................................... 15-401

Version 5.1
 (c)Leuville Objects

Conception de services inter-opérables ......................................... 15-403

Formaliser une architecture SOA en UML.................................... 15-405
SoaML ........................................................................................... 15-407
ServiceInterface SoaML ................................................................ 15-409
Introduction à BPMN......................................................................... 411
Introduction.................................................................................... 16-413
Simplicité ....................................................................................... 16-417
Présentation.................................................................................... 16-419
A quoi ça sert ? .............................................................................. 16-421
Historique....................................................................................... 16-423
A qui est destiné BPMN ?.............................................................. 16-425
Objectifs......................................................................................... 16-427
Exemple de diagramme BPMN ..................................................... 16-429
Outils de modélisation ................................................................... 16-433
Conclusion ..................................................................................... 16-437
Model-Driven Architecture ............................................................... 439
Model Driven Architecture ............................................................ 17-441
Les modèles MDA ......................................................................... 17-443
Les transformations MDA ............................................................. 17-445
Les mappings ou profils MDA ...................................................... 17-451
QVT ............................................................................................... 17-453
ATL................................................................................................ 17-455
Ingénierie Dirigée par les Modèles (IDM) dans un cadre SOA...... 457
MDA et SOA ................................................................................. 18-459
Praxeme ......................................................................................... 18-461
Gouvernance SOA .............................................................................. 465
Gouvernance .................................................................................. 19-467
Centre d’excellence SOA............................................................... 19-469
Comité de gouvernance ................................................................. 19-473
Processus de gouvernance ............................................................. 19-475
Annexes................................................................................................ 481
Introduction aux technologies XML................................................. 483
Présentation de XML ..................................................................... 20-485
Applications de XML .................................................................... 20-487
Exemple de document XML.......................................................... 20-489
Règles syntaxiques XML............................................................... 20-493
Contrôler la structure d’un document XML .................................. 20-495
XMLSchema .................................................................................. 20-497
Exemple XMLSchema................................................................... 20-499
Les espaces de nommage XMLSchema ........................................ 20-501
Les parseurs XML ......................................................................... 20-503
Principes DOM .............................................................................. 20-507

Architectures Orientées Services Version 5.1

(c)Leuville Objects

Principes SAX................................................................................ 20-509

Technologies XML ........................................................................ 20-511
eXtensible Stylesheet Language (XSL) ......................................... 20-513
Exemple XSLT .............................................................................. 20-515
JavaScript Object Notation ............................................................... 519
JSON .............................................................................................. 21-521
Structure d’un document JSON ..................................................... 21-523
Avantages de JSON ....................................................................... 21-533
Utilisation de JSON ....................................................................... 21-535
Présentation oAuth............................................................................. 537
Présentation du protocole OAuth................................................... 22-539
Historique....................................................................................... 22-541
Fonctionnement général................................................................. 22-543
Rôles .............................................................................................. 22-547
Enregistrement préalable ............................................................... 22-549
Exemple de processus .................................................................... 22-551
Les types d’autorisations ............................................................... 22-555
Authorization Code........................................................................ 22-557
Authorization Code: échanges HTTP ............................................ 22-559
Implicit........................................................................................... 22-565
Implicit: Requêtes/réponses HTTP ................................................ 22-567
Resource Owner password credentials .......................................... 22-569
Client credentials ........................................................................... 22-571
Offre SOA ........................................................................................... 573
Bus ESB ......................................................................................... 23-575
La vision SOA d’un fournisseur : BEA Systems........................... 23-579
La vision SOA d’un fournisseur : Oracle ...................................... 23-583
La vision SOA d’un fournisseur : IBM ......................................... 23-585
La vision SOA d’un fournisseur : MICROSOFT .......................... 23-591
La vision d’un fournisseur: TIBCO ............................................... 23-595
Les principaux outils Open Source................................................... 601
Les serveurs de messagerie............................................................ 24-603
Les routeurs.................................................................................... 24-609
Les frameworks Web Service ........................................................ 24-611
Les ESB ......................................................................................... 24-615
Les bundles .................................................................................... 24-621
Les outils de développement.......................................................... 24-623
WS-BPEL / Business Process Execution Language ........................ 625
L’orchestration des Services Web ................................................. 25-627
Historique BPEL............................................................................ 25-629
WS-BPEL ...................................................................................... 25-631
<process> ....................................................................................... 25-633

Version 5.1
 (c)Leuville Objects

<partnerLinks>............................................................................... 25-635
<partnerLinkType>........................................................................ 25-637
<variables>..................................................................................... 25-639
<sequences>................................................................................... 25-643
<assign> ......................................................................................... 25-645
<invoke> ........................................................................................ 25-647
<receive> ....................................................................................... 25-649
<switch>......................................................................................... 25-651

Architectures Orientées Services Version 5.1

(c)Leuville Objects

Version 5.1
Architectures Orientées Services Version 5.1
Modèles d’architectures multi-niveaux

o Architecture centralisée, client-serveur, multi-niveaux

o Spécificités des architectures ouvertes sur le WEB et les architectures internet sécurisées

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Modèles d’architectures multi-niveaux 1-2
 Architectures Orientées Services - Modèles d’architectures multi-niveaux Version 5.1

Architecture centralisée

Modèle "historique"

o Un serveur puissant hébergeant programmes et données (mainframe).

o Des terminaux passifs.

(c)Leuville Objects 1-3

Architecture centralisée

Notes

(c) Leuville Objects Architectures Orientées Services - Modèles d’architectures multi-niveaux 1-4
 Architectures Orientées Services - Modèles d’architectures multi-niveaux Version 5.1

Client - serveur

Architecture à deux niveaux

Avantages Client
Application cliente
o Une certaine simplicité
interface
o Robustesse meilleure graphique

Inconvénients logique métier

o Logique métier répartie entre le

client et le serveur

o Modularité limitée
Serveur
o Montée en charge problématique logique métier

o Adaptation au WEB coûteuse

Interface serveur
S.G.B.D

S.G.B.D.

(c)Leuville Objects 1-5

Client - serveur

Les architectures à deux niveaux peuvent convenir aux besoins relativement limités en termes d’adaptabilité
à la montée en charge et d’évolutivité.

Avantages

o Simplicité architecturale
o Rapidité de mise en oeuvre
o Moins de niveaux entraîne moins de risques de pannes

Inconvénients

o Difficultés pour identifier les composants responsables de la logique métier, car ceux-ci sont souvent
répartis dans le client et le serveur
o Montée en charge très difficile, voire impossible, car ce type d’architecture n’offre pas la modularité
suffisante:
o arrivée directe des connexions client sur le serveur, sans possibilités de multiplexage,
o grandes difficultés pour repartir les traitements métier sur plusieurs machines
o Cette architecture devra être revue si l’on souhaite utiliser le client sur le WEB:
o le client doit être allégé,
o des mécanismes d’accompagnement de la montée en charge doivent être définis.

(c) Leuville Objects Architectures Orientées Services - Modèles d’architectures multi-niveaux 1-6
 Architectures Orientées Services - Modèles d’architectures multi-niveaux Version 5.1

Architecture multi-niveaux

Modèle

Client léger

o Applet Java et/ou HTML,

XML, HTML dynamique

Serveur applicatif ou "métier"

o Composants "métier" et
middleware

Serveur de données

o SGBD, applications
"mainframe"

(c)Leuville Objects 1-7

Architecture multi-niveaux

Par rapport à une architecture client-serveur à deux niveaux, une architecture multi-niveaux présente de
nombreux avantages:
o identification des responsabilités de chaque composant,
o très grande modularité,
o capacité d’adaptation à la charge par duplication des composants.

Par contre, elle présente quelques inconvénients:

o de plus grands risques de panne dûs au nombre de composants et d’interfaces impliqués
o une plus grande compléxité de définition de l’architecture.

Client léger

L’applicatif client comporte uniquement les objets graphiques constituant l’interface utilisateur. Cette
interface peut être en HTML, DHTML, XML, applet Java et Swing, ...

Serveur applicatif ou "métier"

Cette partie centrale rassemble la logique fonctionnelle ou "métier" de l’application.

Serveur de données et applications historiques

Ce niveau rassemble les applications spécialisées en gestion des données telles que SGBD, bases
hiérarchiques ou "mainframe" ainsi que les applications existantes (Cobol, C, ...).
(c) Leuville Objects Architectures Orientées Services - Modèles d’architectures multi-niveaux 1-8
 Architectures Orientées Services - Modèles d’architectures multi-niveaux Version 5.1

Architecture multi-niveaux ouverte au web

Client léger

o Client léger: applet Java et/ou

HTML, XML, WML, ...

o Sécurité plus facile à gérer

CGI
Servlet
JSP
Client Serveur ASP
HTML WEB

(c)Leuville Objects 1-9

Architecture multi-niveaux ouverte au web

Notes

Une architecture multi-niveaux peut-être ouverte sur le monde extérieur par ajout d’un serveur WEB sur la
partie centrale. Ce serveur reçoit les requêtes provenant des clients légers HTML et invoque les services
offerts par les composants métier. Il retourne les réponses au format HTML, mais aussi XML, WML ou
applet.

Pour dialoguer avec la partie applicative, il existe plusieurs possibilités suivant les serveurs WEB du
marché:
o Passerelle de type CGI (Common Gateway Interface) : programmée en C, PERL, ou langage de scripting
de type Unix, elle permet d’invoquer un programme externe au serveur WEB et de retourner des résultats
au format HTML.
o Moteur de servlet Java : suivant un principe identique au CGI, une servlet Java accède aux services de la
couche applicative et retourne le résultat au format HTML.
o Java Server Pages : les pages HTML intègrent directement les appels Java au code applicatif. Ces appels
sont compilés dynamiquement sur le serveur WEB et exécutés. Les résultats sont formatés en HTML.
o Active Server Pages de Microsoft : les pages HTML intègrent directement les appels Visual Basic au code
applicatif. Ces appels sont compilés dynamiquement sur le serveur WEB et exécutés. Les résultats sont
formatés en HTML.

(c) Leuville Objects Architectures Orientées Services - Modèles d’architectures multi-niveaux 1-10
 Architectures Orientées Services - Modèles d’architectures multi-niveaux Version 5.1

Sécurité des architectures multi-niveaux Internet

Les protocoles réseau employés doivent être compatibles avec l’emploi de protections ’pare-feu’

o HTTP

o IIOP avec
tunneling HTTP

o DCOM avec
tunneling HTTP

(c)Leuville Objects 1-11

Sécurité des architectures multi-niveaux Internet

Les architectures multi-niveaux ouvertes sur Internet doivent tenir compte de contraintes de sécurité
spécifiques. Il est notamment recommandé de protéger le réseau interne à l’entreprise à l’aide de solutions
de types ’pare-feu’ ou ’firewall’.

Ces protections sont généralement contrôlées à partir de règles de filtrage qui permettent:
o d’interdire l’entrée du réseau à certains protocoles,
o de refuser des connexions en dehors de certains numéros de ports réservés,
o de refuser des paquets provenant de certaines sources comme des serveurs connus pour héberger des
pirates,
o ...

Il est recommandé de protéger le réseau de l’entreprise à l’aide de deux protections pare-feu de types
différents, afin d’assurer une sécurité plus grande. Entre ces deux pare-feu, on placera un serveur WEB qui
a pour fonction de relayer les appels HTTP entrants vers le réseau interne. Cette zone intermédiaire dans
laquelle on ne trouve aucune application critique est désignée sous le nom de DMZ.

Cela introduit des contraintes sur le développement, particulièrement au niveau du choix des protocoles de
communication entre les clients distants et le serveur WEB ou le serveur applicatif. Il faut en effet que le
protocole choisi soit capable de traverser les protections ’pare-feu’ sans nécessiter un affaiblissement trop
fort au niveau de leurs règles de filtrage.

Un serveur applicatif devra prendre en charge au maximum ces infrastructures techniques afin que le
concepteur puisse se concentrer sur la définition des services "métier".

(c) Leuville Objects Architectures Orientées Services - Modèles d’architectures multi-niveaux 1-12
Architectures Orientées Services Version 5.1
Introduction aux architectures orientées services (SOA)

o Premières définitions et avantages

o Enterprise Service Bus (ESB)

o Standards

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-14
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Quiproquos

SOA ?

o Une application qui utilise des services web est de type SOA

o Une application qui utilise des services web ainsi que des extensions WS-X est de type SOA

o SOA est avant tout un terme marketing qui cache un concept ancien : les web services

o SOA est un terme marketing qui cache un concept d’informatique distribuée basée sur les web services

o SOA simplifie l’informatique distribuée

o La connaissance des Web Services est suffisante pour bâtir une architecture SOA

o Une fois l’architecture SOA adoptée, toutes les applications deviennent interopérables

SOA

o La technologie n’est pas suffisante

o Le modèle architectural sous-jacent est complexe

o La définition des services l’est également

o L’interopérabilité n’est pas automatique

(c)Leuville Objects 2-15

Quiprocos

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-16
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Premières définitions

o Une architecture SOA crée des services réutilisables de niveau entreprise accessibles à travers des
standards Web neutres et ouverts

o L’architecture orientée service ou SOA est une stratégie permettant de convertir les fonctions élémentaires
des applications d’entreprise en services normalisés et inter-opérables qui peuvent ensuite être rapidement
combinés et réutilisés pour répondre aux besoins métier.

Idées essentielles

o Orientation services et non pas fonctionnalités ou applications

o Réutilisabilité

o Granularité entreprise

o Importance des standards

o Adaptabilité

o Plus une stratégie d’entreprise qu’une nouvelle technologie

(c)Leuville Objects 2-17

Premières définitions

Notes

La seconde définition provient de BEA Systems.

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-18
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Définitions d’un service et d’une architecture SOA

Service

o MSDN : un composant capable d’exécuter une tâche.

o Microsoft : un programme qui interagit avec d’autres programmes au moyen de messages

o Gartner Group : Un service désigne une action exécutée par un composant "fournisseur" à l'attention d'un
composant "consommateur", basé éventuellement sur un autre système.

Web Service

o W3C : système logiciel identifié par une URI dont les interfaces publiques et les liaisons sont définies et
décrites en XML. Sa définition peut être découverte en utilisant d’autres systèmes logiciels. Ces systèmes
peuvent interagir avec le Web Service selon des modalités prescrites par sa définition, en utilisant des
messages XML transportés par des protocoles Internet.

Architecture Orientée Services

o CBDI : Les stratégies, pratiques et frameworks qui permettent aux fonctionnalités applicatives d’être
consommées comme des ensemble de services publiés à un niveau de granularité dépendant du consommateur
de ces services. Les services peuvent être invoqués, publiés et découverts et sont découplés de toute
implémentation par l’emploi d’interfaces basées sur des standards.

o Gartner Group : un modèle d'interaction applicative mettant en oeuvre des connexions en couplage lâche entre
divers composants logiciels (ou agents).

(c)Leuville Objects 2-19

Définitions d’un service et d’une architecture SOA

Notes

http://www.cbdiforum.com/

http://msdn.microsoft.com/architecture/soa/

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-20
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Plus sur la notion de service

Un service doit

o Offrir un ensemble d’opérations dont les interfaces sont publiées

o Etre autonome, ce qui implique l’absence de notion d’état

o Respecter un ensemble de règles

o Correspondre à un processus métier d’une organisation

Caractéristiques

o A forte granularité

o Localisable

o Présente une interface bien définie

o Singleton, contrairement à un composant instanciable en de multiples exemplaires

o Faiblement couplé

(c)Leuville Objects 2-21

Plus sur la notion de service

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-22
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Avant SOA

CORBA : une première tentative d’établissement d’un "bus logiciel"

o une infrastructure de
diffusion de messages
orientée Objet

o des services techniques

évolués

o une vision "métier"

orientée Objets et
Applications

o une certaine
indépendance vis-à-vis
des plateformes

Mais

o très grande complexité

o coûts de développement
importants

o refusé par un acteur

important : Microsoft

(c)Leuville Objects 2-23

Avant SOA

Notes

CORBA = Common Object Request Broker Architecture

OMA = Object Management Architecture

IIOP = Internet Inter ORB Protocol

ORB = Object Request Broker ou Courtier en Requêtes Objet

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-24
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Avant SOA
id Avant SOA

Intégration avec liaisons EAI CRM Niveau client

Point-à-Point
Siebel API Siebel API

o Nombreuses dépendances Siebel

entre applications «logique métier»

Component1 «appli cliente»
o Couplage fort Component4
ERP
o Interfaces, données et
messages propriétaires
«logique métier»
SAP
o Complexité Component2
«appli cliente»
SAP API
Component5
o Travail identique fait SAP API

plusieurs fois
Serveur d'applications

o Adaptation aux «logique métier»

changements délicate Component3 Appli J2EE
«appli cliente»
API custom API Custom Component6
o Coûts de développement
élevés
Mainframe

Quelques acteurs
Appli
API Custom
o serveurs J2EE API Custom spécifique

o MS .NET

(c)Leuville Objects 2-25

Avant SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-26
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Avant SOA
id EAI

EAI / BPM Niveau client

o un bus centralise les

connexions et diffuse les «Appli VB» «Appli Java» «Appli web»

données Component7 Component8 Component9

o les connexions se font à

travers des API
propriétaires et/ou
spécifiques
Middleware ou bus de messages
o les échanges se font selon
des formats propriétaires
et/ou spécifiques

Quelques acteurs C / C++ JAM IDOCs/BAPI RMI

CRM
o Weblogic Integration de Mainframe ERP
Serveur d'applications
BEA Systems

o Websphere MQ Siebel Appli SAP Appli J2EE

spécifique
Worksflow d’IBM

o BizTalk de Microsoft

o webMethods, Tibco, ...

(c)Leuville Objects 2-27

Avant SOA

Notes

EAI = Enterprise Applications Integration ou intégration d’applications d’entreprise

BPM = Business Process Management

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-28
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

SOA

Approche architecturale au niveau de l’entreprise

o Ensemble de services qui communiquent à travers un réseau

o faiblement couplés

o possédant des interfaces bien définies et indépendantes des plateformes

o réutilisables

o Développement organisé à un plus haut niveau d’abstraction

o centré sur les processus métier

o tourné vers les échanges inter-entreprises et organisations

o masque la complexité technique

o Basé sur des technologies et mécanismes standards

o XML (toujours)

o WebServices (le plus souvent)

SOA = EAI + patterns normalisés ?

(c)Leuville Objects 2-29

SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-30
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

SOA

Protocoles

o Format de données XML du W3C

o Invocation de services avec SOAP (W3C)

o Description de services avec WSDL (W3C)

o Annuaire de services avec UDDI (OASIS)

Complétés par

o Sécurité avec les normes comprises dans WS-Security

o Orchestration avec WS-BPEL et/ou WS-CDL

o Gestion transactionnelle avec WS-Coordination

(c)Leuville Objects 2-31

SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-32
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Le nouveau modèle induit par SOA

Des composants aux services

Architecture de composants distribués Architecture orientée services - SOA

Orientation fonctionnalités Orientation processus métier
Prévus pour durer Prévue pour supporter le changement
Cycles de développement plus longs Cycles plus courts et interactifs
Centrée sur les coûts Centrée sur les activités métier
Sémantique de haut niveau par agrégation et Orchestration et chorégraphie des services
blocs applicatifs
Couplage fort Couplage faible
Technologie homogène Technologie hétérogène
Orientation Objet Orientation message
Dépendance avec l’implémentation Abstraction plus forte

(c)Leuville Objects 2-33

Le nouveau modèle induit par SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-34
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Avantages des stratégies SOA

Organisation du SI autour de services et non d’applications

o Agilité, capacité à s’adapter rapidement au changement

o Meilleure productivité

o Réalisation rapide de nouveaux services métier

o Meilleure réactivité opérationnelle

o Interopérabilité

Retours d’expériences insuffisants

o De nombreux avantages supposés restent à confirmer

o adoption encore lente

o pas assez de projets réellement SOA pour avoir des informations significatives

(c)Leuville Objects 2-35

Avantages des stratégies SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-36
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Pièges liés à l’adoption de SOA

Sur un plan organisationnel

o Ne pas impliquer la totalité de l’organisation

o Considérer qu’il ne s’agit que d’une n-ième technique informatique

o Minorer l’importance de l’identification précise des processus métier de l’organisation

o Minorer le besoin en formation (BPMN)

o Ne pas établir de gouvernance du portefeuille de services

o Ne pas repenser l’articulation entre métiers et informatique, ainsi que le fonctionnement même des équipes
projet côté informatique

o Penser que la mise en place et le retour sur investissement seront rapides

o Minorer l’importance du volet technique

(c)Leuville Objects 2-37

Pièges liés à l’adoption de SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-38
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Pièges liés à l’adoption de SOA

Sur un plan technique

o Bâtir une architecture SOA comme une architecture distribuée

o avoir des couplages forts, avec des services RPC et/ou synchrones

o Ne pas standardiser SOA au niveau de l’entreprise

o choisir des extensions WS-X incompatibles

o ne pas standardiser les formats de données

o Ne pas planifier la transition vers SOA

o Ne pas avoir normalisé l’emploi de XML préalablement

o plus important que l’emploi de web services

o n’est pas implicitement lié à l’utilisation de web services

o Traîter tardivement les surcoûts en termes de temps de traitements

o Minorer les problèmatiques de sécurité

o Minorer l’importance de l’offre produit et ne pas tenir compte des différences techniques inhérentes à ces
offres

(c)Leuville Objects 2-39

Pièges liés à l’adoption de SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-40
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Le bus ESB

Enterprise Service Bus = le A de SOA

o Gartner Group : "Une infrastructure adaptée aux services Web offrant un support intelligent du routage des
communications et de l’intermédiation entre des composants métier à liaison souple ou découplés."

o Forrester : "Un bus ESB est une infrastructure logicielle essentielle aux SOA tenant lieu de couche
intermédiaire de middleware à travers laquelle les services métiers réemployables sont rendus largement
disponibles."

Caractéristiques essentielles

o Basé sur les Services Web et XML

o Gestion fiabilisée des messages

o Mécanismes de transformation des données

o Routage intelligent des services et des messages

o Gestion de nombreuses connectivités : J2EE JMS, JCA, ... MS .NET, ...

o Outils d’administration

(c)Leuville Objects 2-41

Le bus ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-42
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Le bus ESB

Composants-clé selon Gartner Group

o un Middleware Orienté Messages ou MOM

o distribution fiable de messages

o couplage faible

o des Web Services

o abstraction de services métier

o indépendants des technologies

o un Routage Intelligent des messages

o basé sur les contenus et les contextes

o basé sur des règles métier

o des Transformations XML

o de type XSLT

(c)Leuville Objects 2-43

Un bus ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-44
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Le bus ESB
id ESB

«application» «application» «application»

.NET J2EE Legacy

«connecteur» «connecteur» «connecteur»

SOAP / HTTP JMS / JCA MQ Gateway

Enterprise Service Bus

«connecteur» «connecteur» Moteur de

SOAP / HTTP requêtes
SOAP / HTTP
distribué

«service» «webservice» «base de données»

Partenaire Fournisseur SGBD

(c)Leuville Objects 2-45

Le bus ESB

Notes

Ce type de bus rappelle d’anciennes propositions, comme les bus de type CORBA.

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-46
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Le bus ESB : mise en place incrémentale

cmp ESB - adoption incrémentale

«application» «application»
J2EE Legacy

PHASE 3
«connecteur» «connecteur»
JMS / JCA MQ Gateway

ESB ESB ESB ESB

«connecteur» «connecteur» «connecteur» Moteur de

SOAP / HTTP SOAP / HTTP SOAP / HTTP PHASE 2 requêtes PHASE 1
distribué

«service» «webservice» «application» «base de donné...

Partenaire Fournisseur .NET SGBD

(c)Leuville Objects 2-47

Le bus ESB : mise en place incrémentale

Notes

Un bus ESB peut être mis en place progressivement:

o d’abord en interne : backend, frontend, ...
o puis en externe : partenaires, fournisseurs, clients.

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-48
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Le routage des messages par le bus

Service existant
Bus ESB
Service Client

Service Métier
Service Proxy Service existant
routage

Service Client
Service Métier
Service existant

(c)Leuville Objects 2-49

Le routage des messages par le bus

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-50
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Web Oriented Architecture (WOA)

Variante d’une architecture SOA

o Internet employé comme unique support de service

o Plus de bus ESB

o Tous les services sont exposés sur Internet

o Tous les services sont accessibles à travers des Web Services

Avantages

o Pas d’outil spécifique à acquérir, configurer et exploiter

Inconvénients

o Pas de maîtrise complète : performances ? sécurité ?

o Pas d’administration spécifique

(c)Leuville Objects 2-51

Web Oriented Architecture (WOA)

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-52
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

La standardisation

Bases

o XML

o Web Services : SOAP, WSDL, UDDI

o Normes du WS-I

Une évolution continue

o Trois organismes de standardisation : W3C, OASIS, WS-I

o Un grand nombre de spécifications d’extensions WS-X

o non stabilisé

o propositions concurentes, exemple : WS-Reliability / WS-ReliableMessaging

o Pas de spécification "chapeau" qui englobe l’ensemble des spécifications WS-X

o Maturité de certaines spécifications WS-X envisagée pour 2010

Attention : choix délicats

(c)Leuville Objects 2-53

La standardisation

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-54
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

La standardisation

W3C OASIS WS-I

Date de création 1994 1993 : SGML Open 2002
1998 : OASIS
Nombre de membres 400 600 200
Objectifs Accompagner l’évo- Promouvoir le com- Promouvoir l’intero-
lution du web, en merce en ligne à pérabilité à l’aide de
définissant les stan- l’aide de standards standards appliqués
dards permettant appliqués au web ser- aux web services.
d’améliorer son usage vices.
professionnel et les
échanges d’informa-
tions.
Travaux principaux XML, XML Schema, UDDI, ebXML, Basic Profile, Basic
XQuery, XML SAML, XACML, Security Profile
Encryption, XML WS-BPEL, WS-Secu-
Signature, XPath, rity, ebSOA
XSLT, WSDL,
SOAP, WS-CDL,
WS-Addressing, Web
Services Architecture

(c)Leuville Objects 2-55

La standardisation

Notes

Les travaux de ces organismes sont souvent complémentaires, comme par exemple:
o WS-Security qui s’appuie sur XML Encryption, XML Sugnature, ...
o UDDI qui fait référence à WSDL,
o ...

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-56
 Architectures Orientées Services - Introduction aux architectures orientées services (SOA) Version 5.1

Synthèse

Alignement entre SI et processus métier

(c)Leuville Objects 2-57

Synthèse

Notes

Schéma selon http://www.urbanisation-si.com/

(c) Leuville Objects Architectures Orientées Services - Introduction aux architectures orientées services (SOA) 2-58
Architectures Orientées Services Version 5.1
Introduction aux microservices

o Concepts sous-jacents

o Liens avec les architectures SOA

o Acteurs et outils

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Introduction aux microservices 3-60
 Architectures Orientées Services - Introduction aux microservices Version 5.1

Constats

Les problèmes des gros projets

o Surnommés monolithes par les tenants de l’approche microservices

o Complexité

o liée directement à la taille du code

o impacte la fiabilité

o Frein à l’innovation

o causé par la nécessité de maintenir une cohérence: outils, techniques, ...

(c)Leuville Objects 3-61

Constats

(c) Leuville Objects Architectures Orientées Services - Introduction aux microservices 3-62
 Architectures Orientées Services - Introduction aux microservices Version 5.1

Microservices

Petits projets

o Petites équipes de sept personnes au miximum (pizza teams)

o Totalement indépendants

o Echanges par appels de services / envois de messages

o Chaque projet dispose de son équipe, son code et ses données

Basés sur

o Certains concepts des architectures SOA

o Les méthodes agiles et le lean startup

o L’industrialisation des déploiements, la virtualisation et la conteneurisation, le DevOps

o De nouvelles techniques moins contraignantes comme les bases NoSQL

(c)Leuville Objects 3-63

Microservices

(c) Leuville Objects Architectures Orientées Services - Introduction aux microservices 3-64
 Architectures Orientées Services - Introduction aux microservices Version 5.1

Microservices

D’après www.martinfowler.com

(c)Leuville Objects 3-65

Microservices

(c) Leuville Objects Architectures Orientées Services - Introduction aux microservices 3-66
 Architectures Orientées Services - Introduction aux microservices Version 5.1

Microservices

(c)Leuville Objects 3-67

Microservices

(c) Leuville Objects Architectures Orientées Services - Introduction aux microservices 3-68
 Architectures Orientées Services - Introduction aux microservices Version 5.1

Microservices

Exemple

o D’après www.microservices.io

(c)Leuville Objects 3-69

Microservices

De nombreux patterns sont disponibles sur ce site.

(c) Leuville Objects Architectures Orientées Services - Introduction aux microservices 3-70
 Architectures Orientées Services - Introduction aux microservices Version 5.1

Liens avec SOA

Mêmes objectifs et similitudes

o Normalisation des échanges

o Couplage faible

o Diminution de la complexité (applications -> services)

o Possibilité d’avoir un modèle d’architecture de type publish-subscribe avec un bus de messages/évènements

Différences

o Domaines métier beaucoup plus petits

o Chaque projet peut faire ses choix techniques propres

o Pas forcément de format pivot

o Orchestration moins identifiable

o Gouvernance à priori plus simple

o Difficultés

o comment gérer les transactions partagées entre applications ?

o comment fournir la haute disponibilité de l’ensemble ?

(c)Leuville Objects 3-71

Liens avec SOA

(c) Leuville Objects Architectures Orientées Services - Introduction aux microservices 3-72
 Architectures Orientées Services - Introduction aux microservices Version 5.1

Modèles d’architectures

Microservices de type REST

o API normalisées entre applications avec contrats d’interfaces constants

o Liaisons point-à-point

o Modèle limité aux infrastructures de petite taille

(c)Leuville Objects 3-73

Modèles d’architectures

(c) Leuville Objects Architectures Orientées Services - Introduction aux microservices 3-74
 Architectures Orientées Services - Introduction aux microservices Version 5.1

Modèles d’architectures

Utilisation d’un bus de messages

o Possibilités techniques

o JMS

o STOMP

o MQTT

o Modèle plus adapté aux infrastructures de taille moyenne ou importante

(c)Leuville Objects 3-75

Modèles d’architectures

(c) Leuville Objects Architectures Orientées Services - Introduction aux microservices 3-76
 Architectures Orientées Services - Introduction aux microservices Version 5.1

Utilisateurs

Plusieurs "gros" utilisateurs

o Amazon

o Google

o Netflix

o Twitter

o IBM Bluemix

(c)Leuville Objects 3-77

Utilisateurs

(c) Leuville Objects Architectures Orientées Services - Introduction aux microservices 3-78
Architectures Orientées Services Version 5.1
Introduction aux Services Web

o Services Web : principes de base

o Les besoins qui expliquent l’avènement des Web Services

o Services WEB et protocoles associés : SOAP, WSDL, UDDI

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-80
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Les services WEB

Les besoins

o Permettre les échanges inter-entreprises et inter-systèmes

o Avoir une réelle inter-opérabilité indépendante des contraintes techniques : système, langage, ...

o Ne pas perturber l’existant au niveau des infrastructures de gestion de la sécurité

La solution

o Utiliser l’existant plutot qu’imposer des changements

o Protocoles Internet déjà répandus, comme HTTP et HTTPS

o Format de données XML

o Constituants essentiels

o Un protocole de requétage basé sur un format de données universel : XML et pouvant utiliser HTTP :
SOAP

o Un langage de description des services : WSDL

o Un système d’annuaire : UDDI

(c)Leuville Objects 4-81

Les services WEB

Les besoins

L’inter-opérabilité des systèmes et des applications est un souhait partagé depuis très longtemps par de
nombreuses organisations et entreprises. Jusqu’à présent, les technologies permettant l’invocation distante
de services comportaient de très nombreuses contraintes qui rendaient difficile leur utilisation:
o incompatibilité des protocoles de communication : CORBA avec DCOM par exemple,
o incapacité à traverser les protections pare-feu des entreprises sans modification des règles de sécurité,
o lourdeurs de développement et de mise en oeuvre.

La solution

L’idée forte des services WEB consiste à utiliser ce qui existe déjà au niveau des entreprises plutôt qu’à
proposer de nouvelles solutions trop contraignantes en termes d’équipements et de procédures:
o XML qui est un format de données largement accepté et répandu,
o HTTP qui est un procole de communication universel pour lequel les procédures de sécurité réseau des
entreprises sont déjà adaptées.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-82
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Bénéfices des services WEB

o Intégrer des plate-formes techniques incompatibles jusqu’à maintenant

o Ouvrir l’entreprise à ses fournisseurs, ses partenaires et ses clients en exposant ses services à travers des
protocoles simples et normalisés

o S’adapter aux changements plus facilement et plus rapidement

J2E E J2E E
F O U R N ISSEU R C oupe-feu
P R O D U C T IO N

PERL

F O U R N ISSEU R
C oupe-feu

.N E T

C ++ C oupe-feu

C oupe-feu AD M IN IST R AT IO N
T R AN SPO R T EU R

(c)Leuville Objects 4-83

Bénéfices des services WEB

Avant l’avénement des services WEB, il était assez complexe de développer des mécanismes d’échanges
inter-applications en milieu hétérogène. Ainsi, pour par exemple communiquer entre un serveur Corba sous
Unix et un serveur DCOM sous Windows, il fallait utiliser des passerelles propriétaires et difficiles à mettre
en oeuvre.

S’affranchir des technologies sous-jacentes rend virtuellement possible une inter-opérabilité extrémement
grande entre systèmes d’informations du monde entier.

Cette liberté (relative !) donne aussi la possibilité de suivre plus facilement les évolutions technologiques
sans rompre le contrat applicatif qui peut exister envers les utilisateurs d’un système d’informations.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-84
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Les constituants d’une architecture à base de services WEB

SOAP : Simple Object Access Protocol

o Protocole requete-réponse d’invocation des services WEB

o Synchrone ou asynchrone

o Basé sur XML

WSDL : Web Service Description Language

o Langage de description technique d’un service WEB : signatures des opérations, adresses, ...

o S’apparente au langage de description de services de CORBA : IDL

UDDI : Universal Description Discovery and Integration

o Système d’annuaire normalisé de services WEB

o système d’enregistrement de services

o système d’interrogation

(c)Leuville Objects 4-85

Les constituants d’une architecture à base de services WEB

SOAP

SOAP est le protocole d’invocation d’un service WEB. Il a été défini de façon à pouvoir être mis en oeuvre
avec n’importe quelle technologie de développement. Il suffit de pouvoir:
o ouvrir une socket de communication vers le serveur hébergeant le service WEB,
o lui transmettre une requête formattée en XML, donc essentiellement textuelle,
o analyser une réponse également formattée en XML.

WSDL

Cette description comporte notamment:

o les coordonnées du service : URL, numéro de port, protocole, ...
o la signature du service : nom, types des paramètres, ...

UDDI

UDDI est une spécification élaborée par IBM, Microsoft et Ariba. Elle normalise le fonctionnement d’un
annuaire permettant d’enregistrer des descriptions WSDL et de les restituer à différents utilisateurs.

Les annuaires UDDI peuvent être de deux types:

o accessibles à tout utilisateur à partir d’Internet,
o locaux à une entreprise ou à une organisation.
(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-86
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Principes de fonctionnement

Recherche du service

1 Annuaire UDDI

description WSDL <une balise>

... ... ...
</une balise> Enregistre le service
Client dans l’annuaire

Fournisseur du service
Requête SOAP

Proxy SOAP Réponse SOAP Frontal SOAP Objet Métier / application : J2EE, .NET,

o L’usage de l’annuaire est optionnel

(c)Leuville Objects 4-87

Principes de fonctionnement

Le fournisseur du service WEB peut l’enregistrer au sein d’un annuaire UDDI, soit à l’intérieur de son
entreprise, soit à l’extérieur si ce service est destiné à être utilisé par des acteurs externes.

Un client est alors en mesure d’interroger l’annuaire à partir de critères qui lui sont propres pour obtenir la
description WSDL du service WEB.

Cette description permet d’automatiser et donc de simplifier la phase de requêtage via SOAP. En effet, de
nombreux outils permettent de produire des proxy d’interrogation des services WEB à placer côté client
afin de masquer les complexités de SOAP.

Un service WEB peut être réalisée avec n’importe quelle technologie de développement. Les serveurs
d’applications de type J2EE ou .NET proposent généralement des mécanismes permettant de simplifier
énormément la réalisation d’un service WEB. Il s’agit la plupart du temps de frontaux SOAP générés
automatiquement qui permettent au concepteur de se concentrer sur le développement de ses objets métier.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-88
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Pile Web Services

(c)Leuville Objects 4-89

Pile Web Services

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-90
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Pile Web Services

(c)Leuville Objects 4-91

Pile Web Services

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-92
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Pile Web Services

(c)Leuville Objects 4-93

Pile Web Services

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-94
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

SOAP

Protocole léger d’échange d’informations

o Messages dont la structure est basée sur XML

o Attachements possibles pour les données

binaires

o Produits et analysés automatiquement

o Normalisation des requêtes distantes et des

réponses

o Synchronisme ou asynchronisme

o Règles d’encodage et de décodage des types de données

o Correspondances normalisées avec les types primitifs de tous les langages de programmation

o Mécanismes de sérialisation - désérialisation pour les types complexes

Ne normalise pas certaines modalités d’échanges évoluées

o Sessions et Transactions

o Sécurité intrinsèque

o Fiabilité de la transmission

(c)Leuville Objects 4-95

SOAP

Protocole léger d’échange d’informations

SOAP est un protocole simplifié d’invocation de services à distance. Il normalise donc uniquement ce qui
est strictement indispensable.

Ne normalise pas certaines modalités d’échanges évoluées

SOAP comporte plusieurs limitations:

o l’absence de mécanisme intrinsèque permettant de gérer les différents aspects de la sécurité:
o authentification et droits d’accès
o confidentialité
o l’absence de mécanisme intrinsèque de gestion des sessions applicatives
o l’absence de prise en charge des transactions globales ou transactions distribuées.

Cependant, plusieurs groupes de travail se sont constitués afin de faire des propositions dans ces différents
domaines. Nous les exposerons dans la suite de ce document.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-96
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Structure d’un message SOAP

o Enveloppe de communication
souvent basée sur HTTP

o Un header pour tous les aspects non

normalisés : gestion de session par
exemple

o Un body comportant les

informations sur le service appelé,
les paramètres effectifs, ...

o Des attachements optionnels pour

les données binaires

(c)Leuville Objects 4-97

Structure d’un message SOAP

SOAP normalise la structure des messages de définition des requêtes et des réponses.

Cette structure comporte notamment:

o Une enveloppe de communication correspondant au protocole utilisé pour acheminer les données. Ce
protocole n’est pas normalisé par SOAP et peut théoriquement être de toute nature. En pratique, on
rencontre couramment HTTP ou HTTPS.
o Une zone d’entête utilisée pour transmettre des informations complémentaires non prévues par le
standard comme par exemple un identifiant de session applicatice.
o Un corps permettant de transmettre le message lui-même, qu’il s’agisse d’une requête ou d’une réponse.
o Un ou plusieurs attachements optionnels (à partir de SOAP 1.1) qui permettent d’associer aux messages
des pièces jointes binaires, de façon similaire à un courrier électronique.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-98
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Un exemple de message SOAP

Requête Réponse

POST /StockQuote HTTP/1.1 HTTP/1.1 200 OK

Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8"
Content-Type: text/xml; charset="utf-8" Content-Length: nnnn
Content-Length: nnnn
SOAPAction: "Some-URI"

<SOAP-ENV:Envelope <SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body> <SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI"> <m:GetLastTradePriceResponse xmlns:m="Some-URI">
<symbol>DIS</symbol> <Price>34.5</Price>
</m:GetLastTradePrice> </m:GetLastTradePriceResponse>
</SOAP-ENV:Body> </SOAP-ENV:Body>
</SOAP-ENV:Envelope> </SOAP-ENV:Envelope>

(c)Leuville Objects 4-99

Un exemple de message SOAP

Comme le montre cet exemple, les deux messages SOAP correspondant respectivement à une requête et à
sa réponse sont assez verbeux. C’est un inconvénient mineur de SOAP.

Par contre, ils ont l’avantage d’être en format texte ce qui facilite la mise-au-point d’une solution à base de
services WEB.

En cas de nécessité d’une confidentialité accrue, on pourra utiliser HTTPS à la place de HTTP.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-100
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

WSDL

Format XML de description de services réseau

o Défini à l’initiative d’IBM et de Microsoft

o Particulièrement adapté à la description des services WEB

o Description comportant:

o informations concernant la localisation du service : adresse,

numéro de port, procole, ...

o description de la structure des requêtes et réponses associées

o description des opérations disponibles : noms, paramètres,

types, ...

o informations sur les types de données nécessaires pour les

arguments et les valeurs de retour

(c)Leuville Objects 4-101

WSDL

Format XML de description de services réseau

WSDL a été défini par IBM et Microsoft dans le but de fournir un moyen de décrire des services applicatifs
accessibles par réseau. Ces services sont invocables par l’intermédiaire de messages dont le format est
défini à l’aide de WSDL.

Un document WSDL peut contenir:

o Types– des définitions de types basées sur un formalisme de définition tel que XSD.
o Message– une définition abstraite des données à communiquer.
o Operation– une définition abstraite des actions supportées par le service.
o Port Type– un ensemble d’opérations abstraites supportées par les points d’entrée du service.
o Binding– une définition concrète d’un protocole et d’un format de données pour un Port Type.
o Port– un point d’entrée défini comme une combinaison d’un Binding et d’une adresse réseau.
o Service– un ensemble de points d’entrée.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-102
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

WSDL

Message Exchange Patterns

o Spécifient les modalités du dialogue

o 4 dans WSDL 1.1

o requête client / réponse serveur synchrone

o invocation par le client sans retour (One Way)

o requête serveur / réponse client synchrone

o invocation par le serveur sans retour

o Enrichis dans WSDL 2.0

WS-Policy

o Politique de sécurité applicable

(c)Leuville Objects 4-103

WSDL

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-104
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Exemple WSDL

Entête et définition des types

<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType>
</element>
<element name="TradePrice">
<complexType><all> <element name="price" type="float"/> </all> </complexType>
</element>
</schema>

(c)Leuville Objects 4-105

Exemple WSDL

Entête et définition des types

L’entête d’un document WSDL comporte des références à différents espaces de nommage, identifiés par
une URL et un préfixe:
o wsdl : http://schemas.xmlsoap.org/wsdl/WSDL namespace pour le framework WSDL.
o soap : http://schemas.xmlsoap.org/wsdl/soap/ WSDL namespace pour le binding WSDL SOAP.
o http : http://schemas.xmlsoap.org/wsdl/http/ WSDL namespace pour le binding WSDL HTTP GET &
POST.
o mime : http://schemas.xmlsoap.org/wsdl/mime/ WSDL namespace pour le binding WSDL MIME.
o soapenc : http://schemas.xmlsoap.org/soap/encoding/ namespace d’encodage SOAP 1.1.
o soapenv : http://schemas.xmlsoap.org/soap/envelope/ namespace de définition de l’enveloppe SOAP 1.1.
o xsi : http://www.w3.org/2000/10/XMLSchema-instance namespace d’instance XSD.
o xsd : http://www.w3.org/2000/10/XMLSchema namespace de schéma XSD .
o tns : “this namespace” (tns) référence le document courant par convention.

La partie réservée à la définition des types peut être écrite en utilisant XSD.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-106
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Exemple WSDL

Message et portType

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

(c)Leuville Objects 4-107

Exemple WSDL

Message et portType

Une opération est définie par association de deux messages, l’un en entrée et l’autre en sortie.

Elle permet de constituer un élément appelé portType.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-108
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Exemple WSDL

Binding et service

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input> <soap:body use="literal"/> </input>
<output> <soap:body use="literal"/> </output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

(c)Leuville Objects 4-109

Exemple WSDL

Binding et service

Le binding associe une opération à un protocole de transport, HTTP sur cet exemple.

Le service associe un binding et une adresse, sous la forme d’une URL.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-110
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

UDDI

o Fonctionnement comparable aux DNS réseau

Publication de services WEB

o Permet la création, l’édition et la suppression d’enregistrements via des messages SOAP avec accès sécurisé

o Publisher API

Recherche de services WEB

o Accessible par l’intermédiaire de SOAP

o Quatre types d’informations définies avec XML schéma

o <businessEntity> : identification d’une entreprise ou d’une organisation permettant une recherche de

type "Pages blanches"

o <businessService> : informations métier sur un service particulier ("Pages jaunes")

o <bindingTemplate> : éléments techniques indispensables à l’invocation du service ("Pages vertes")

o <tModels> : références aux spécifications utilisées

o Inquiry API

(c)Leuville Objects 4-111

UDDI

La spécification UDDI a été établie suite aux travaux initiaux de Ariba, IBM et Microsoft. Elle définit un
accès programmatique normalisé à des services métier invocables indépendamment des technologies.

Les registres UDDI fonctionnent avec un système de réplication d’informations, à la façon des serveurs
DNS, afin d’offrir une fiabilité maximale.

Publication de services WEB

Le volet publication de la spécification UDDI prévoit plusieurs modalités de publication d’un service WEB:
o l’utilisation d’une API dédiée qui permet d’automatiser cette t,
o l’utilisation d’un service en ligne avec une interface de type WEB, de façon analogue à ce que certains
moteur de recherche proposent sur Internet.

Recherche de services WEB

Dans le cadre d’échanges de type B2B, la présence d’une API normalisée de recherche est indispensable.

Cette API permet d’accèder aux pages blanches et jaunes d’un registre, mais également à sas pages vertes,
ce qui permet d’automatiser la recherche et l’invocation d’un service WEB.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-112
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Historique des services WEB

o 1992 : naissance de HTML o 2002 : définition de WSCI 1.0 (Web Service

Choregraphy Interface) par Sun Microsystems,
o 1994 : création du W3C (World Wide Web BEA Systems, Intalio, SAP
Consortium)
o 2002 : UDDI 3.0
o 1996 : document de travail XML
o Avril 2002 : définition de WS-Security par
o 1997 : adoption de XML par Microsoft Microsoft, IBM, Verisign
o 1998 : XML 1.0 par le W3C o Août 2002 : Business Process Execution Language for
Web Services (BPEL4WS)
o 1999 : SOAP 0.9 par DevelopMentor,
Microsoft, Userland o Octobre 2002 : WS-Coordination et WS-
Transactions par IBM et Microsoft
o 1999 : SOAP 1.0 soumis à l’IETF
o 2003 : SOAP 1.2
o 2000 : SOAP 1.1 contributions IBM

o 2001 : 28 groupes de travail au W3C !

o 2001 : soumission de WSDL au W3C à

l’initiative de IBM et Microsoft

o 2001 : soumission de Business Transaction

Protocol à l’OASIS par BEA Systems

(c)Leuville Objects 4-113

Historique des services WEB

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-114
 Architectures Orientées Services - Introduction aux Services Web Version 5.1

Les enjeux

Standardisation

o Des acteurs ambitieux : IBM, Microsoft, Sun, BEA, ...

o De multiples organismes de normalisation : W3C, OASIS, WS-I

o La promesse initiale de l’interopérabilité sera-t-elle tenue ?

Evolutions importantes

o WSCI : description du comportement des services Web (dépendances logiques, règles, ...)

o WS-Transactions : prise en charge des transactions distribuées sur plusieurs services Web

o WS-Security : sécurité intrinsèque

o Description des processus B2B : ebXml, BPEL4WS

o Architectures Orientées Services ou SOA - Services Oriented Architectures

(c)Leuville Objects 4-115

Les enjeux

Standardisation

Devant la multiplication des alliances de circonstances et des propositions de standards, on peut

légitimement s’inquiéter de l’universalité des services Web.

Evolutions importantes

Au départ, les services Web comportaient le minimum de ce qu’il fallait pour faire des invocations inter-
applications sur le Web. Ces mécanismes initiaux ne proposaient pas ce qui est indispensable pour
supporter un fonctionnement de type B2B:
o les transactions distribuées
o des mécanismes de sécurité
o une sémantique riche.

Devant l’importance des enjeux, de nombreux fournisseurs tentent de prendre une longueur d’avance en
proposant différentes solutions, généralement au travers d’alliances de circonstance.

(c) Leuville Objects Architectures Orientées Services - Introduction aux Services Web 4-116
Architectures Orientées Services Version 5.1
Representational state transfer

o Philosophie des systèmes RESTful

o Concepts REST d’après Roy T. Fielding

o Comparaison avec les services webs SOAP

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-118
 Architectures Orientées Services - Representational state transfer Version 5.1

Representational state transfer (REST)

REST est :

o Un style d’architecture.

o Une manière de construire une application pour les systèmes distribués.

o Un terme inventé par Roy T. Fielding en 2000.

REST n’est pas :

o Une technologie.

o Un protocole.

o Un format d’échange de données.

Les principes de base de REST

o L’URI est suffisant pour accéder à une ressource.

o Les méthodes HTTP (GET, POST, PUT, DELETE) sont suffisantes.

o Chaque opération est auto-suffisante (stateless).

o Les standards hypermedia (HTML et XML) sont à privilégier.

(c)Leuville Objects 5-119

Representational state transfer (REST)

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-120
 Architectures Orientées Services - Representational state transfer Version 5.1

Architecture RESTful

Les systèmes suivant les principes de REST sont dits RESTful

o Les systèmes RESTful permettent aussi de créer

o des applications à destination d’utilisateurs

o des modes de communication entre applications.

o REST est une alternative (simple) aux architectures RPC et à SOAP.

o REST n’impose pas de format de données particulier

o XML est recommandé

o JSON est également souvent utilisé.

(c)Leuville Objects 5-121

Architecture RESTful

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-122
 Architectures Orientées Services - Representational state transfer Version 5.1

Architecture RESTful

Première définition par Roy Thomas Fielding

o Les fondamentaux ont été posés par Roy Thomas Fielding dans sa thèse "Architectural Styles and the Design
of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000"

o Roy Fielding est un informaticien américain.

o Il a participé à la spécification HTTP.

o Il est l’un des membres fondateurs de la fondation Apache.

o Il a participé au développement du serveur web Apache.

o Il travaille actuellement sur le protocole Waka, extension de HTTP permettant d’intégrer des
fonctionnalités sémantiques et dynamiques (Web 3.0).

(c)Leuville Objects 5-123

Architecture RESTful

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-124
 Architectures Orientées Services - Representational state transfer Version 5.1

Architecture RESTful

Ce qui suit est un extrait de la thèse de Roy Fielding, posant les bases de REST

Le modèle vide

o Roy Fielding présente REST comme une architecture s’adaptant à plusieurs contraintes.

o Pour expliquer REST, il part d’un modèle vide (null model) puis le complète au fur et à mesure.

(c)Leuville Objects 5-125

Architecture RESTful

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-126
 Architectures Orientées Services - Representational state transfer Version 5.1

Architecture RESTful

Client-Serveur

o Séparation de l’interface utilisateur et du stockage des données.

o Amélioration de la portabilité de l’interface utilisateur.

o Possibilité de montée en charge.

o Evolutions séparées des composants.

(c)Leuville Objects 5-127

Architecture RESTful

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-128
 Architectures Orientées Services - Representational state transfer Version 5.1

Architecture RESTful

Sans état (Stateless)

o Communication sans état (CSS : Client-Stateless-Server).

o Chaque requête du client vers le serveur contient toutes les informations nécessaires à sa compréhension.

o Aucun contexte stocké coté serveur. Etat de la session entièrement détenu par le client.

(c)Leuville Objects 5-129

Architecture RESTful

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-130
 Architectures Orientées Services - Representational state transfer Version 5.1

Architecture RESTful

Cache

o Gestion d’un cache coté client pour améliorer les performances.

o Chaque réponse est marquée (implicitement ou explicitement) comme pouvant être mise en cache (cacheable)
ou non.

Le modèle Client-Serveur sans état avec gestion de cache est celui du web standard.

(c)Leuville Objects 5-131

Architecture RESTful

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-132
 Architectures Orientées Services - Representational state transfer Version 5.1

Architecture RESTful

Interface uniforme

o Les données échangées sont les mêmes quelque soit le type de client.

o L’interface du service est la même quelque soit l’implémentation du service.

o Avantages :

o Indépendance des évolutions.

o Système simplifié.

o Inconvénients :

o Pénalise l’efficacité (optimum pour les applications web, non optimum pour les autres applications)

(c)Leuville Objects 5-133

Architecture RESTful

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-134
 Architectures Orientées Services - Representational state transfer Version 5.1

Architecture RESTful

Système en couches

o Architecture composée de couches hiérarchiques.

o Chaque composant ne voit que la couche immédiate avec laquelle il agit.

o Chaque couche peut encapsuler des services.

(c)Leuville Objects 5-135

Architecture RESTful

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-136
 Architectures Orientées Services - Representational state transfer Version 5.1

Architecture RESTful

Code à la demande

o Le client a la possibilité de télécharger du code qui vient l’enrichir.

o Amélioration de l’extensibilité du système.

o Le code à la demande est cependant une contrainte optionnelle.

(c)Leuville Objects 5-137

Architecture RESTful

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-138
 Architectures Orientées Services - Representational state transfer Version 5.1

Architecture RESTful

Résumé de la dérivation de modèle

o Le schéma ci-dessous présente les différentes combinaisons des concepts de REST et les propriétés des
architectures résultantes.

(c)Leuville Objects 5-139

Architecture RESTful

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-140
 Architectures Orientées Services - Representational state transfer Version 5.1

Elément architecturaux de REST

Representational State Transfer

o Abstraction des éléments architecturaux d’un système réparti hypermédia.

o Indépendant des détails de mise en oeuvre des composants et de syntaxe de protocole.

o Se concentre sur les rôles des composants, les contraintes sur leur interaction avec d’autres composants, et leur
interprétation des éléments de données signifactives.

o Englobe les contraintes fondamentales sur les composants, les connecteurs et les données qui définissent la
base de l’architecture du Web.

(c)Leuville Objects 5-141

Eléments architecturaux de REST

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-142
 Architectures Orientées Services - Representational state transfer Version 5.1

Services REST vs Services SOAP

REST SOAP
Orientation Ressource Service
Protocole HTTP Au choix (en théorie, HTTP unique-
ment selon WS-I)
Messages Pas de format unique (XML, JSON, format SOAP (XML + pièces attachées)
HTML, PDF, ...)
Description / Métadonnées du WADL (optionnel) WSDL, WS-Policy, WS-Metadata
service
Description / Métadonnées du En-têtes HTTP Header SOAP (WS-*)
message
Sécurité HTTPS + authentification HTTP WS-Security
Organismes de standardisa- IETF (RFC2616 et autres RFC) W3C, Oasis, WS-I
tion

(c)Leuville Objects 5-143

Services REST vs Services SOAP

Notes

(c) Leuville Objects Architectures Orientées Services - Representational state transfer 5-144
Architectures Orientées Services Version 5.1
HATEOAS (Hypermedia as the Engine of Application State)

o Le modèle de maturité de Richardson

o Concepts HATEOAS

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) 6-146
 Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) Version 5.1

Le modèle de maturité de Richardson

http://martinfowler.com/articles/richardsonMaturityModel.html

(c)Leuville Objects 6-147

Le modèle de maturité de Richardson

Notes

(c) Leuville Objects Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) 6-148
 Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) Version 5.1

Le modèle de maturité de Richardson

Ce modèle définit 4 niveaux. Seul le niveau 3 désigne une véritable API RESTful.

Niveau 0 : Le RPC sur HTTP en POX (Plain Old XML)

o Utilisation d’un protocole de transport (ici HTTP) pour interagir avec un service. Toutes les requêtes sont
envoyées vers le même endpoint (URI) et sont décrites en XML (SOAP, XML-RPC...).

Niveau 1 : L’utilisation de ressources différentiées

o Introduction de la notion de ressource. Ici, les requêtes sont envoyées à des ressources individuelles. Le service
est alors éclaté en plusieurs ressources.

Niveau 2 : L’utilisation des verbes et des codes retours HTTP

o Les ressources sont manipulées à l’aide d’un ensembles de verbes simples. Ceci permet de tirer pleinement
parti du procole utilisé (ici HTTP).

Niveau 3 : L’utilisation des contrôles hypermédia

o La notion de HATEOS est introduite ici. Le principe est simple : les transitions possibles vers les états suivants
sont fournies par des liens hypermédia.

(c)Leuville Objects 6-149

Le modèle de maturité de Richardson

Notes

o Le Richardson Maturity Model propose un fil conducteur permettant d’appréhender pas à pas les concepts sous-
jacents à une approche RESTFul :

o Niveau 1 : Gérer la complexité de notre système via l’approche « divide & conquer » en introduisant la
notion de ressource.

o Niveau 2 : Eliminer les variantes dans la façon de traiter les choses et de gérer des cas similaires de façon
semblable en introduisant un jeu de verbes standards pour manipuler les ressources.

o Niveau 3 : Auto-documenter le protocole et fournir un premier niveau de découvrabilité au travers de la

notion de HATEOAS.

o Le Richardson Maturity Model fournit aussi un biais intéressant pour évaluer la « RESTitude » d’une
architecture.

(c) Leuville Objects Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) 6-150
 Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) Version 5.1

REST / HATEOAS

Hypermedia as the Engine of Application State

o Contrainte/caractéristique REST liée au concept d’uniformité d’interface

o Un système REST est connu par le client uniquement par son URL initiale

o Pas de description statique de type WSDL

o Les possibilités sont découvertes dynamiquement

o Une représentation de ressource est décrite par un format hypermédia

o données

o liens permettant d’effectuer de nouvelles opérations

o Un client n’a pas forcément besoin de connaître le type d’une ressource

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

(c)Leuville Objects 6-151

REST / HATEOAS

(c) Leuville Objects Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) 6-152
 Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) Version 5.1

Hypermedia

Données + opérations possibles

o Exemple: résultat de la requête GET /account/12345

o état de la ressource

o opérations possibles en fonction de cet état (solde)

(c)Leuville Objects 6-153

Hypermedia

(c) Leuville Objects Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) 6-154
 Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) Version 5.1

Hypermedia

Les opérations dépendent de l’état

o Exemple: le compte est devenu débiteur

(c)Leuville Objects 6-155

Hypermedia

(c) Leuville Objects Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) 6-156
 Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) Version 5.1

Implémentations disponibles

Possibilités

o Spring HATEOAS,

o Yii 2 Framework

o Jersey

o Tastypie

o Eve

o Apigility (Zend Framework 2)

o Hateoas PHP library.

o API Platform, PHP framework based on hypermedia and Linked Data support with JSON-LD, Schema.org
and Hydra

(c)Leuville Objects 6-157

Implémentations disponibles

(c) Leuville Objects Architectures Orientées Services - HATEOAS (Hypermedia as the Engine of Application State) 6-158
Architectures Orientées Services Version 5.1
Enterprise Service Bus

o Les constituants fondamentaux d’un Enterprise Service Bus (ESB)

o MOM / Message-Oriented Middleware

o Web Services

o Routage intelligent

o Transformations XML

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-160
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Le bus ESB

Caractéristiques

o Technologie de middleware

o But premier: permettre la communication d’applications non conçues pour fonctionner ensemble

o Nouvelle génération d’EAI basée sur des standards

o messages : XML, XSLT, XPath

o web services : SOAP, WSDL, UDDI

o bus: JMS, JBI, JCA

o orchestration BPEL

Principes

o Communication par envoi de messages

o Forte distribution

o Découverte dynamique de services à l’aide d’un annuaire

o Chorégraphie des processus métier / orchestration des services

(c)Leuville Objects 7-161

Le bus ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-162
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Le bus ESB
id E S B

Composants-clé selon Gartner

« a p p l i ca ti o n »
Group .NE T
« a p p l i ca ti o n »
J2EE
« a p p l i ca ti o n »
Le ga c y

o Middleware Orienté Messages ou

MOM « co n n e cte u r» « co n n e cte u r» « co n n e cte u r»
S O AP / HTTP J M S / J CA M Q G a te w a y

E nte rpris e S e rv ic e Bus

o distribution fiable de messages

o couplage faible
« co n n e cte u r» « co n n e cte u r» M ote ur de
S O AP / HTTP re quê te s
S O AP / HTTP
o Web Services dis tribué

o abstraction de services métier « se rvi ce » « we b se rvi ce » « b a se d e d o n n é e s»

P a rte na ire Fournis s e ur S G BD

o indépendants des technologies

o Routage Intelligent des messages

o basé sur les contenus et les contextes

o basé sur des règles métier

o Transformations XML

o de type XPath et XQuery et/ou XSLT

(c)Leuville Objects 7-163

Un bus ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-164
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

MOM

o Message-Oriented Middleware

Caractéristiques principales
MOM
o Asynchronisme
Appli A 3 2 1 Appli B
o Files de stockage des messages
Client Client
o Différentes modalités d’émission / file d’attente des messages
producteur consommateur
réception des messages de message de message

Qualités

o Hétérogénéïté des applications clientes

o Couplage lâche

o Fiabilisation des échanges

o stockage des messages

o gestion des acquittements et qualité de service

(c)Leuville Objects 7-165

MOM

Définition

o Un MOM permet de manipuler des messages et de les échanger d’une application à une autre.
o Les applications communiquent entre elles via ce système de messagerie et n’ont donc pas besoin de se
"voir" les unes les autres.

Propriétés

o Les implémentations sont nombreuses. Parmis les fournisseurs :

o IBM WebSphere MQ
o BEA WebLogic Server JMS
o JBoss Messaging
o OpenJMS
o Ces systèmes proposent un fonctionnement en mode synchrone (attente et récupération des messages) ou
asynchrone (modèle Listener).
o Il est également possible de contrôler que tout message est traité une et une seule fois (politiques
d’acquittements). Le niveau de contrôle peut être réduit pour les applications acceptant la perte ou la
duplication de messages.

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-166
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

MOM : domaines de messagerie

Deux domaines de messagerie supportés, un type de destination pour chacun

o Point à Point (PTP)

o Publish / Subscribe

Messagerie Point à Point (PTP)

o Destination de type Queue

msg

consomme
envoie
Client 1 Queue Client 2
msg acquittement

(c)Leuville Objects 7-167

MOM : domaines de messagerie

Messagerie Point à Point

Messagerie Point à Point : Chaque message est adressé à une queue spécifique. Les clients lisent cette
queue afin d’en extraire les messages. Les queues conservent les messages qui leur sont envoyés jusqu’à ce
qu’ils soient lus ou périmés. Un message est consommé dès qu’il est lu par un client, quel qu’il soit.

Chaque message ne peut être consommé qu’une seul fois

Les processus emetteur et destinataire du message peuvent ne pas être exécutés en même temps. Le
message envoyé sera conservé jusqu’à ce que le destinataire l’extrait de la queue.

Le destinataire peut envoyer un message d’acquittement pour signaler la fin du traitement du message

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-168
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

MOM : domaines de messagerie

Système publication / souscription (publish/subscribe)

o Mode permettant la diffusion à plusieurs destinataires

o Destination de type Topic

souscrit

délivre Client 2
publie msg
Client 1 Topic
msg
souscrit
délivre Client 3
msg

(c)Leuville Objects 7-169

MOM : domaines de messagerie

Système publication / souscription (pub/sub)

Le message est publié dans un "Topic". Les destinataire du messages sont les clients ayant souscrit au topic.
Le système transmet automatiquement tout message souscrit dans un topic aux clients y ayant souscrit. Les
messages sont conservés le temps qu’ils soient distribués à tous les clients.

Chaque message peut être consommé plusieurs fois

Les clients souscrivant à un topic ne peuvent consommer que les messages ayant été publiés après leur
souscription. Le souscrivant doit être actif au moment de la publication du message pour que celui-ci lui
soit délivré.

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-170
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

MOM : exemple JMS

Java Message Service

o spécification permettant de découpler les clients Java d’un MOM d’un type de MOM particulier

o normalise:

o les domaines de messagerie

o les modalités de connexion au MOM

o les modalités d’émission / réception

o les formats des messages

o améliore la portabilité des applications

o implémentée par de nombreux fournisseurs

o IBM

o BEA

o JBoss

o ...

(c)Leuville Objects 7-171

MOM : exemple JMS

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-172
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

MOM : exemple JMS

Java Message Service

o Fournisseur JMS (JMS Provider) : implémentation de l’API JMS

o Client JMS : produit et/ou consomme des messages

o Message : objet véhiculant des informations entre clients JMS

o Objets administrés : les fabriques de connexion (Connection Factory) et les destinations sont configurées et
placées dans un contexte JNDI par un administrateur

(c)Leuville Objects 7-173

MOM : exemple JMS

Notes

Les fabriques de connexion et les destinations sont placées dans un espace de nommage JNDI par un
administrateur. Un client JMS peut alors récupérer une référence sur ces objets (look up) et établir une
connexion logique via le fournisseur JMS.

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-174
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Web Services

Les besoins

o Permettre les échanges inter- J2E E J2E E

entreprises et inter-systèmes F O U R N IS S E U R C o u p e -fe u
P R O D U C T IO N
o Avoir une réelle inter-opérabilité
indépendante des contraintes PERL
techniques : système, langage, ... F O U R N IS S E U R
C o u p e -fe u

.N E T
o Ne pas perturber l’existant au
niveau des infrastructures de C++ C o u p e -fe u

gestion de la sécurité
C o u p e -fe u A D M IN IS T R A T IO N
TRANSPO RTEUR

La solution

o Utiliser l’existant plutot qu’imposer des changements : HTTP et XML

o Constituants essentiels

o Un protocole de requétage basé sur un format de données universel : XML et pouvant utiliser HTTP :
SOAP

o Un langage de description des services : WSDL

o Un système d’annuaire : UDDI

(c)Leuville Objects 7-175

Web Services

Les besoins

L’inter-opérabilité des systèmes et des applications est un souhait partagé depuis très longtemps par de
nombreuses organisations et entreprises. Jusqu’à présent, les technologies permettant l’invocation distante
de services comportaient de très nombreuses contraintes qui rendaient difficile leur utilisation:
o incompatibilité des protocoles de communication : CORBA avec DCOM par exemple,
o incapacité à traverser les protections pare-feu des entreprises sans modification des règles de sécurité,
o lourdeurs de développement et de mise en oeuvre.

La solution

L’idée forte des services WEB consiste à utiliser ce qui existe déjà au niveau des entreprises plutôt qu’à
proposer de nouvelles solutions trop contraignantes en termes d’équipements et de procédures:
o XML qui est un format de données largement accepté et répandu,
o HTTP qui est un procole de communication universel pour lequel les procédures de sécurité réseau des
entreprises sont déjà adaptées.

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-176
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Routage Intelligent des messages

Exemple de scénario

Bus ESB
Service "Montants spéciaux"
routage
Emprunteur
Service de "haut niveau"
Service "Montants normaux"

o un client doit appeler un service permettant d’obtenir une offre de crédit bancaire

o en fonction du montant à emprunter, sa demande est routée soit vers un service "Montants spéciaux", soit vers
un service "Montants normaux"

Bus ESB = une sorte de routeur de messages

o Fonctionnalités minimales

o valider les messages entrants

o acheminer les messages en fonction de leur contenu

o agréger des résultats pour les retourner aux clients

o gèrer les erreurs

(c)Leuville Objects 7-177

Routage intelligent des messages

Notes

Ces possibilités ne sont pas normalisées pour le moment.

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-178
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Routage Intelligent des messages

Fonctionnalités avancées

o Pouvoir formaliser des processus métier à l’aide d’un langage:

o structurer un processus en plusieurs étapes

o déclarer et affecter des variables, à portée locale ou globale

o exécuter des tests

o faire des itérations

o gérer des états dépendants des utilisateurs

o appeler différents types de services pré-existants

o agréger des résultats intermédiaires

BPEL : Business Process Execution Language

o Permet de décrire des processus métier

o Standard

(c)Leuville Objects 7-179

Routage Intelligent des messages

Notes

BPEL est étudié dans un autre chapitre.

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-180
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Routage Intelligent des messages

Modalités de définition du routage

o Langage propriétaire

o Métaphore graphique

o Diagrammes UML (diagrammes d’activités)

o Processus BPEL

Possibilités très variables d’un bus à l’autre.

(c)Leuville Objects 7-181

Routage Intelligent des messages

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-182
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Routage Intelligent des messages: exemple

Routage basé sur le contenu

o Exemple BEA Aqualogic : routage en fonction d’un taux présent dans la requête entrante

(c)Leuville Objects 7-183

Routage Intelligent des messages: exemple

Routage basé sur le contenu

L’exemple présenté ici est exécuté au sein de Aqualogic Service Bus de BEA Systems.

L’expression permettant d’extraire le taux d’intérêt de la requête entrante est exprimé à l’aide de
XQuery/Xpath:

$body/exam:processLoanApp/loanRequest/java:Rate

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-184
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Routage Intelligent des messages: exemple

Appel de services intermédiaires

o Communication assurée par des variables

(c)Leuville Objects 7-185

Routage Intelligent des messages: exemple

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-186
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Routage Intelligent des messages: exemple

Itération

(c)Leuville Objects 7-187

Routage Intelligent des messages: exemple

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-188
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Transformations XML

ESB et XML

o Un ESB héberge des web services qui traitent des requêtes SOAP = XML

o Des données sont extraites de ces requêtes SOAP et envoyées à différents composants du SI, après
transformations éventuelles

o Les résultats sont agrégés

o Et renvoyés aux clients

Opérations souhaitées

o Ajout d’éléments XML

o Remplacement d’éléments par d’autres éléments

o Suppression d’éléments

Moyens techniques

o Langages basés sur XML

o XPath & XQuery

o XSLT

(c)Leuville Objects 7-189

Transformations XML

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-190
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Transformations XML

XPath

o Constituant principal du standard XSLT du W3C

o Permet de naviguer au sein d’un arbre XML

XQuery

o Permet d’exécuter des requêtes au sein de données XML

XSLT = XSL Transformations

o Permet de transformer un document XML en un autre document XML

(c)Leuville Objects 7-191

Transformations XML

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-192
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Transformations XML : insertion

o Insertion d’un arbre XML au sein d’un autre arbre XML

Exemple

<lg:CreditRating> ./exam:processLoanApp/loanRequest/lg:Notes
{data($creditRating)}
</lg:CreditRating>

(c)Leuville Objects 7-193

Transformations XML : insertion

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-194
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Transformations XML : remplacement

o Remplacement d’un arbre XML par un autre

o Remplacement d’une valeur ou d’un attribut

o Modification des références aux espaces de nommage

Exemple

o Renommage d’un namespace dans un corps de requête SOAP

(c)Leuville Objects 7-195

Transformations XML : remplacement

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-196
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Transformations XML : suppression

o Suppression d’un arbre XML

Exemple

o Suppression de l’élément CreditRating de la branche processLoanAppResponse/return

./exam:processLoanAppResponse/return/lg:CreditRating

(c)Leuville Objects 7-197

Transformations XML : suppression

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-198
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Architecture logique d’un bus ESB

BUS

Conteneur Conteneur
A BPM
Conteneur

Service A Service B
BAM

Web Services Web Services

Application A Application B

o Conteneur: support de la distribution des services

o Composants optionnels

o BPM: Business Process Management pour suivre l’orchestration des processus métier

o BAM: Business Activity Monitoring pour suivre l’activité d’un processus métier

(c)Leuville Objects 7-199

Architecture logique d’un bus ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-200
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Déploiement d’un bus ESB

Conteneurs

o Supports de la distribution des fonctions du BUS sur différentes machines

o Assimilables à un ensemble de processus serveurs répartis et fédérés par un protocole commun

deployment Bus ESB

Serv eur 1 Serv eur 2

Bus ESB

Conteneur 2 BPM
Admin Conteneur 1

Serv ice Serv ice

1 2 BAM

Web Service Web Service

Application 2
Application 1

(c)Leuville Objects 7-201

Déploiement d’un bus ESB

Notes

Les concepts des bus ESB ne sont pas sans rappeler les principes des ORB CORBA.

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-202
 Architectures Orientées Services - Enterprise Service Bus Version 5.1

Exemple de bus ESB

Aqualogic (BEA Systems)

(c)Leuville Objects 7-203

Exemple de bus ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Service Bus 7-204
Architectures Orientées Services Version 5.1
Les architectures et modèles SOA

o Modèles d’architecture SOA en couches

o Modèles d’intégration ou patterns

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-206
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Architecture SOA

Objectifs liés à la définition d’une architecture SOA

o S’organiser par niveaux d’abstraction

o Favoriser la réutilisation

o S’aligner sur les processus métier

Plusieurs propositions de modèles

o Modèle en trois couches de Thomas Erl

o Modèle BEA Systems

o Service Component Architecture (soumis à l’OASIS)

o ...

(c)Leuville Objects 8-207

Architecture SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-208
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Modèle trois couches de Thomas Erl

L’auteur

o Fondateur de la société SOA Systems Inc.

o Membre de l’OASIS disposant d’un droit de vote

o Auteur de nombreux ouvrages

Proposition d’architecture
(1) Business Process Layer
o (1) Business Process Layer
Processus métier de haut niveau

o (2) Service Interface Layer

(2) Orchestration Service Layer
o Orchestration Service Layer
Couche d’orchestration
(2) Business Service Layer
o Business Service Layer
Couche métier
(2) Application Service Layer
o Application Service Layer
Couche d’intégration

o (3) Application Layer (3) Application Layer

SI pré-SOA

(c)Leuville Objects 8-209

Modèle trois couches de Thomas Erl

Notes

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-210
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Modèle trois couches de Thomas Erl

Orchestration Service Layer

o Comporte des services métier alignés sur les règles métier

o Composition de services de la couche "Business Service Layer", voire de la couche inférieure

o Couche pensée en vue de la réutilisation

Business Service Layer

o Services métier

o Agissent comme des contrôleurs des services de la couche "Application Service Layer"

Application Service Layer

o Couche d’intégration comportant éventuellement des technologies spécifiques au SI sous-jacent

o Elaborée conformément au pattern Wrapper

(c)Leuville Objects 8-211

Modèle trois couches de Thomas Erl

Notes

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-212
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Modèle BEA

Le modèle architectural en
couches ou Layered
Architectural Model

o Couche = regroupement de
services similaires en termes de
finalité

o Couches typiques

o Services d’accès et
d’information

o Services métier partagés

o Services de présentation

o Applications composites

o Services d’infrastructure

Source BEA Systems

(c)Leuville Objects 8-213

Modèle BEA

Notes

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-214
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Services d’accès et d’information

o Couche d’intégration des architectures multi-niveaux

Accès standardisés cmp Couches SOA

o API et connecteurs normalisés : JCA, Web

Applications Composites
Services

A l’existant de l’entreprise
Serv ices de Présentation

o Systèmes tiers
Serv ices M étier Partagés
o Serveurs d’applications

o Applications d’entreprise Serv ices d'Accès et d'Information

o Systèmes existants : middlewares messages,

...

o Bases et entrepôts de données

SI existant

(c)Leuville Objects 8-215

Services d’accès et d’information

Notes

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-216
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Services métier partagés

Services de haut niveau cmp Couches SOA

o Utilisent la couche des services d’accès et

Applications Composites
d’information

o Contiennent éventuellement de la logique

d’orchestration et de coordination Serv ices de Présentation

Première des deux couches métier Serv ices M étier Partagés

o Processus métier simples

Serv ices d'Accès et d'Information
o Services à granularité fine

SI existant

(c)Leuville Objects 8-217

Services métier partagés

Notes

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-218
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Services de présentation

Services de fourniture d’une interface cmp Couches SOA

utilisateur
Applications Composites
o Proposent des composants réutilisables tels
que des portlets

o Permettent de construire des interfaces Serv ices de Présentation

orientées processus métier

o Peuvent être utilisées par plusieurs Serv ices M étier Partagés

applications de type portail

Serv ices d'Accès et d'Information

SI existant

(c)Leuville Objects 8-219

Services de présentation

Notes

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-220
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Applications composites

Seconde couche métier du modèle cmp Couches SOA

o Contient des applications complètes ou des

Applications Composites
composants permettant de construire des
applications

o Comporte les implémentations des Serv ices de Présentation

processus métier complexes multi-étapes

o S’appuie sur la couche des services métier Serv ices M étier Partagés

partagés

o Services à forte granularité Serv ices d'Accès et d'Information

SI existant

(c)Leuville Objects 8-221

Applications composites

Notes

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-222
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Services d’infrastructure

Services communs

o Gestion d’erreurs

o Gestion des traces

o Sécurité

Bus ESB

o Routage des messages

o Transformation de données

o Reprise sur panne

Administration

o Versionnage, gestion des déploiement, ...

o Qualité de service

(c)Leuville Objects 8-223

Services d’infrastructure

Notes

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-224
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Le pattern VETO ou VETRO

o VETO = Valider Enrichir Transformer Opérer

o VETRO = Valider Enrichir Transformer Router Opérer

Modèle d’intégration

o Permet de structurer l’emploi du bus par les différents clients

o Veille à limiter le couplage entre un service et ses utilisateurs

o Sur un plan technique, permet d’apparenter le processus d’intégration à un ensemble d’opérations de

paramétrage

o sélection des endpoints ou destinations des messages

o paramétrage des processus de validation, enrichissement et transformation

XSD - XPath - XQuery

(c)Leuville Objects 8-225

Le pattern VETO ou VETRO

Notes

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-226
 Architectures Orientées Services - Les architectures et modèles SOA Version 5.1

Le pattern VETO ou VETRO

Modèle d’emploi d’un bus ESB

o Validate : validation des données XML entrantes, par exemple avec un schéma XSD

o Enrich : ajout éventuel de données compémentaires, par appel à une source externe telle qu’un autre service,
une base de données, ...

o Transform : modification des données en vue de respecter le structure imposée par le service cible

o Route (optionnel) : choix du service cible en fonction de règles, par exemple sur le contenu ...

o Operate : envoi du message au service cible

(c)Leuville Objects 8-227
Le pattern VETO ou VETRO

Notes

http://webservices.sys-con.com/read/46170.htm

(c) Leuville Objects Architectures Orientées Services - Les architectures et modèles SOA 8-228
Architectures Orientées Services Version 5.1
Enterprise Integration Patterns : système de messagerie

o Utilité des modèles d’intégration

o Revue des différents patterns

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-230
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Enterprise Integration Patterns

o Modèles d’intégration pour l’entreprise.

o Solutions éprouvées pour la mise en oeuvre de communication entre systèmes.

o Concepts présentés sans contraintes sur les systèmes ou les langages utilisés.

o "Enterprise Integration Patterns", paru en janvier 2004, écrit par Gregor Hohpe & Bobby Woolf

Gregor Hohpe, Bobby Woolf,

Architecte logiciel chez Google, Inc. Membre de IBM Software Services for WebSphere.
Co-auteur de Enterprise Integration Patterns etEnterprise Solu- Auteur de Exploring IBM SOA Technology & Practice, co-auteur
tion Patterns. de Enterprise Integration Patterns et The Design Patterns Small-
talk Companion.

http://www.enterpriseintegrationpatterns.com/

(c)Leuville Objects 9-231

Enterprise Intergration Patterns

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-232
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Enterprise Intergration Patterns

o Les EIP sont relativements simples, naturels, basiques, voire même évidents...

o ... mais leur combinaison permet de créer des systèmes d’intégration complexes !!

(c)Leuville Objects 9-233

Enterprise Intergration Patterns

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-234
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Styles d’intégration

Quatre méthodes pour permettre à des applications de s’échanger des informations ou de communiquer
entre elles

o Transfert de fichiers

o Base de données partagée

o Invocation de procédures à distance

o Système de messagerie

(c)Leuville Objects 9-235

Styles d’intégration

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-236
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Styles d’intégration

Transfert de fichier (File Transfer)

o Deux applications communiquent entre elles en se partageant des données stockées dans des fichiers.

o Principe de l’export / import de données.

o Se pose le problème du format du fichier, un mauvais choix pouvant entrainer des problèmes
d’interopérabilité.

o Aujourd’hui, XML est le choix le plus judicieux pour le format d’échange de données.

o En l’absence de standard, le fichier généré par l’application A est rarement au format attendu par l’application
B et il est souvent nécessaire de compléter le système avec des processus de transformation de données.

(c)Leuville Objects 9-237

Styles d’intégration

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-238
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Styles d’intégration

Base de données partagée (Shared Database)

o Plusieurs applications ont accès à une même base de données pour s’échanger des informations.

o Solution "naturelle" et déjà largement utilisée.

o Une limitation : chaque application doit avoir accès à la base de données.

o Les accès simultanés à la base doivent être gérés, chaque application doit parfaitement gérer les transactions.

(c)Leuville Objects 9-239

Styles d’intégration

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-240
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Styles d’intégration

Invocation de procédure à distance (Remote Procedure Invocation)

o Une application expose une interface dont les opérations peuvent être invoquées à distance par une autre
application.

o L’application effectuant l’invocation ne connait que l’interface exposée par l’autre application.

o La communication entre le stub et le skeleton utilise souvent un protocole propriétaire, ce qui pose le problème
de l’interopérabilité.

o Les paramètres d’invocation et le résultat doivent être écrits sous une forme compréhensible par les deux
applications.

(c)Leuville Objects 9-241

Styles d’intégration

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-242
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Styles d’intégration

Système de messagerie

o Plusieurs applications s’échangent des messages, sans se connaitre ni se "voir" directement.

o L’envoi et la récupération de messages se fait via un Middleware Orienté Message (MOM).

o La communication entre les systèmes est asynchrone, les applications n’ont pas besoin d’être actives pour
s’envoyer des messages.

o C’est le style adopté dans les architectures SOA. C’est l’ESB qui joue le rôle de bus de messages.

(c)Leuville Objects 9-243

Styles d’intégration

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-244
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Système de messagerie

o Le système de messagerie permet de faire communiquer des applications en créant un couplage lâche entre
elles.

o La communicaton est également rendue plus fiable car les systèmes s’échangeant des messages n’ont pas
besoin d’être forcément actifs.

o C’est le MOM qui est chargé de transmettre les messages d’une application à une, ou plusieurs autres.

Concepts de base

o Message Channel : Les messages sont transmis à travers des canaux (Message Channel), reliant un emetteur
à un destinataire.

o Message : Un message est un ensemble atomique de données véhiculé sur un canal.

o Multi-step delivery : Entre son emission et sa réception, un message peut être traité par le système de
messagerie pour, par exemple, le valider, l’enrichir, le transformer, ...

o Routing : Il peut arriver que l’émetteur du message ne connaisse pas sa destination. Le système de messagerie
peut se charger de router le message vers le bon destinataire en fonctions de critères ou de règles.

o Transformation : Le message émis n’est pas toujours au format attendu par l’application destinataire. Le
système de messagerie peut transformer le message pour qu’il soit compris de tous.

o EndPoint : Les applications communiquant avec le système de messagerie le font en spécifiant les
coordonnées de la destination (Message Endpoint) avec laquelle elles doivent interagir.

(c)Leuville Objects 9-245

Système de messagerie

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-246
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Système de messagerie

Message Channel

o Un Message Channel est l’élément permettant de mettre en relation deux applications.

o Une application envoie un message dans le canal.

o L’autre application récupère le message dans le canal.

o Un système de messagerie propose autant de Message Chanels que nécessaire.

o Chaque application doit savoir avec quel canal elle doit interagir.

(c)Leuville Objects 9-247

Système de messagerie

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-248
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Système de messagerie

Message

o Un message contient les informations transmises entre l’emetteur et le receveur.

o Un message circule dans un Message Channel

(c)Leuville Objects 9-249

Système de messagerie

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-250
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Système de messagerie

Tubes et Filtres

o Le message émis peut nécessiter qu’on lui applique un certain nombres de traitement avant d’être délivré au
destinataire.

o Ce processus est effectué dans un Tube (Pipe) au sein du système de messagerie.

o Le message passe par divers filtres (Filters) avant d’être mis à disposition du destinataire.

o Chaque filtre expose une interface simple : il reçoit le message, le traite, et rend le message modifié au tube.

o La connection entre le tube et un filtre est appelé port. Un filtre possède habituellement un port d’entrée et un
port de sortie.

(c)Leuville Objects 9-251

Système de messagerie

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-252
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Système de messagerie

Routeur de message

o Le routeur est un filtre particulier.

o Le routeur permet de transmettre le message à différents channels suivant certaines conditions.

o Le routeur diffère du filtre habituel dans le sens où le routeur possède plusieurs ports de sortie.

(c)Leuville Objects 9-253

Système de messagerie

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-254
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Système de messagerie

Traducteur de message (Message Translator)

o Le traducteur de message est un filtre spécialisé dans la transformation de message.

o Il prend en entrée le message, tel qu’il a été émis, et le transforme de telle manière que sa structure soit celle
attendue par le destinataire.

(c)Leuville Objects 9-255

Système de messagerie

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-256
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Système de messagerie

Message Endpoint

o Les applications s’échangent des messages via des Message Channels.

o Les Message Endpoints sont la liaison entre les applications et les Message Channels.

(c)Leuville Objects 9-257

Système de messagerie

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-258
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channels

A propos des message channels

o Dans un système de messagerie, les applications communiquent entre elles en s’échangeant des messages
transitant dans des Message Channels.

o Pour utiliser le système de messagerie, une application doit donc savoir à priori quel canal utiliser pour
transmettre ou recevoir un message.

o Les sujets suivants doivent faire l’objet d’une réflexion afin de mettre en oeuvre de façon efficace un système
de messagerie :

o L’usage veut que l’on dispose d’un ensemble pré-determinés de canaux ; les canaux de messagerie ne
sont pas découverts dynamiquement, il doivent être connus à l’avance.

o Qui doit gérer les canaux ? Est-ce à l’application de connaitre les canaux dont elle a besoin, et au système
de messagerie de lui mettre à disposition ? Ou bien l’application doit-elle s’adapter au canaux proposés
par le système ?

o Habituellement les canaux sont uni-directionnels.

(c)Leuville Objects 9-259

Messaging Channels

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-260
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channels

Les choix à faire

o Canal de type Point à Point, ou de type Publication / Souscription ?

o Quel type de données seront échangées ?

o Chaque canal ne doit comporter qu’un seul type de message.

o Comment gérer les messages invalides, ou les messages périmés ?

o Prévoir des canaux spéciaux pour rediriger ces messages.

o Comment gérer la robustesse du système ? Que deviennent les messages si le serveur redémarre ?

o Déterminer les canaux qui doivent être rendus persistents.

o Déterminer le type de persistence.

o Comment intégrer au système de messagerie une application qui n’a pas techniquement accès à ce système ?

o Prévoir des adapteurs et des bridges.

o Comment garantir la pérennité du système de messagerie ?

o Le penser, dès sa conception, comme un bus de messages, potentiellement utilisable par toutes les
applications de l’entreprise.

(c)Leuville Objects 9-261

Messaging Channels

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-262
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channels

Canal de type Point à Point

o Point-to-Point Channel

o Un message envoyé ne doit être consommé que par une seule application.

o Il peut y avoir plusieurs consommateurs récupérant des messages dans le canal, mais un même message ne
pourra être traité que par un seul receveur.

o C’est au système de messagerie de s’assurer que le message n’est traité qu’une seule fois, pas aux applications.

(c)Leuville Objects 9-263

Messaging Channels

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-264
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channels

Canal de type Publication / Souscription

o Publish / Suscribe Channel

o Un même message peut potentiellement interresser plusieurs applications réceptrices.

o Le système doit s’assurer que le message a bien été traité par toutes les applications qui se sont abonnées au
canal.

(c)Leuville Objects 9-265

Messaging Channels

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-266
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channels

Datatype Channel

o Une application peut envoyer des messages contenant divers types de données à une autre application.

o Comment s’assurer que l’application consommatrice sache comment traiter les messages ?

o Solution : Créer un canal pour chaque type de données.

(c)Leuville Objects 9-267

Messaging Channels

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-268
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channels

Canal de message invalide

o Invalid Message Channel

o Permet à une application de gérer la réception d’un message invalide en le routant vers un canal dédié à ce
type de message.

(c)Leuville Objects 9-269

Messaging Channels

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-270
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channels

Canal à lettres mortes

o Dead Letter Channel

o Permet de gérer les messages périmés, n’ayant pas été consommés après un certain délai.

(c)Leuville Objects 9-271

Messaging Channels

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-272
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channels

Persistence des messages

o Utiliser des canaux persistents pour les messages importants qui doivent survivre à un redémarrage du système
de messagerie.

o Le message est conservé sur un disque tant que celui-ci n’a pas été consommé.

(c)Leuville Objects 9-273

Messaging Channels

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-274
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channel

Canal adaptateur

o Channel Adapter

o Application cliente du système de messagerie et qui communique avec lui à la place d’une autre application
qui n’en a techniquement pas la possibilité.

(c)Leuville Objects 9-275

Messaging Channel

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-276
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channel

Pont de messagerie

o Messaging Bridge

o Utile si le système dispose de plusieurs systèmes de messagerie. Plutôt que de laisser à l’application le soin de
se connecter au bon système de messagerie, on s’assure plutôt que tous les systèmes disposent de tous les
messages.

o Le pont est client de tous les systèmes de messagerie et se charge de répliquer les messages.

(c)Leuville Objects 9-277

Messaging Channel

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-278
 Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie Version 5.1

Messaging Channels

Notion de bus de message

o Message Bus

o Un bus de message est constitué :

o d’un modèle de données commun

o d’un jeu de commandes commun

o d’une infrastructure de messagerie

o Il permet à différents systèmes de communiquer entre eux à travers un ensemble d’interfaces.

(c)Leuville Objects 9-279

Messaging Channels

Notes

(c) Leuville Objects Architectures Orientées Services - Enterprise Integration Patterns : système de messagerie 9-280
Architectures Orientées Services Version 5.1
Les extensions WS-X

o Les spécifications Web Service relatives aux eXtensions

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-282
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Services

Plusieurs familles de spécifications pour mettre en oeuvre des Web Service d’entreprise :

o Spécifications XML

o Spécifications relatives aux messages

o Spécifications relatives aux échanges de métadonnées

o Spécifications relatives à la sécurité

o Spécifications relatives à la qualité de service

o Spécifications relatives à la gestion de ressources

o Spécifications relatives à l’interopérabilité (WS-I)

o Spécifications relatives à la mise en oeuvre de processus métiers

o Spécifications relatives aux transactions

o Spécifications relatives à la gestion

o ...

(c)Leuville Objects 10-283

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-284
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Spécifications XML

o XML : eXtensible Markup Language

o XML Namespaces : espaces de nommages XML

o XML Schema : description de structures de documents XML

o XPath : formalisme de sélection et de traitements de noeuds XML

o XQuery : langage de requêtage sur des documents XML

o XML Information Set (XML Infoset) : partage d’informations entre documents XML

o XInclude : inclusion de documents XML

o XML Pointer : adressage d’éléments XML

(c)Leuville Objects 10-285

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-286
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Spécifications relatives aux messages

o SOAP (anciennement Simple Object Access Protocol)

o MTOM (Message Transmission Optimization Mechanism) : gestion des données binaires dans les messages
SOAP

o WS-Notification : modèle évènementiel appliqué aux Web Services

o WS-BaseNotification : définitions des interfaces client et serveur

o WS-Topics : définition de la notion de Topic, d’adressage et de hiérarchie de Topics

o WS-BrokeredNotification : définition d’un broker de messages

o WS-Addressing : adressage et routage des messages et des réponses

o WS-Transfer : Transfert de ressources adressables via un WebService

o WS-Eventing : Protocole permettant à un WebService de souscrire auprès d’un autre WebService

o WS-Enumeration : Protocole de récupération de données en plusieurs passes

(c)Leuville Objects 10-287

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-288
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Spécifications relatives aux échanges de métadonnées

o WS-Policy : description des services techniques proposés par un WebService (Sécurité, Qualité de service,
...).

o WS-PolicyAssertions : déclaration d’assertions de policy

o WS-PolicyAttachment : association d’une policy à sa cible et association à WSDL et UDDI

o WS-Discovery : Découverte de WebServices sur un réseau

o WS-Inspection : Aggrégation de descriptions de WebServices

o WS-MetadataExchange : Récupération des métadonnées d’un WebService

o Universal Description, Discovery and Integration (UDDI) : Annuaire de WebServices

o WSDL 2.0 Core : Description de Web Service

o WSDL 2.0 SOAP Binding : Description des modalités concrètes d’invocation d’un WebService

o Web Services Semantics (WSDL-S) : Extension de WSDL permettant d’inclure des éléments de
sémantique.

(c)Leuville Objects 10-289

Les spécifications WebService

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-290
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Les spécifications relatives à la sécurité

o WS-Security : identification, autentification, signature, cryptage des messages SOAP

o XML-Signature : format XML d’une signature numérique

o XML-Encryption : format XML de données XML cryptées

o XML Key Management (XKMS) : gestion de clés

o WS-SecureConversation: sécurisation de la conversation entre WebServices.

o WS-SecurityPolicy : Policy Assertions relatives à la sécurité

o WS-Trust : gestion des jetons entre client et service

o WS-Federation : Fédération des système de sécurité entre divers WebServices et d’autres types
d’applications

o WS-Federation Active Requestor Profile : WS-Federation pour les applications SOAP-enabled

o WS-Federation Passive Requestor Profile : WS-Federation pour les application non SOAP-enabled

(c)Leuville Objects 10-291

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-292
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Les spécifications relatives à la sécurité

o Web Services Security Kerberos Binding : intégration de Web Services Security avec Kerberos

o Web Single Sign-On Interoperability Profile : interopérabilité entre WS-Federation et le protocole Liberty
Alliance.

o Web Single Sign-On Metadata Exchange Protocol : protocole d’accord entre un service et un fournisseur
d’identité

o Security Assertion Markup Language (SAML) : échange d’informations d’autentification et d’autorisation

en XML.

o eXtensible Access Control Markup Language (XACML) : langage XML de déclaration de politique de
contrôle d’accès

o XML Key Management (XKMS) : validation et enregistrement de clé publique

(c)Leuville Objects 10-293

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-294
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Les spécifications relatives à la qualité de service

o WS-ReliableMessaging : protocole de transmission fiable de messages SOAP (BEA, Microsoft, Tibco)

o WS-Reliability : protocole de transmission fiable de messages SOAP (Fujitsu, Novell, Oracle, Sun)

o WS-RM Policy Assertion : Policy Assertion associée à WS-ReliableMessaging

(c)Leuville Objects 10-295

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-296
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Les spécifications relatives à la gestion des ressources

o WS-Resource Framework (WSRF) : description d’un WebService Stateful

o WS-BaseFaults : structure standard et interoperable d’une Fault

o WS-ServiceGroup : représentation et gestion d’un ensemble de web services

o WS-ResourceProperties : définition des propriétés d’une ressource Web Service

o WS-ResourceLifetime : gestion du cycle de vie d’une ressource

o WS-Transfer : Transfert de ressources adressables via un WebService

(c)Leuville Objects 10-297

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-298
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Les spécifications relatives à l’interopérabilité (WS-I)

o WS-I Basic Profile : recommandations sur l’usage de SOAP et WSDL

o WS-I Basic Security Profile : recommandations sur la sécurité des Web Services

o Simple SOAP Binding Profile : recommandations sur les protocoles d’invocation des Web Services

(c)Leuville Objects 10-299

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-300
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Les spécifications relatives à la mise en oeuvre de processus métiers

o Business Process Execution Language (WS-BPEL) : description XML d’interactions (orchestration) entre
Web Services

o Choreography Description Language (WS-CDL) : description XML d’interactions (chorégraphie) entre

Web Services

o Web Service Choreograpy Interface (WSCI) : description XML d’un flux de message échangés par des
services dans le cadre d’une chorégraphie

o XML Process Definition Language (XPDL) : description XML d’un processus métier

(c)Leuville Objects 10-301

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-302
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Les spécifications relatives aux transactions

o WS-BusinessActivity : Définition de la gestion d’une transaction longue

o WS-AtomicTransaction : Définition de la gestion d’une transaction ATOMique

o WS-Coordination : Façon de coordonner le fonctionnement de Web Services participant à une activité

o Web Service Composite Application Framework (WS-CAF) : framework générique permettant de

combiner des Web Services

o WS-Transaction : relation entre WS-Coordination et WS-AtomicTransaction / WS-BusinessActivity

permettant de mettre en oeuvre un contexte transactionnel lors de l’invocation de Web Services

o WS-Context : Réference à un contexte partagé

(c)Leuville Objects 10-303

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-304
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Les spécifications Web Service

Les spécifications relatives à la gestion

o WS-Management : protocole de gestion, basé sur SOAP, permettant de gérer des serveurs, des périphériques,
des applications, ...

o Web Services Distributed Management (WSDM) : gestion et contrôle du status des services.

(c)Leuville Objects 10-305

Les spécifications Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-306
 Architectures Orientées Services - Les extensions WS-X Version 5.1

Extensions courantes

WS-Addressing

o Améliore la définition de l’adressage des messages : origine, endpoint, identité d’un destinataire, ...

WS-ReliableMessaging

o Introduit des notions de qualité de service : distribution garantie

WS-MetadataExchange

o Définit un moyen d’obtenir des méta-informations sur un service : WSDL, ...

WS-Security

o Apporte un possibilité de sécuriser SOAP de façon intrinsèque

WS-Policy

o Lié à WS-Security

o Permet de définir des règles d’usage, des pré-requis, ...

...

(c)Leuville Objects 10-307

Extensions courantes

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-308
 Architectures Orientées Services - Les extensions WS-X Version 5.1

WS-MetadataExchange

o Objectif : obtenir toutes les méta-informations d’un service, ou d’un endpoint

o en une seule requête,

o ou plusieurs

Metadata d’un service

o Description WSDL

o Schema XSD

o Policy

Contributeurs initiaux

o BEA

o IBM

o Microsoft

o SAP

(c)Leuville Objects 10-309

WS-MetadataExchange

Notes

(c) Leuville Objects Architectures Orientées Services - Les extensions WS-X 10-310
Architectures Orientées Services Version 5.1
WS-Coordination

o Le concept de transaction dans un cadre Web Services

o WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - WS-Coordination 11-312
 Architectures Orientées Services - WS-Coordination Version 5.1

Les transactions et les Services Web

Différents niveaux

o Transaction "locale" à un Web Service

o Transaction distribuée impliquant plusieurs Web Services

Une spécification "Web Services Transactions"

o Un framework de coordination : WS-Coordination

o propagation de contextes transactionnels au sein des web services

o protocoles de coordination

o Deux types de coordinations:

o WS-AtomicTransactions pour les transactions dites ACID

o WS-BusinessActivity pour les transactions métier à longue durée de vie

(c)Leuville Objects 11-313

Les transactions et les Services Web

Notes

(c) Leuville Objects Architectures Orientées Services - WS-Coordination 11-314

 Architectures Orientées Services - WS-Coordination Version 5.1

WS-Coordination

Concept d’activité

o Activité = tâche ou unité de travail assurée par un ensemble de Services Web

o Informations de contexte associées : identifiants, données, ...

o Assimilable à un processus métier de haut niveau

Complexité d’une activité

o liée au nombre de services participants

o liée à la durée de l’activité

o liée à la fréquence des modifications de nature de l’activité

o liée à la possibilité d’existence concurrente de plusieurs occurences de l’activité

Nécessité d’un framework de gestion des activités : WS-Coordination

o Gestion et transmission des informations de contexte entre les participants d’une activité

(c)Leuville Objects 11-315

WS-Coordination

Notes

(c) Leuville Objects Architectures Orientées Services - WS-Coordination 11-316

 Architectures Orientées Services - WS-Coordination Version 5.1

WS-Coordination

Architecture et services

o Activation

o permet la création de contextes

o un contexte permet d’inviter d’autres services à

participer à l’activité

o Enregistrement

o permet à un participant de s’enregistrer pour

participer à une activité

o l’enregistrement nécessite le contexte envoyé

par l’application ayant réalisé l’activation

o fournit l’adresse du service de coordination

o Gestion de protocoles

o propose un ensemble de protocoles de coordination

o 2 par défaut : WS-AtomicTransaction et WS-BusinessActivity

o Coordination : service de contrôle avec lequel tous les participants interagissent

(c)Leuville Objects 11-317

WS-Coordination

Notes

(c) Leuville Objects Architectures Orientées Services - WS-Coordination 11-318

 Architectures Orientées Services - WS-Coordination Version 5.1

WS-Coordination : activation et enregistrement

1: demande de création contexte

Service Service
Applicatif d’Activation
contexte

2: enregistrement

3: demande
participation
(contexte)
adresse coordinateur
Service
4: enregistrement d’Enregistrement
Service
Participant

adresse coordinateur

(c)Leuville Objects 11-319

WS-Coordination : activation et enregistrement

Notes

(c) Leuville Objects Architectures Orientées Services - WS-Coordination 11-320

 Architectures Orientées Services - WS-Coordination Version 5.1

WS-Coordination : fin d’activité

Service
Applicatif requête de fin d’activité

Service
acquittement de Coordination

fin
fin

acquittement
Service acquittement
Participant Autres services
Service participants
Participant

(c)Leuville Objects 11-321

WS-Coordination : fin d’activité

Notes

(c) Leuville Objects Architectures Orientées Services - WS-Coordination 11-322

 Architectures Orientées Services - WS-Coordination Version 5.1

Deux types de coordinations

WS-AtomicTransaction

o Transactions analogues aux transactions distribuées 2PC de type ACID

o Transactions à durée de vie courte

o Possibilités d’annulation

WS-BusinessActivity

o Transactions à longue ou très longue durée de vie

o Pas de possibilités d’annulation ...

o ... mais mécanismes de compensation fournis par chaque service participant

o Une activité de ce type peut contenir plusieurs activités de type WS-AtomicTransaction

(c)Leuville Objects 11-323

Deux types de coordinations

Notes

(c) Leuville Objects Architectures Orientées Services - WS-Coordination 11-324

 Architectures Orientées Services - WS-Coordination Version 5.1

WS-Coordination : implémentation

D’après IBM DeveloperWorks

(c)Leuville Objects 11-325

WS-Coordination : implémentation

Notes

(c) Leuville Objects Architectures Orientées Services - WS-Coordination 11-326

 Architectures Orientées Services - WS-Coordination Version 5.1

Exemple de contexte WS-Coordination

<?xml version="1.0" encoding="utf-8"?>

<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"
<S:Header>
...
<wscoor:CoordinationContext xmlns:wsme="http://www.w3.org/2002/06/msgext" xmlns:wscoor=http://www.w3.org/2002/06/Coordination
xmlns:myApp="http://www.w3.org/2002/06/myApp">
<wsme:Identifier>http://foobaz.com/SS/1234</wsme:Identifier>
<wsme:Expires>2002-06-30T13:20:00.000-05:00</wsme:Expires>
<wscoor:CoordinationType>http://xml-soap.org/2002/06/AtomicTransaction </wscoor:CoordinationType>
<wscoor:RegistrationService>
<Address>http://myservice.com/mycoordinationservice/registration </Address>
<myApp:BetaMark> ... </myApp:BetaMark>
<myApp:EBDCode> ... </myApp:EBDCode>
</wscoor:RegistrationService>
<myApp:IsolationLevel>RepeatableRead</myApp:IsolationLevel>
</wscoor:CoordinationContext>
...
</S:Header>

(c)Leuville Objects 11-327

Exemple de contexte WS-Coordination

Notes

(c) Leuville Objects Architectures Orientées Services - WS-Coordination 11-328

Architectures Orientées Services Version 5.1
La sécurité au sein des Web Services

o Introduction aux différentes spécifications relatives à la sécurité des Web Services

o WS-Security et travaux connexes

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
 1

(c) Leuville Objects Architectures Orientées Services - La sécurité au sein des Web Services 12-330
 Architectures Orientées Services - La sécurité au sein des Web Services Version 5.1

Spécifications

Utilisables dans un contexte Web Services

WS-Security Identification - authentification - autorisation - confi-

dentialité - intégrité
WS-Policy De façon générale, exigences imposées à l’utilisateur
d’un Web Service (conformité extensions)
WS-SecurityPolicy Politiques de sécurité applicables à un endpoint, en
liaison avec WS-Policy et WS-Security
WS-SecureConversation Modèle permettant des conversations sécurisées entre
services basé sur WS-Security et WS-Policy
WS-Trust Framework permettant à des Web Services d’échanger
des informations de sécurité
XML Encryption Confidentialité des messages
XML Signature Intégrité des messages
XKMS XML Key Management Specification
XACML Extensible Access Control Markup Language
SAML Security Assertion Markup Language
SSL Secure Socket Layer

(c)Leuville Objects 12-331

Spécifications

Notes

(c) Leuville Objects Architectures Orientées Services - La sécurité au sein des Web Services 12-332
 Architectures Orientées Services - La sécurité au sein des Web Services Version 5.1

WS-Security

Standard OASIS

o Définit des entêtes spécifiques permettant de véhiculer des informations de sécurité avec les messages SOAP

o Tokens d’identification

o username / password

o certificat X509

o ticket Kerberos

o assertion SAML

o Signatures (XMLSignature)

o Messages cryptés (XMLEncryption)

(c)Leuville Objects 12-333

WS-Security

Notes

(c) Leuville Objects Architectures Orientées Services - La sécurité au sein des Web Services 12-334
 Architectures Orientées Services - La sécurité au sein des Web Services Version 5.1

WS-Policy

Soumis au W3C

o Permet à un fournisseur de services web de spécifier (entre autres exigences) des exigences en matière de
sécurité

o authentification

o encryption

o signature

o Les exigences sont attachées à la description WSDL

(c)Leuville Objects 12-335

WS-Policy

Notes

(c) Leuville Objects Architectures Orientées Services - La sécurité au sein des Web Services 12-336
 Architectures Orientées Services - La sécurité au sein des Web Services Version 5.1

WS-SecurityPolicy

https://www.oasis-open.org/standards#ws-secpol

Standard OASIS depuis version 1.2

o Créé par IBM et 12 autres acteurs

o Basé sur WS-Security, WS-Trust, WS-SecureConversation

o Permet de définir des "assertions" relatives à la sécurité au sein d’un WSDL

o contraintes de signature, encryption ou même simple présence de tel ou tel élément XML

o contraintes en matières de format de tokens: SAML, X509, ...

<sp:IssuedToken>
<sp:RequestSecurityTokenTemplate>
<wst:TokenType>...#SAMLV2.0</wst:TokenType>
</sp:RequestSecurityTokenTemplate>
</sp:IssuedToken>

o Objectif: simplifier la mise en oeuvre de WS-Security par génération automatique de proxy conformes aux
exigences

(c)Leuville Objects 12-337

WS-SecurityPolicy

Notes

(c) Leuville Objects Architectures Orientées Services - La sécurité au sein des Web Services 12-338
 Architectures Orientées Services - La sécurité au sein des Web Services Version 5.1

SAML

Standard WS-I

o Définit un format XML standard permettant de transporter des informations de sécurité d’un système à un
autre

o indépendamment des plate-formes

o indépendamment des langages de programmation

o Constitue un mécanisme de SSO (Single-Sign On) pour les Web Services

o notion d’autorité SAML qui peut attester de la validité d’une authentification

(c)Leuville Objects 12-339

SAML

Notes

(c) Leuville Objects Architectures Orientées Services - La sécurité au sein des Web Services 12-340
Architectures Orientées Services Version 5.1
WS-Security

o Présentation de WS-Security

o Structure des données de sécurité

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
 2

(c) Leuville Objects Architectures Orientées Services - WS-Security 13-342

 Architectures Orientées Services - WS-Security Version 5.1

Présentation de WS-Security

Caractéristiques

o Spécification élaborée par Microsoft, IBM et Verisign puis standardisée par le consortium OASIS.

o Version 1.0 du 5 avril 2002

o Extension de SOAP permettant des échanges sécurisés de messages au format SOAP.

o Fournit des mécanismes standards pour :

o La propagation de jetons de sécurité

o L’assurance de l’intégrité des messages échangés

o La gestion de la confidentialité

o S’utilise en complément d’un transport sécurisé

o Mais permet de rester sécurisé quel que soit le protocole de transport

(c)Leuville Objects 13-343

Présentation de WS-Security

Notes

Cette extension de SOAP a été mise au point pour pallier au manque de sécurité inhérents aux services
Web.

WS-Security est un système extensible et s’adapte à tous les moyens d’authentifications. C’est pourquoi
cette spécification n’impose aucun protocole d’identification / authentification particulier.

Les sécurités de niveau transport tels que SSL permettent de protéger le message durant son transport d’un
point à l’autre de la chaîne de liaison. WS-Security apporte une sécurité au niveau du message lui-même
assurant ainsi sa protection depuis son émission jusqu’à réception.

(c) Leuville Objects Architectures Orientées Services - WS-Security 13-344

 Architectures Orientées Services - WS-Security Version 5.1

Terminologie

Sécurité d’un message

o WS-Security propose une structure de données adaptée à la gestion des aspects suivants, liés à la sécurité d’un
message :

o Identification : processus permettant de déterminer qui est le client

o Authentification : processus permettant de s’assurer que le client est bien celui qu’il prétend être

o Autorisation : processus permettant de s’assurer que le client a les droits nécessaires et suffisants pour
satisfaire sa demande

o Confidentialité : processus permettant de s’assurer que seul le destinataire du message est capable de le
lire.

o Intégrité : processus permettant de s’assurer que le message n’a pas été modifié entre son émission et sa
réception.

(c)Leuville Objects 13-345

Terminologie

Notes

(c) Leuville Objects Architectures Orientées Services - WS-Security 13-346

 Architectures Orientées Services - WS-Security Version 5.1

Cryptage et signature numérique

Utilisation d’extensions de WS-Security.

o XML-Encryption

o Technologie de cryptage de données XML

o Crypter tout ou partie d’un message

o XML-Signature

o Génération d’une information permettant de vérifier l’intégrité d’un message (checksum)

(c)Leuville Objects 13-347

Cryptage et signature digitale

Notes

XML-Signature et XML-Encryption sont deux spécifications du W3C. C’est l’utilisation conjointe de ces
deux technologies qui permet d’assurer la sécurité d’un message.

WS-Security utilise ses deux technologies pour décrire les éléments sécurisant un message.

(c) Leuville Objects Architectures Orientées Services - WS-Security 13-348

 Architectures Orientées Services - WS-Security Version 5.1

Structures des en-têtes Security

o WS-Security introduit un nouvel en-tête dans l’enveloppe SOAP : l’en-tête Security.

Quelques règles

o Autant d’en-têtes Security que nécessaire, mais un seul par acteur SOAP

o L’ordre des éléments dans l’élément Security indique l’ordre dans lequel effectuer les opérations

o Dans la mesure du possible, placer les éléments référencés avant l’appel à leur référence

Contenu

o Jetons d’authentification

o Signatures numériques (XML-Signature)

o Déclarations de contenu cryptés (XML-Encryption)

(c)Leuville Objects 13-349

Structure des en-têtes Security

Notes

Un message peut contenir un ou plusieurs en-têtes Security. Ceux-ci peuvent être associé à un acteur SOAP
particulier.

L’en-tête Security permet de spécifier un ou plusieurs jetons d’authentification : identifiant, identifiant / mot
de passe, jeton de type binaire (décrits par les balises UsernameToken et BinarySecurityToken). Les
jetons ainsi déclarés peuvent ensuite être référencés dans le reste du document (utilisation de la balise
SecurityTokenReference).

Les signatures numériques nécessitent parfois que l’en-tête fournisse des information sur une clé, dans ce
cas, on ajoute un élément keyInfo du domaine XML-Signature

La signature numérique d’un élément du message peut être ajouté à l’en-tête Security afin que le receveur
soit en mesure d’en vérifier l’intégrité. Pour cela, on ajoute un élément Signature du domaine XML-
Signature. Plusieurs signatures numériques, chacune portant sur une partie du message, peuvent être
spécifiés, permettant ainsi à chaque acteur de vérifier l’intégrité de la partie du message qui le concerne.

Les algorithmes supportés pour signer un contenu sont ceux de la spécifications XML-Signature.

L’en-tête sécurité peut déclarer du contenu crypté (élément ReferenceList de XML-Encryption) qui sera
remplacé son équivalent crypté (dans un élément EncryptedData de XML-Encryption). Si la méthode de
cryptage est telle que la clé doit elle-même être cryptée (cryptage à clé symétrique), la déclaration de la clé
cryptée fait alors également partie de l’en-tête Security (élément EncryptedKey de XML-Encryption).

(c) Leuville Objects Architectures Orientées Services - WS-Security 13-350

 Architectures Orientées Services - WS-Security Version 5.1

Gestion des erreurs

Codes de l’élément fault en fonction du type d’erreur :

Table 1: faultcode pour les erreurs de type "non supporté"

Erreur faultcode
Type de jeton non supporté wsse:UnsupportedSecurityToken
Algorithme de signature ou de cryptage non supporté wsse:UnsupportedAlgorithm

Table 2: faultcode pour les erreurs de type "echec"

Erreur faultcode
Erreur durant le traitement de l’en-tête "Security" wsse:InvalidSecurity
Jeton invalide wsse:InvalidSecurityToken
Identification ou authentification du jeton impossible wsse:FailedAuthentication
Signature ou décryptage invalide wsse:FailedCheck
Jeton de référence irrécupérable wsse:SecurityTokenUnavailable

(c)Leuville Objects 13-351

Gestion des erreurs

Notes

En plus des erreurs métiers liées au traitement du contenu du message, l’utilisation de WS-Security
implique la gestion d’erreurs liées aux processus d’identification / authentification / permissions / intégrité,
mais également des erreurs dues au non support d’une technologie WS-Security par le serveur.

En cas d’erreur de sécurité, la réponse intègre un élément SOAP "fault" fournissant le code de l’erreur.

(c) Leuville Objects Architectures Orientées Services - WS-Security 13-352

 Architectures Orientées Services - WS-Security Version 5.1

Exemple de message

Message SOAP utilisant l’extension WS-Security en fournissant un identifiant d’utilisateur :

<?xml version="1.0" encoding="utf-8"?>
<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<S:Header>
<m:path xmlns:m="http://schemas.xmlsoap.org/rp/">
<m:action>http://fabrikam123.com/getQuote</m:action>
<m:to>http://fabrikam123.com/stocks</m:to>
<m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>
</m:path>
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">
<wsse:UsernameToken Id="MyID">
<wsse:Username>Zoe</wsse:Username>
</wsse:UsernameToken>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
<ds:Reference URI="#MsgBody">
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>DJbchm5gK...</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#MyID" />
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</S:Header>
<S:Body Id="MsgBody">
<tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads">
QQQ
</tru:StockSymbol>
</S:Body>
</S:Envelope>

(c)Leuville Objects 13-353

Exemple de message

Notes

Dans cet exemple, on retrouve la structure habituelle d’un message SOAP, c’est à dire une enveloppe
contenant des en-têtes (header) et un corps (body). L’en-tête Security introduit par WS-Security contient les
informations de sécurité.

Un jeton de securité est associé au message par l’usage de la balise "UsernameToken". La seule donnée
transmise ici est l’identifiant de l’utilisateur (on suppose que le mot de passe est connu du service).

La suite de l’en-tête de sécurité (balise "Signature") concerne la signature numérique du message qui
garantit l’intégrité du message (ie qu’il n’a pas été modifié entre sa soumission et sa réception). La balise
"SignedInfo" décrit ce qui doit être signé (ici, le corps du message) et avec quelle méthode. La balise
"SignatureValue" indique la valeur de la signature calculée, quant à "KeyInfo", elle spécifie le jeton de
sécurité associé à cette signature.

Toutes les informations relatives à la signatures sont décrites en suivant la spécification XML-Signature du
W3C.

(c) Leuville Objects Architectures Orientées Services - WS-Security 13-354

 Architectures Orientées Services - WS-Security Version 5.1

Autre exemple
<?xml version="1.0" encoding="utf-8"?>
<S:Envelope
xmlns:S="http://www.w3.org/2001/12/soap-envelope" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<S:Header>
<m:path xmlns:m="http://schemas.xmlsoap.org/rp/">...</m:path>
<wsse:Security>
<wsse:BinarySecurityToken ValueType="wsse:X509v3" Id="X509Token" EncodingType="wsse:Base64Binary">
MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
</wsse:BinarySecurityToken>
<xenc:EncryptedKey>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<ds:KeyInfo><ds:KeyName>CN=Hiroshi Maruyama, C=JP</ds:KeyName></ds:KeyInfo>
<xenc:CipherData><xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...</xenc:CipherValue></xenc:CipherData>
<xenc:ReferenceList><xenc:DataReference URI="#enc1" /></xenc:ReferenceList>
</xenc:EncryptedKey>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference>
<ds:Transforms>
<ds:Transform Algorithm="http://...#RoutingTransform" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>LyLsF094hPi4wPU...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>Hp1ZkmFZ/2kQLXDJbchm5gK...</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference><wsse:Reference URI="#X509Token" /></wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</S:Header>
<S:Body>
<xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" Id="enc1">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#3des-cbc" />
<xenc:CipherData><xenc:CipherValue>d2FpbmdvbGRfE0lm4byV0...</xenc:CipherValue></xenc:CipherData>
</xenc:EncryptedData>
</S:Body>
</S:Envelope>

(c)Leuville Objects 13-355

Autre exemple

Notes

Dans cet exemple, le jeton de sécurité est un certificat X.509 encodé en base 64.

La balise "xenc:EncryptedKey" indique la clé utilisée pour crypter une partie du message. Le cryptage
utilisé étant basé sur une clé symétrique, celle-ci est transmise cryptée. En l’occurence, elle est cryptée en
utilisant l’algorithme RSA. La clé utilisée pour crypter la clé symétrique est indiquée dans la balise
"keyInfo". Viennent ensuite la valeur de la clé cryptée ainsi que la référence vers le contenu crypté
(identifiant "enc1").

La dernière partie concerne la signature numérique du document. Comme dans l’exemple précédent, on
indique la méthode de signature, la partie du document signée (ici, à base de Transform), le checksum
résultant et enfin la clé (ici une référence au certificat X.509 déclaré plus haut).

Enfin, le corps même du message est remplacé par un élément EncryptedData du domaine XML-Encryption
comme spécifié dans l’élément EncryptedKey de l’en-tête de sécurité.

(c) Leuville Objects Architectures Orientées Services - WS-Security 13-356

 Architectures Orientées Services - WS-Security Version 5.1

Implémentations de WS-Security

Java

o Implémentation Sun/Oracle : XWS-Security, disponible dans le WSDP

o Implémentation Apache : Apache WSS4J, utilisable conjointement avec Apache Axis ou CXF.

o axis-wsse (implémentation partielle)

.NET

o Implémentation complète au sein du framework

(c)Leuville Objects 13-357

Implémentations de WS-Security

Notes

(c) Leuville Objects Architectures Orientées Services - WS-Security 13-358

Architectures Orientées Services Version 5.1
Expression des besoins

o Expression des besoins par la MOA

o Etude de faisabilité

o Rédaction du cahier des charges

o Diagrammes UML associés

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-360
 Architectures Orientées Services - Expression des besoins Version 5.1

Démarche générale
act Expression du besoin

Etude de faisabilité Début

o Pour déterminer l’opportunité de

lancer un projet

o Consiste en un ensemble d’études

Repèrage domaine Découv erte informations M odélisation w orkflow s
globales chiffrées, à comparer

o Peut être déléguée à un Maître

Etude de
d’ouvrage opérationnel fai sabi l i té

Diagnostic
Réalisation du cahier des charges

o Pour présenter la solution retenue à Reconfiguration SI

l’issue de l’étude de faisabilité

o De façon compréhensible par la MOE

M odélisation futur SI Rédacti on du

o Pour que la MOE s’engage sur un coût CDC

ou une charge et des délais

Rédaction CDC

Fi n

(c)Leuville Objects 14-361

Démarche générale

Notes

Ce diagramme illustrant la démarche générale de la MOA est un diagramme d’activités UML 2.

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-362
 Architectures Orientées Services - Expression des besoins Version 5.1

Etude de faisabilité

Etapes

o Repérage du domaine

o pour déterminer les finalités du projet, ses limites, les acteurs concernés

o Découverte des informations

o pour comprendre le SI existant

o Modélisation des workflows (processus métier)

o pour comprendre et modéliser les activités essentielles de l’entreprise

o Diagnostic et orientation

o pour détecter les forces et faiblesses du système existant

o Scénarios de reconfiguration du système d’information

o pour proposer des solutions globales et des éléments de choix

(c)Leuville Objects 14-363

Etude de faisabilité

Notes

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-364
 Architectures Orientées Services - Expression des besoins Version 5.1

Repérage du domaine

Prise de connaissance du projet

Déterminer les avantages supposés du nouveau projet

o Gain de productivité administrative

o Aide au management

o Efficacité opérationnelle

o Evolutivité

o Utilisation de nouvelles technologies

Définir les limites du projet

o Identification des domaines (domaine = composant du SI gérant un ensemble cohérent d’informations)

o Identification des frontières entre le projet et ces domaines

Moyens

o Entretiens avec des cadres de l’entreprise ayant une vue globale (interviews de direction)

(c)Leuville Objects 14-365

Repérage du domaine

Notes

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-366
 Architectures Orientées Services - Expression des besoins Version 5.1

Repérage du domaine

Outils de modélisation

o Diagramme de paquetages

o un domaine = un paquetage

o interfaces entre domaines = dépendances entre paquetages

o Diagramme de communications

o un domaine = un objet

o interfaces entre domaines = communications entre objets

sd Repérage domaine

:Serv ice
2: paiement Comptabilité

1: commande avec paiement

:Serv ice
Commandes
5: livraison 4: produit disponible
:Client

3: demande produits :Serv ice Stock

(c)Leuville Objects 14-367

Repérage du domaine

Notes

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-368
 Architectures Orientées Services - Expression des besoins Version 5.1

Découverte des informations

Comprendre les facettes du SI existant

Moyens

o Discours des acteurs de l’entreprise

o Modèles et dictionnaires de données du système existant

o Connaissances des administrateurs de données du système existant

o Observation des emplois opérationnels des interfaces du système existant

o Documentation

Outils de modélisation

o Diagramme de classes avec les grands concepts d’informations

(c)Leuville Objects 14-369

Découverte des informations

Notes

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-370
 Architectures Orientées Services - Expression des besoins Version 5.1

Modélisation des workflows

Comprendre le fonctionnement des activités organisées de l’entreprise

Moyens

o Recenser les types d’événements à l’origine d’un processus

o est événement quelque chose qui se passe et qui est reconnu par l’entreprise

o engendre une réponse se traduisant par des circulations d’informations, accompagnées de

transformations

o Ne pas chercher à modéliser trop finement le SI existant -> risque de perte de recul

Outils de modélisation

o Diagramme de cas d’utilisation

o Diagramme de séquences

o Diagramme d’activités

(c)Leuville Objects 14-371

Modélisation des workflows

Notes

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-372
 Architectures Orientées Services - Expression des besoins Version 5.1

Modélisation des workflows

Exemple

(c)Leuville Objects 14-373

Modélisation des workflows

Notes

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-374
 Architectures Orientées Services - Expression des besoins Version 5.1

Diagnostic

Appréciation sur la gestion des informations et les processus

Points à évaluer, si possible avec un groupe d’utilisateurs

o Mission actuelle du système d’informations

o Importance stratégique du domaine

o Détermination des critères d’évaluation de l’adéquation du nouveau système à ses missions

Améliorations nécessaires

o Concepts d’informations de l’étape de découverte des informations

o Processus issus de l’étape de modélisation des workflows

Orientations

o Améliorer les informations et les processus

o Renforcer les moyens de pilotage

(c)Leuville Objects 14-375

Diagnostic

Notes

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-376
 Architectures Orientées Services - Expression des besoins Version 5.1

Scénarios de reconfiguration du SI

Proposer des solutions avec des moyens de les évaluer

Points à prendre en considération

o Eléments issus des étapes précédentes : concepts, processus, etc ...

o Types de solutions possibles

o développement spécifique

o mise en oeuvre de progiciels

o solution mixte

o Etudes de coûts

o méthode des points fonctions permettant d’évaluer les charges de développement

Décision

o Prise par un Comité de pilotage

o Donne lieu à l’établissement du cahier des charges

(c)Leuville Objects 14-377

Scénarios de reconfiguration du SI

Notes

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-378
 Architectures Orientées Services - Expression des besoins Version 5.1

L’établissement du cahier des charges

act Expression du besoin

Deux étapes Début

o Modélisation du futur système

o compléter les diagrammes

obtenus à l’issue de l’étude de
Repèrage domaine Découv erte informations M odélisation w orkflow s
faisabilité

o Rédaction proprement dite comportant

Etude de
fai sabi l i té
o description du futur SI
Diagnostic

o stratégie de développement
Reconfiguration SI

M odélisation futur SI Rédacti on du

CDC

Rédaction CDC

Fi n

(c)Leuville Objects 14-379

L’établissement du cahier des charges

Notes

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-380
 Architectures Orientées Services - Expression des besoins Version 5.1

L’établissement du cahier des charges

Description du futur SI

o Objectifs du futur système

o Cartographie du système, avec mise en évidence de ses frontières avec d’autres systèmes

o Description des entités métier

o Description des processus métier

o L’ensemble étant illustré par les diagrammes obtenus lors de l’étude de faisabilité

Stratégie et exigences

o Grandes lignes de la stratégie de réalisation

o Exigences en matière de qualité

o Contraintes en termes de suivi de l’avancement du projet

o Précisions des rôles de la MOE dans certaines tâches réalisées par la MOA (recette, migration, formation, ...)

Cahier des Clauses Techniques Particulières

(c)Leuville Objects 14-381

L’établissement du cahier des charges

Notes

Les reprises de données peuvent être gérées comme des projets à part entière.

(c) Leuville Objects Architectures Orientées Services - Expression des besoins 14-382
Architectures Orientées Services Version 5.1
Analyse, conception et modélisation des services

o Cycle de vie d’un projet SOA

o Analyse et conception de services SOA

o Qualités attendues d’un service SOA

o Recommandations WS-I

o Lien avec le formalisme UML

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-384
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Expression des besoins d’un projet SOA

act Expression du besoin

Ordre des étapes Début

o Recensement de l’existant

o Périmètre

o Processus métier Repèrage domaine Découv erte informations M odélisation w orkflow s

o Objets métier
Etude de

o Décisions stratégiques fai sabi l i té

Diagnostic
o Objectifs d’améliorations

o Allocations de moyens Reconfiguration SI

o Cahier des Charges

o Modélisation cible M odélisation futur SI Rédacti on du

CDC

o Stratégie(s)
Rédaction CDC

Fi n

(c)Leuville Objects 15-385

Expression des besoins d’un projet SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-386
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Phases du développement

Processus Unifié / Cycle en Y

MOA Expression des besoins

MOE
CP

Expression Expression
Besoins fonctionnels contraintes techniques
Expert
Métier Architecte

Analyse Architecture
technique

Conception préliminaire

Conception détaillée

Réalisation Recette

(c)Leuville Objects 15-387

Phases du développement

Notes

o Expression des besoins fonctionnels : phase dont l’objectif est de produire les spécifications
fonctionnelles du système à réaliser
o Expression des contraintes techniques : recenser toutes les contraintes non fonctionnelles qui auront une
influence sur la conception du système
o Analyse : découpage en catégories, mise au point des modèles statiques et dynamiques fonctionnels,
indépendamment de toute considération technique
o Architecture technique : définition des composants de l’architecture technique, si possible
indépendamment des besoins fonctionnels
o Conception préliminaire : fusion de l’analyse fonctionnelle et de l’architecture technique
o Conception détaillée : conception de chaque composant à réaliser
o Réalisation : codage et tests unitaires
o Recette : validation du système final

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-388
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Sorties des différentes phases

De façon générale

Phases du processus Résultats et/ou diagrammes UML

Expression des besoins fonctionnels Cas d’utilisation avec fiches descriptives
Scénarios illustrés par des diagrammes de séquences et/ou de collabo-
rations et/ou d’activités
Diagrammes de classes participantes
Expression des contraintes techniques Choix du style d’architecture et organisation en couches
Diagramme de déploiement. Diagramme de composants
Cas d’utilisation techniques destinés aux exploitants
Analyse Diagramme de paquetages illustrant le découpage en catégories
Modèle statique : diagramme de classes enrichi
Modèle dynamique : scénarios précisés, diagrammes états-transitions
Architecture technique Sélection des frameworks techniques et design-patterns
Modèle d’exploitation illustré par le diagramme de composants
Conception préliminaire Diagrammes de déploiement et de composants.
Précisions des interfaces sur les diagrammes de classes.
Conception détaillée Introduction des classes techniques
Réalisation Code source
Recette Système validé

(c)Leuville Objects 15-389

Sorties des différentes phases

Notes

Il s’agit de suggestions qui peuvent être particularisées dans le cadre de la mise en oeuvre d’un processus
spécifique adapté à partir du Processus Unifié.

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-390
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Sorties des différentes phases

Dans un cadre SOA

Phases du processus Eléments complémentaires au tableau précédent

Expression des besoins fonctionnels Liste de services candidats (à partir des CU), représentés à l’aide de paquetages
Expression des contraintes techniques Choix du style d’architecture SOA: centralisée, répartie
Définition des couches (modèle de T. Erl, modèle "BEA", ...)
Représentation des services sous la forme de composants
Analyse Modélisation des processus métier avec BPMN, ou diagramme d’activités avec
profil spécifique
Recensement et modélisation des Objets Métier Locaux (SI existant ou nou-
veaux composants)
Architecture technique Sélection des éléments techniques: bus ESB, moteur BPM, moteur BPEL, pas-
serelles avec les éléments existants du SI, ...
Conception préliminaire Production des schémas XML à partir des diagrammes de classes
Production des processus BPEL à partir de BPMN ou des diagrammes d’activi-
tés
Conception détaillée Recensement des passerelles Objets Métier Globaux <-> Objets Métier Locaux
Définition des formats de données correspondants aux Objets Métier Locaux
Réalisation Réalisation des passerelles entre le SI existant et le bus ESB
Implémentation des processus
Réalisation des transformations XML <-> XML, XML <-> formats spécifiques
Recette Injection de jeux d’essais XML et validation automatique des résultats

(c)Leuville Objects 15-391

Sorties des différentes phases

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-392
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Analyse SOA

Objectifs de cette phase

o Déterminer les services à concevoir et réaliser

o Déterminer la logique métier encapsulée par ces services

Processus en trois étapes

o Définir les cas d’utilisation du système

o processus UP

o formalisme UML

o Identifier au sein des applications existantes les processus métier correspondant aux cas d’utilisation retenus

o Etablir la liste des services candidats

o identifier les opérations candidates

o les regrouper en ensembles -> services candidats

o définir les frontières de ces ensembles avec les services existants ou planifiés

o identifier la logique sous-jacente réutilisable

(c)Leuville Objects 15-393

Analyse SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-394
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Définir les services candidats

Processus

o Décomposer les processus métier en étapes, en s’appuyant sur des techniques existantes : BPM par exemple

o Identifier les opérations candidates parmi ces étapes

o Définir (éventuellement) une couche d’orchestration à partir d’informations telles que : règles métier,
conditions, exceptions, ...

o Grouper les opérations en services candidats

o Vérifier que les candidats sont de "bons" services : réutilisables, autonomes, sans état, ...

o Dérouler les principaux scénarios issus des cas d’utilisation, identifier les compositions de services

o Modifier le contenu des services candidats si nécessaire, créer les services ou opérations manquants

o Identifier les services applicatifs et les services métier

(c)Leuville Objects 15-395

Définir les services candidats

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-396
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Les qualités attendues d’un service

Les services

o sont réutilisables

o sont composables au sein de services de plus haut niveau

o sont conformes à un contrat formel : endpoints, opérations, messages d’entrées et de sorties

o sont faiblement couplés

o cachent la logique métier sous-jacente

o sont autonomes

o sont sans état

o sont accompagnés de descriptions accessibles aux humains et aux autres services

o -> annuaires

o -> descriptions plus sémantiques

(c)Leuville Objects 15-397

Les qualités attendues d’un service

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-398
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Définir des services d’orchestration

Processus complexe et coûteux

Contrôleur de services

o Modélisation des processus

métier : BPM

o Modélisation de services de
haut niveau

Outils

o Modèles BPMN

o Langage d’orchestration WS-

BPEL

(c)Leuville Objects 15-399

Définir des services d’orchestration

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-400
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Conception préliminaire SOA

Définition des services concrets

o A partir des services logiques issus de l’analyse et des choix issus de l’étude d’architecture

Activités typiques

o Concevoir les services conformément aux recommandations WS-I

o ensemble des opérations

o messages d’entrée et de sortie

o types des données avec XSD

o S’assurer de la conformité aux standards et conventions de conception choisis par l’architecte

o couches pertinentes de l’architecture canonique

o emploi de modèles de conception tels que le pattern VETO ou d’autres plus spécifiques

o extensions WS-X indispensables

(c)Leuville Objects 15-401

Conception préliminaire SOA

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-402
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Conception de services inter-opérables

Recommandations WS-I : Web Services Interoperability

o organisation internationale de promotion de l’interopérabilité des web services

o profil WS-I Basic Profile Version 1.0

o Eviter les services RPC / encoded et choisir plutôt Document / Literal

Deux types de messages SOAP

o RPC : l’élement <soap:Body> contient un élément dont le nom est celui de la méthode invoquée

o Document : l’élément <soap:Body> peut contenir un nombre quelconque d’éléments, selon accord entre
l’émetteur et le récepteur

Deux formats de sérialisation des données

o SOAP Encoding

o données encodées selon des règles de sérialisation issues de SOAP 1.1 section 5

o Literal

o les données sont sérialisées d’après un schéma XSD

(c)Leuville Objects 15-403

Conception de services inter-opérables

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-404
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

Formaliser une architecture SOA en UML

Nombreuses propositions d’extensions UML

o UML 2.0 Profile for Software Services

o UML Profile for Automated Business Processes

o correspondances entre UML et WS-BPEL

o Profil de l’Université de Paderborn (Allemagne)

o Profils pour EAI

Travaux de l’OMG

o SoaML

o un profil et un méta-modèle adaptés à la modélisation de services au sein d’une architecture SOA

o soutenu par: CapGemini, EDS, Fujitsu, HP, IBM, Softeam, France Telecom, Thales, ...

o version 1.0 de mai 2007

o version 1.8 : 25/08/2008

(c)Leuville Objects 15-405

Formaliser une architecture SOA en UML

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-406
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

SoaML

Concepts permettant de modéliser des services

o Service

o possibilité offerte par une ou plusieurs entités (Participant) à d’autres, par l’intermédiaire de contrats bien
définis

o le recours au service s’effectue à travers un port

o stéréotype <<service>>

o Participant

o être humain, application, composant, système, ...

o stéréotype <<participant>>

o ServiceInterface

o une interface qui décrit les messages reçus

o une interface qui décrit les messages envoyés

o un protocole qui décrit l’ordre des messages

(c)Leuville Objects 15-407

SoaML

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-408
 Architectures Orientées Services - Analyse, conception et modélisation des services Version 5.1

ServiceInterface SoaML

Exemple générique

o Interface1: décrit les

requêtes

o Interface2: décrit les

réponses

o part: endpoints

o Protocole: ordre des

échanges

(c)Leuville Objects 15-409

ServiceInterface SoaML

Notes

(c) Leuville Objects Architectures Orientées Services - Analyse, conception et modélisation des services 15-410
Architectures Orientées Services Version 5.1
Introduction à BPMN

o Concepts BPMN

o Objectifs

o Historique

o A qui est destiné BPMN ?

o Exemples de diagrammes BPMN

o Outils de modélisation

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-412
 Architectures Orientées Services - Introduction à BPMN Version 5.1

Introduction

Modélisation de processus métier

o Business Process Management est une approche consistant à modéliser informatiquement les processus
métiers de l'entreprise et aboutir à une meilleure vue globale de leurs intéractions afin de les optimiser et les
automatiser autant que possible.

o BPM est un moyen d’étudier, identifier, modifier et surveiller les processus d’entreprise.

o Avant BPM existait UML, mais BPM fait l'unanimité dans la gestion des processus métiers, car BPM est
orienté métier.

o Dans une organisation, BPM intervient à plusieurs niveaux :

o Au niveau métier afin de définir les différents processus du travail à modéliser,

o Au niveau technique pour une transposition du niveau métier dans le système informatique de
l'entreprise.

(c)Leuville Objects 16-413

Introduction

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-414

 Architectures Orientées Services - Introduction à BPMN Version 5.1

Introduction

Trois niveaux

o Les processus stratégiques,

o Les processus fonctionnels ,

o Les processus organisationnels.

Ceci a donné naissance à:

o BPMN (Business Process Model and Notation) qui définit un modèle graphique des processus,

o BPEL (Business Process Execution Language) qui définit un langage de programmation destiné à l’exécution
des processus.

(c)Leuville Objects 16-415

Introduction

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-416

 Architectures Orientées Services - Introduction à BPMN Version 5.1

Simplicité

Quatre éléments de base et trois éléments d’interaction entre acteurs

(c)Leuville Objects 16-417

Simplicité

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-418

 Architectures Orientées Services - Introduction à BPMN Version 5.1

Présentation

Notation inspirée des diagrammes d’activités UML

o BPMN (Business Process Model and Notation) est un système de notation graphique permettant de représenter
les processus métiers sous forme de modèle.

o La notation consiste en un ensemble de symboles graphiques représentant des actions, des flux ou des
comportements dans un processus

(c)Leuville Objects 16-419

Présentation

Notes

D’après https://bonitasoft.developpez.com/tutoriels/business-process-management/guide-ultime-
bpmn2/#LIV-M

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-420

 Architectures Orientées Services - Introduction à BPMN Version 5.1

A quoi ça sert ?

Répondre aux questions suivantes

o Quelles sont les activités prises en charge ?

o Quelles sont les tâches de chacun ?

o Quels sont les évènement de début et de fin ?

o Que se passe-t-il maintenant ?

o Quelle est la tâche suivante ?

o Est ce que tous les processus ont été modélisés ?

o Quels sont les délais de chaque activité ?

o Quelles sont les données qui circulent ?

o Est que les tâches sont compréhensibles ?

o Est ce que les règles de gestion sont appliquées (pilotage) ?

(c)Leuville Objects 16-421

A quoi ça sert ?

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-422

 Architectures Orientées Services - Introduction à BPMN Version 5.1

Historique

Standard OMG

o Cette norme a été élaborée à l'origine par la Business Process Management Initiative (BPMI) et maintenue par
l'Object Management Group (OMG), puisque les deux organisations ont fusionné en 2005.

o La première version de BPMN 1.0 est fournie par la BPMI en Mai 2004.

o En février 2006, BPMN 1.0 a été officialisée comme un standard OMG.

o En Février 2008 est délivrée la release 1.1 suivie d'une release 1.2 en Janvier 2009.

o La version 2.0 a été officialisée en 2010. Cette version 2 permet de mieux prendre en compte la complexité
des interactions entre processus au travers du concept de "chorégraphie".

o format d’échange XML

o capacité à rendre le modèle "exécutable"

o La BPMN Version 2.0.1 est publiée en Septembre 2013 suivie de la version 2.0.2 en Décembre 2013.

(c)Leuville Objects 16-423

Historique

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-424

 Architectures Orientées Services - Introduction à BPMN Version 5.1

A qui est destiné BPMN ?

Métiers et SI

o La norme BPMN a été conçue pour être utilisée aussi bien par les acteurs métiers de l'entreprise que par les
acteurs du système d'information :

o Des maîtrises d’ouvrage exprimant leur besoin,

o Des consultants métiers pour présenter les macro process de leur client,

o Des bureaux d'études informatiques,

o Des consultants informatiques pour représenter leur processus,

o Des architectes pour modéliser toutes sortes de processus,

o Les développeurs chargés de la mise en place de la technologie d’exécution des processus.

(c)Leuville Objects 16-425

A qui est destiné BPMN?

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-426

 Architectures Orientées Services - Introduction à BPMN Version 5.1

Objectifs

Standard de modélisation de processus

o Standardiser les systèmes de notation graphique permettant de décrire les processus de l'entreprise,
indépendamment de l'outil utilisé,

o Représenter un pont standardisé pour combler le vide entre la modélisation des procédures d'entreprise et leur
mise en place,

o Fournir une notation qui soit réellement compréhensible par tous les utilisateurs de l'entreprise,

o Découpler l'information métier de l'information technique afin de maximiser sa portabilité d'une entreprise à
une autre,

o Fournir un mapping complet vers le langage de programmation BPEL,

o Générer automatiquement et de manière standard le langage BPEL à exécuter par le moteur de processus.

(c)Leuville Objects 16-427

Objectifs

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-428

 Architectures Orientées Services - Introduction à BPMN Version 5.1

Exemple de diagramme BPMN

(c)Leuville Objects 16-429

Exemple de diagramme BPMN

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-430

 Architectures Orientées Services - Introduction à BPMN Version 5.1

Exemple de diagramme BPMN

Le diagramme de collaboration

o Permet de représenter les échanges et les interactions entre deux ou plusieurs unités d'affaires représenté sous
la forme de Couloirs et de Bassins.

(c)Leuville Objects 16-431

Exemple de diagramme BPMN

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-432

 Architectures Orientées Services - Introduction à BPMN Version 5.1

Outils de modélisation

Quelques exemples

(c)Leuville Objects 16-433

Outils de modélisation

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-434

 Architectures Orientées Services - Introduction à BPMN Version 5.1

Outils de modélisation

Camunda

o Modeleur

o Moteur d’exécution basé sur Java / Spring / REST

(c)Leuville Objects 16-435
Outils de modélisation

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-436

 Architectures Orientées Services - Introduction à BPMN Version 5.1

Conclusion

o BPMN est la notation standard la plus adaptée pour modéliser les processus.

o Il est relativement simple et ses diagrammes sont compréhensibles.

o Il est multi-utilisateurs, il cible à la fois les personnels métier et informatique.

o La norme est supportée par plusieurs logiciels (pas de dépendance vers une implémentation particulière).

o BPMN est univoque.

o La définition des règles pour la collaboration entre maîtrise d’ouvrage et maîtrise d’œuvre n’existe pas et
semble nécessaire.

o A partir de BPMN on peut générer le code BPEL correspond, mais cette opération est partielle et peu
opérationnelle.

o La plupart des outils BPMN offrent des fonctionnalités de simulation mais il n’existe pas un standard qui
définit les paramètres de simulation, cette fonction dépend de l’outil utilisé.

o BPMN est peu connu dans la sphère éducative.

(c)Leuville Objects 16-437

Conclusion

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction à BPMN 16-438

Architectures Orientées Services Version 5.1
Model-Driven Architecture

o Architecture à base de composants métier formalisée en UML

o Modèle indépendant des technologies : Platform-Independent Model

o Modèle technique adapté : Platform-Specific Model

o QVT et ATL

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Model-Driven Architecture 17-440
 Architectures Orientées Services - Model-Driven Architecture Version 5.1

Model Driven Architecture

Objectifs

o Proposer une démarche de définition d’architecture

indépendante des technologies

o Faciliter la réutilisation des modèles d’architecture

o Bénéficier plus facilement des évolutions technologiques

o Affirmer UML en tant que standard de modélisation, y

compris pour la formalisation des architectures

Constituants de base

o Unified Modeling Language (UML)

o Meta-Object Facility (MOF)

o XML Meta-Data Interchange (XMI)

o Common Warehouse Meta-model (CWM)

o Mappings : Corba, J2EE, MS .NET, Services WEB

o Services techniques : annuaires, transactions, sécurité, événements

(c)Leuville Objects 17-441

Model Driven Architecture

Objectifs

MDA se propose de formaliser le processus de définition d’une architecture afin de mieux le maîtriser et de
pouvoir réutiliser.

Les outils proposés sont:

o un formalisme basé sur UML,
o un processus en deux étapes distinctes, la première étant indépendante de la technologie, la seconde étant
spécifique à la technologie de la plateforme cible,
o des mécanismes de transformation d’un modèle indépendant des technologies en un modèle spécifique à
un framework particulier,
o un ’mapping’ vers différents frameworks tels que Corba, XML/Soap, J2EE, MS .NET (à venir).

Constituants de base

MDA est bâtie à partir de standards existants de l’OMG:

o UML est utilisé pour la formalisation des modèles d’architecture,
o MOF est un méta-modèle commun à toutes les spécifications de l’OMG,
o XMI est un format normalisé permettant d’échanger des modèles et méta-modèles UML,
o CWM est un méta-modèle orienté datamining.

(c) Leuville Objects Architectures Orientées Services - Model-Driven Architecture 17-442

 Architectures Orientées Services - Model-Driven Architecture Version 5.1

Les modèles MDA

Platform-Independent Model (PIM)

o Représente les structures et comportements métier

sans lien avec une technologie particulière

o Eléments de représentation:

o sémantique exprimée en Action Language

o pré et post-conditions en Object Constraint

Language

Platform-Specific Model (PSM)

o Modèle dérivé du PIM par adaptation à une

technologie middleware spécifique

o Peut-être partiellement généré par des outils

o Utilise des mappings standards OMG

(c)Leuville Objects 17-443

Les modèles MDA

Platform-Independent Model (PIM)

Le modèle PIM est un modèle métier classique formalisé à l’aide de tous les outils UML. Cela inclut donc
au minimum un diagramme de classes métier.

Platform-Specific Model (PSM)

L’OMG a défini plusieurs mappings standards qui sont:

o CORBA
o SOAP / XML
o EJB

Par ailleurs, un mapping vers Microsoft .NET est en cours d’étude.

(c) Leuville Objects Architectures Orientées Services - Model-Driven Architecture 17-444

 Architectures Orientées Services - Model-Driven Architecture Version 5.1

Les transformations MDA

Les possibilités

o D’un modèle indépendant de la technologie

(PIM) vers un modèle spécifique (PSM)

o Rétro-architecture d’un PSM vers un PIM

Les paramètres

o Les patrons de conception

o Les choix techniques

o Les exigences en termes de qualité

Normalisation

o Langage QVT (Query / View / Transformation) de l’OMG

Outillage indispensable.

(c)Leuville Objects 17-445

Les transformations MDA

Les possibilités

MDA prévoit une démarche classique, que l’on pourrait qualifier de démarche descendante du modèle
indépendant de la plateforme cible au modèle spécifique. Mais il est également possible de faire de la rétro-
architecture.

Sans le support d’un outil spécifique, ces démarches ne pourront être mises en oeuvre de façon efficace. Il
faut en effet accompagner le passage d’un modèle à l’autre par un support puissant des design patterns.

Les paramètres

De nombreux paramètres influent la définition du modèle PSM à partir du modèle PIM.

Il est crucial à ce stade d’identifier et utiliser tous les design patterns qui permettront d’automatiser une
partie de ce processus

(c) Leuville Objects Architectures Orientées Services - Model-Driven Architecture 17-446

 Architectures Orientées Services - Model-Driven Architecture Version 5.1

Les transformations MDA

Exemple

o Un modèle métier indépendant

o Deux "branches" principales de

modèles techniques

o les modèles IDL

o les modèles C++

(c)Leuville Objects 17-447

Les transformations MDA

Notes

Le diagramme de paquetages UML représente les différents modèles PIM et PSM ainsi que les liens de
dépendances entre ces modèles.

Dans cet exemple, la technologie employée est Corba en C++.

D’après des documents OMG consultables sur http://www.omg.org/mda

(c) Leuville Objects Architectures Orientées Services - Model-Driven Architecture 17-448

 Architectures Orientées Services - Model-Driven Architecture Version 5.1

Les transformations MDA

Nécessitent un outillage important

(c)Leuville Objects 17-449

Les transformations MDA

Notes

Comme le montre le schéma, le point névralgique de la démarche se situe autour des moyens permettant
d’automatiser le passage du modèle PIM vers différents modèles PSM.

Un outil MDA devra proposer au minimum:

o le support complet de la norme UML,
o des moteurs de génération PIM vers PSM exploitant les mappings OMG standards,
o de puissants moyens de paramétrer cette génération, notamment à l’aide de design patterns,

un support de la démarche de rétro-architecture permettant d’assister la production de modèles PIM à partir

de modèles PSM existants

(c) Leuville Objects Architectures Orientées Services - Model-Driven Architecture 17-450

 Architectures Orientées Services - Model-Driven Architecture Version 5.1

Les mappings ou profils MDA

Ensembles de règles de transformations normalisées.

Adoptés

o Enterprise Distributed Object Computing (EDOC)

o CORBA

o EJB (adopté par le processus JCP)

En travaux

o EAI

o SOAP /XML

A définir

o Microsoft .NET

(c)Leuville Objects 17-451

Les mappings ou profils MDA

Adoptés

De façon naturelle, l’OMG a privilégié le profil CORBA.

Le profil J2EE / EJB a été adopté par le Java Community Process initié par Sun Microsystems.

(c) Leuville Objects Architectures Orientées Services - Model-Driven Architecture 17-452

 Architectures Orientées Services - Model-Driven Architecture Version 5.1

QVT

Langage standardisé pour

définir des transformations de
modèles

o QVT-Relation
Langage déclaratif

o QVT-Operationnal
Règles et expressions
impératives

o QVT-Core
Sémantique des concepts
déclaratifs

Outils supportant QVT

o Borland Together

o SmartQVT

o UMT-QVT

(c)Leuville Objects 17-453

QVT

Notes

http://www.omg.org/docs/ptc/07-07-07.pdf

(c) Leuville Objects Architectures Orientées Services - Model-Driven Architecture 17-454

 Architectures Orientées Services - Model-Driven Architecture Version 5.1

ATL

ATLAS Transformation Language

o Langage opensource de transformation de modèles, utilisé dans l’industrie et maintenu par OBEO, INRIA

o Inspiré de QVT de l’OMG, mais non normalisé

o Disponibilité d’un plugin Eclipse

(c)Leuville Objects 17-455

ATL

Notes

http://www.eclipse.org/atl/

(c) Leuville Objects Architectures Orientées Services - Model-Driven Architecture 17-456

Architectures Orientées Services Version 5.1
Ingénierie Dirigée par les Modèles (IDM) dans un cadre SOA

o Praxeme

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Ingénierie Dirigée par les Modèles (IDM) dans un cadre SOA 18-458
 Architectures Orientées Services - Ingénierie Dirigée par les Modèles (IDM) dans un cadre SOA Version 5.1

MDA et SOA

La vision d’un acteur

(c)Leuville Objects 18-459

MDA et SOA

Notes

D’après http://www.orchestranetworks.com

(c) Leuville Objects Architectures Orientées Services - Ingénierie Dirigée par les Modèles (IDM) dans un cadre SOA 18-460
 Architectures Orientées Services - Ingénierie Dirigée par les Modèles (IDM) dans un cadre SOA Version 5.1

Praxeme

Une méthode publique

o Association loi 1901: Praxeme Institute

o Objectifs :

o aider les entreprises à mettre en oeuvre des architectures SOA

o devenir un socle méthodologique de référence pour les architectures SOA

o Origine : Unilog Management, Orchestra Networks, Softeam, Conix Consulting, Dreamsoft, Vistali

o Contributeurs : Calyon, Armée de Terre, CNAF, SMABTP

Caractéristiques

o Méthode ouverte

o Adaptable aux besoins et à la culture des entreprises

o Permet de modéliser: architecture logique, architecture physique, architecture technique

(c)Leuville Objects 18-461

Praxeme

Notes

http://www.praxeme.org

(c) Leuville Objects Architectures Orientées Services - Ingénierie Dirigée par les Modèles (IDM) dans un cadre SOA 18-462
 Architectures Orientées Services - Ingénierie Dirigée par les Modèles (IDM) dans un cadre SOA Version 5.1

Praxeme

Topologie du Système d’Informations

o Règles de dérivation des modèles

(c)Leuville Objects 18-463

Praxeme

Notes

D’après http://www.praxeme.org

(c) Leuville Objects Architectures Orientées Services - Ingénierie Dirigée par les Modèles (IDM) dans un cadre SOA 18-464
Architectures Orientées Services Version 5.1
Gouvernance SOA

o Centre d’Excellence

o Comite de Gouvernance

o Gestion d’une candidature de service

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Gouvernance SOA 19-466
 Architectures Orientées Services - Gouvernance SOA Version 5.1

Gouvernance

Pour concrétiser les bénéfices SOA

o Assurer la mise en place de services d’entreprise réellement réutilisables

o Aligner le SI avec les processus métier de l’organisation

Moyens

o Centre d’Excellence SOA créé lors de la mise en place initiale de l’architecture SOA

o Comité de Gouvernance qui prend le relais et assure le bon fonctionnement

o Fonctionnement défini par une charte de gouvernance

(c)Leuville Objects 19-467

Gouvernance

(c) Leuville Objects Architectures Orientées Services - Gouvernance SOA 19-468

 Architectures Orientées Services - Gouvernance SOA Version 5.1

Centre d’excellence SOA

Créé à la mise en place de l’architecture SOA

o Centralise la mise en place des services

o Permet de monter en compétences et en maturité SOA

o Comporte à parité des équipes métier et des équipes techniques

o Peut être dissous après plusieurs projets réussis

o Sera remplacé par un Comité de Gouvernance

(c)Leuville Objects 19-469

Centre d’excellence SOA

(c) Leuville Objects Architectures Orientées Services - Gouvernance SOA 19-470

 Architectures Orientées Services - Gouvernance SOA Version 5.1

Centre d’excellence SOA

Rôles

Directeur Métier - Gère et contrôle l’implémentation, l’évolution et l’arrêt du service.

- Dirige le cahier des charges et les contrats du service (interface et opérationnel)
- Met en oeuvre les recommandations de la gouvernance et s’assure que les déve-
loppements nécessaires à la réutilisation du service sont effectués
- Prépare les rapports d’activité du service pour la gouvernance
- Gère les capacités des services pour atteindre les objectifs fixés par la gouver-
nance et assurer un niveau de réutilisation approprié
- Fournit les rapports d’activité au comité de gouvernance
Directeur Technique - Assure la bonne exécution du développement, de l’évolution et du reclassement
des services
- Gère les opérations du service pour atteindre les objectifs en termes de disponi-
bilité, performance et sécurité
Architecte du Socle Technique SOA - Analyse et propose l’utilisation de standards techniques adaptés aux besoins et
capacités des services
Architecte de Domaine SOA - Identifie les services potentiels
- Prépare les propositions de services

(c)Leuville Objects 19-471

Centre d’excellence SOA

(c) Leuville Objects Architectures Orientées Services - Gouvernance SOA 19-472

 Architectures Orientées Services - Gouvernance SOA Version 5.1

Comité de gouvernance

Responsable de la bonne exécution des processus de gouvernance

o Prend le relais du Centre d’Excellence

o Comporte plusieurs rôles

Directeur de Comité de Gouvernance - Gère le bon fonctionnement de tous les aspects organisa-
tionnels, procéduriers et techniques du comité

- Responsable de l’évolution du cycle de vie des services

- Responsable du degré de réutilisation des services

Conseil de Gouvernance - Analyse les propositions de candidature de services

- Définit le modèle de financement des services

- S’assure de la bonne résolution des conflits d’intérêts

entre fournisseurs et consommateurs de services
Gérant du Catalogue de Services - Gère le catalogue de services et facilite la recherche

- Gère la nomenclature des services

(c)Leuville Objects 19-473

Comité de gouvernance

(c) Leuville Objects Architectures Orientées Services - Gouvernance SOA 19-474

 Architectures Orientées Services - Gouvernance SOA Version 5.1

Processus de gouvernance

Activités typiques

o Gérer les candidatures de services

o Gérer les évolutions des services

o Gérer les nouveaux consommateurs de services

o Mettre en place les feuilles de route de réalisation des services

o Adapter la gouvernance

(c)Leuville Objects 19-475

Processus de gouvernance

(c) Leuville Objects Architectures Orientées Services - Gouvernance SOA 19-476

 Architectures Orientées Services - Gouvernance SOA Version 5.1

Processus de gouvernance

Candidature de service

(c)Leuville Objects 19-477

Processus de gouvernance

(c) Leuville Objects Architectures Orientées Services - Gouvernance SOA 19-478

 Architectures Orientées Services - Gouvernance SOA Version 5.1

Processus de gouvernance

A maturité

o Développement de services initié par le Comité de Gouvernance

o Nécessite budget et champ de responsabilité

(c)Leuville Objects 19-479

Processus de gouvernance

(c) Leuville Objects Architectures Orientées Services - Gouvernance SOA 19-480

Architectures Orientées Services Version 5.1
Annexes

o XML et JSON

o oAuth

o Outils

o WS-BPEL

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
 3

(c) Leuville Objects Architectures Orientées Services - Annexes 19-482

Architectures Orientées Services Version 5.1
Introduction aux technologies XML

o Concepts XML

o XML Schema

o Parseurs XML SAX et DOM

o Transformations XML et autres technologies XML

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-484
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Présentation de XML

eXtensible Markup Language

o Permet de modéliser et de stocker des données de façon portable

o Extensible car il permet de définir de nouvelles balises : c'est un métalangage

o Ne permet pas à lui seul d'afficher les données qu'il contient.

o Dérivé de SGML (Standard Generalized Markup Language)

o Ne fait pas d’hypothèse en matière de système d’exploitation et de langage de programmation

Document XML = données structurées

o Les données peuvent faire référence à la structure à laquelle elles sont conformes

o Ce lien permet d’effectuer une validation de conformité

(c)Leuville Objects 20-485

Présentation de XML

eXtensible Markup Language

Le format HTML est utilisé pour formater et afficher les données qu'il contient : il est destiné à structurer,
formater et échanger des documents d'une façon la plus standard possible..

XML est utilisé pour modéliser et stocker des données. Il ne permet pas à lui seul d'afficher les données
qu'il contient.

Pourtant, XML et HTML sont tous les deux des dérivés d'une langage nommé SGML (Standard
Generalized Markup Language). La création d'XML est liée à la complexité de SGML. D'ailleurs, un fichier
XML avec sa DTD correspondante peut être traité par un processeur SGML.

Document XML = données structurées

Les données sont la plupart du temps stockée sous la forme de textes et la structure peut en première
approximation être assimilée à la grammaire d’un langage.

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-486
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Applications de XML

Exemples

o Distribution d’information

o Gestion de données d’entreprise

o Transactions métier et transport de données

o Flux métier

o Gestion des connaissances

o Intégration d’applications

o Descripteurs de déploiement J2EE

o Format externe de persistance de données

o Web Services

(c)Leuville Objects 20-487

Applications de XML

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-488
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Exemple de document XML

Adapté à la représentation de données arborescentes

(c)Leuville Objects 20-489

Exemple de document XML

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-490
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Exemple de document XML

(c)Leuville Objects 20-491

Exemple de document XML

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-492
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Règles syntaxiques XML

Principales

o Le document doit contenir au moins une balise

o Chaque balise d'ouverture (exemple <tag>) doit posséder une balise de fermeture (exemple </tag>). Si le tag
est vide, c'est à dire qu'il ne possède aucune données (exemple <tag></tag>), un tag abrégé peut être utilisé
(exemple correspondant : <tag/>)

o Les balises ne peuvent pas être intercalées (exemple <liste><element></liste></element> n'est pas autorisé)

o Toutes les balises du document doivent obligatoirement être contenues entre une balise d'ouverture et de
fermeture unique dans le document nommée élément racine

o Les valeurs des attributs doivent obligatoirement être encadrées avec des quotes simples ou doubles

o Les balises sont sensibles à la casse

o Les balises peuvent contenir des attributs même les balises vides

o Les données incluses entre les balises ne doivent pas contenir de caractères < et & : il faut utiliser
respectivement &lt ; et &amp ;

o La première ligne du document doit normalement correspondre à la déclaration de document XML : le

prologue.

(c)Leuville Objects 20-493

Règles syntaxiques XML

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-494
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Contrôler la structure d’un document XML

Deux possibilités

o DTD : Document Type Définition

o Structure du document représentée à la façon d’une grammaire d’un langage

o Une DTD n’est pas un document XML

o Pas d’information précise sur les types des données

o Simple à utiliser

Obsolète et interdit avec les Web Services SOAP

o XML Schema

o Nouvelle recommandation W3C

o Est un document XML

o Permet à XML de devenir un vrai langage de définition de données métier

o Associe des types aux données d’un document XML

o Plus complexe à utiliser

(c)Leuville Objects 20-495

Contrôler la structure d’un document XML

Deux possibilités

Les professionnels chargés d'intégrer des données XML dans un système d'information considèrent
aujourd'hui que la simplicité d'expression des DTD ne correspond plus aux besoins des applications
modernes.

Parmi les langages de définition de types récemment proposés pour succéder aux DTD, XML Schéma du
W3C est le plus utilisé, mais aussi l'un des plus difficile à maîtriser.

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-496
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

XMLSchema

Tentative d’amélioration des DTD

o Typage fort et types normalisés par le W3C

o Support des cardinalités autres que 0, 1, plusieurs

o Mécanisme de dérivation

o Espaces de nommage

o XSD exprimé en XML

Mais

o Plus difficiles à construire que des DTD

o Plus difficiles à lire

(c)Leuville Objects 20-497

XMLSchema

Tentative d’amélioration des DTD

Pour pallier les inconvénients des Document Type Définitions, les schémas ont été créés.

Ce sont de vrais fichiers XML dont le but est de valider les documents.

Un schéma est un fichier de type .XSD.

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-498
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Exemple XMLSchema

Données Structure en XSD

<?xml version="1.0" ?> <?xml version="1.0" ?>

<films xsi:noNamespaceSchemaLocation="cine.xsd" <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
xmlns:xsi="http://www.w3.org/...">
<xsd:element name="acteur" type="xsd:string"/>
<film> <xsd:element name="titre" type="xsd:string"/>
<titre>le silence des agneaux</titre>
<acteur>jodie foster</acteur> <xsd:element name="film">
<acteur>anthony hopkins</acteur> <xsd:complexType>
</film> <xsd:sequence>
<xsd:element ref="titre"/>
<film> <xsd:element ref="acteur" maxOccurs="unbounded"/>
<titre>conan le barbare</titre> </xsd:sequence>
<acteur>arnold schwarzenegger</acteur> </xsd:complexType>
</film> </xsd:element>

</films> <xsd:element name="films">

<xsd:complexType>
<xsd:sequence>
<xsd:element ref="film" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

(c)Leuville Objects 20-499

Exemple XMLSchema

Notes

La balise <films xsi:noNamespaceSchemaLocation="cine.xsd"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> inséré dans le document XML permet
d’associer le document à un XMLSchema.

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-500
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Les espaces de nommage XMLSchema

Utilité

o Définir une zone dans laquelle il y a unicité des noms

o Permet d’éviter les collisions de noms d’éléments avec d’autres éléments importés

o Concept analogue à celui de namespace ou de package rencontré dans certains langages de programmation

Définir un espace de nommage

o targetNamespace
<xs:schema version="1.0" targetNamespace="http://www.leuville.com/formation"
xmlns:tns="http://www.leuville.com/formation"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">

Faire référence à un espace de nommage

o xmlns
<formation xmlns="http://www.leuville.com/formation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.leuville.com/formation formation.xsd">

(c)Leuville Objects 20-501

Les espaces de nommage XMLSchema

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-502
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Les parseurs XML

Besoin

o Analyser le contenu de documents XML

o Emplois typiques: travail sur données XML, web services, architectures SOA

Techniques

o Construire une représentation en mémoire : DOM ou Document Object Model

o Déclencher des traitements lors de la rencontre d’éléments particuliers : SAX ou Simple API for XML

Avantages et inconvénients

Avantages Inconvénients
DOM parcours libre de l'arbre gourmand en mémoire
possibilité de modifier la structure et le contenu de doit lire tout le document avant d'exploiter les résul-
l'arbre tats
SAX peu gourmand en ressources mémoire traite les données séquentiellement
rapide un peu plus difficile à programmer, il est souvent
assez simple à mettre en oeuvre nécessaire de sauvegarder des informations pour les
permet de ne traiter que les données utiles traiter

(c)Leuville Objects 20-503

Les parseurs XML

Techniques

Il existe plusieurs types de parseur. Les deux plus répandus sont ceux qui utilisent un arbre pour représenter
et exploiter le document et ceux qui utilisent des événements. Le parseur peut en plus permettre de valider
le document XML.

Ceux qui utilisent un arbre permettent de le parcourir pour obtenir les données et modifier le document.

Ceux qui utilisent des événements associent à des événements particuliers des méthodes pour traiter le
document.

SAX (Simple API for XML) est une API libre créée par David Megginson qui utilisent les événements
pour analyser et exploiter les documents au format XML.

Les parseurs qui produisent des objets composant une arborescence pour représenter le document XML
utilisent le modèle DOM (Document Object Model) défini par les recommandations du W3C.

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-504
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Les parseurs XML

Implémentations DOM

o Apache Xerces 2 : implémentation expérimentale DOM level 3

o Crimson

o Oracle XML Parser

o Microsoft XML Parser : DOM level 1 & 2

Implémentations SAX

o Apache Xerces 2 : implémentation SAX 2.0.1 et SAX2 Extensions 1.0

o J2SE version 1.4.2 (package org.xml.sax)

o Microsoft XML Parser : SAX 1.0 & 2.0

(c)Leuville Objects 20-505

Les parseurs XML

Notes

SAX et DOM ne fournissent que des définitions : ils ne fournissent pas d'implémentation utilisable.
L'implémentation est laissée aux différents éditeurs qui fournissent un parseur compatible avec SAX et/ou
DOM. L'avantage d'utiliser l'un deux est que le code utilisé sera compatible avec les autres : le code
nécessaire à l'instanciation du parseur est cependant spécifique à chaque fournisseur.

IBM fourni gratuitement un parseur XML : xml4j. Il est téléchargeable à l'adresse suivante :
http://www.alphaworks.ibm.com/tech/xml4j

Le groupe Apache développe Xerces à partir de xml4j : il est possible de télécharger la dernière version à
l'URL http://xml.apache.org

Sun a développé un projet dénommé Project X. Ce projet a été repris par le groupe Apache sous le nom de
Crimson.

Ces trois projets apportent pour la plupart les mêmes fonctionnalitées : ils se distinguent sur des points
mineurs : performance, rapidité, facilité d'utilisation etc. ... Ces fonctionnalités évoluent très vite avec les
versions de ces parseurs qui se succèdent très rapidement.

Pour les utiliser, il suffit de dézipper le fichier et d'ajouter les fichiers .jar dans la variable définissant le
CLASSPATH.

Il existe plusieurs autres parseurs que l'on peut télécharger sur le web.

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-506
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Principes DOM

Spécification W3C

o Construire une représentation

mémoire arborescente d’un
document XML

o Indépendance vis-à-vis des

langages de programmation

o Permettre la manipulation du
document et notamment sa
modification

o Implémentation Java
regroupée dans le package
org.w3c.dom

(c)Leuville Objects 20-507

Principes DOM

Spécification W3C

Il existe deux versions de DOM nommées «niveau» :

o DOM Core Level 1 : cette spécification contient les bases pour manipuler un document XML (document,
élément et noeud)
o DOM Core Level 2 :

Le niveau 3 est en cours de développement.

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-508
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Principes SAX

www.megginson.com/SAX/index.html

Programmation événementielle

o Handlers implémentant des interfaces d’écoute d’éléments

Deux versions

o SAX 1

o SAX 2

o Apporte le support des espaces de nommages

o Principes de fonctionnement très proches de SAX 1

o Evolutions d’API

(c)Leuville Objects 20-509

Principes SAX

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-510
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Technologies XML

Grand nombre de spécifications

o DTD, Schémas XML : Définition de structures XML

o DOM, SAX : Parsing de documents XML

o XSL, XSLT, XSL-FO : Transformation de documents XML

o XPath : Système de sélection de noeuds

o XQuery : Requêtes sur un document XML

o XPointer : Référence à un fragment de document XML

o ...

(c)Leuville Objects 20-511

Technologies XML

Notes

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-512
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

eXtensible Stylesheet Language (XSL)

o Transformer un document XML en un autre document

o Véritable langage de programmation

o Interprété directement par certains navigateurs

Deux constituants

o Transformation des données avec XSLT (XSL Transformation)

o Sélection de noeuds

o Application de règles de gabarits (template rules) pour transformer un arbre source en arbre destination

o Formattage des données avec XSL-FO (XSL Formatting Objects)

o Application de mises en formes

o Processeurs prêts à l’emploi, comme FOP pour produire des documents PDF

(c)Leuville Objects 20-513

eXtensible Stylesheet Language (XSL)

Deux constituants

Un document XML peut être représenté comme une structure arborescente. Ainsi XSLT permet de
transformer les documents XML à l'aide de feuilles de style contenant des règles appelées template rules
(ou règles de gabarit en français).

Le processeur XSLT (composant logiciel chargé de la transformation) crée une structure logique
arborescente (on parle d'arbre source) à partir du document XML et lui fait subir des transformations selon
les template rules contenues dans la feuille XSL pour produire un arbre résultat représentant, par exemple,
la structure d'un document HTML. Les composants de l'arbre résultat sont appelés objets de flux.

Chaque template rule définit des traitements à effectuer sur un élément (noeud ou feuille) de l'arbre source.
On appelle "patterns" (en français motifs, parfois "éléments cibles") les éléments de l'arbre source.

L'arbre source peut être entièrement remodelé et filtré ainsi qu'ajouter du contenu à l'arbre résultat, si bien
que l'arbre résultat peut être radicalement différent de l'arbre source.

le langage de formatage des données (XSL/FO), c'est-à-dire un langage permettant de définir la mise en
page (affichage de texte ou de graphiques) de ce qui a été créé par XSLT.

Une fois l'arbre source créé, XSL/FO permet de formater le résultat, c'est-à-dire d'interpréter l'arbre résultat,
ou plus exactement les objets de flux le composant en leur appliquant des objets de mise en forme afin d'en
faire une représentation visuelle (papier, écran, ...)

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-514
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Exemple XSLT

Production d’une page HTML à partir d’un document XML

<?xml version="1.0"?> <?xml version='1.0'?>

<BIB> <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<LIVRE> <xsl:template match="/">
<TITRE>titre livre 1</TITRE> <html>
<AUTEUR>auteur 1</AUTEUR> <body>
<EDITEUR>editeur 1</EDITEUR> <table border="1" cellspacing="0" cellpadding="3">
</LIVRE> <tr bgcolor="#FFFF00">
<LIVRE> <td>Titre</td> <td>Auteur</td> <td>Editeur</td>
<TITRE>titre livre 2</TITRE> </tr>
<AUTEUR>auteur 2</AUTEUR> <xsl:for-each select="BIB/LIVRE"><tr>
<EDITEUR>editeur 2</EDITEUR> <td><xsl:value-of select="TITRE"/></td>
</LIVRE> <td><xsl:value-of select="AUTEUR"/></td>
<LIVRE> <td><xsl:value-of select="EDITEUR"/></td>
<TITRE>titre livre 3</TITRE> </tr></xsl:for-each>
<AUTEUR>auteur 3</AUTEUR> </table>
<EDITEUR>editeur 3</EDITEUR> </body>
</LIVRE> </html>
</BIB> </xsl:template>
</xsl:stylesheet>

(c)Leuville Objects 20-515

Exemple XSLT

Production d’une page HTML à partir d’un document XML

Après les balises de départ d'un fichier XSL, on aborde un tableau tout à fait classique en Html.

Pour chaque élément de type "BIB/LIVRE", on remplit la cellule correspondante au titre par la balise
xsl:value-of avec l'attribut select="TITRE" qui indique comme chemin d'accès la balise racine BIB, la
balise LIVRE et la balise TITRE. Et bien entendu de même pour les balises AUTEUR et EDITEUR.

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-516
 Architectures Orientées Services - Introduction aux technologies XML Version 5.1

Exemple XSLT

Production d’une page HTML à partir d’un document XML

o Lien entre XML et XSL

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="bib.xsl"?>
<BIB>
<LIVRE>
<TITRE>titre livre 1</TITRE>
<AUTEUR>auteur 1</AUTEUR>
<EDITEUR>editeur 1</EDITEUR>
</LIVRE>
<LIVRE>
<TITRE>titre livre 2</TITRE>
<AUTEUR>auteur 2</AUTEUR>
<EDITEUR>editeur 2</EDITEUR>
</LIVRE>
<LIVRE>
<TITRE>titre livre 3</TITRE>
<AUTEUR>auteur 3</AUTEUR>
<EDITEUR>editeur 3</EDITEUR>
</LIVRE>
</BIB>

(c)Leuville Objects 20-517

Exemple XSLT

Production d’une page HTML à partir d’un document XML

On ajoute au fichier XML le lien vers la feuille de style XSL.

(c) Leuville Objects Architectures Orientées Services - Introduction aux technologies XML 20-518
Architectures Orientées Services Version 5.1
JavaScript Object Notation

o Présentation de JSON

o Formalisme

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - JavaScript Object Notation 21-520
 Architectures Orientées Services - JavaScript Object Notation Version 5.1

JSON

Présentation

o Format de données textuel, générique, dérivé de la notation des objets du langage ECMAScript.

o Permet de représenter de l’information structurée.

o Employé dans les applications AJAX pour la communication client-serveur

o Créé par Douglas Crockford, décrit dans la RFC 4627 de l’IETF.

http://www.ietf.org/rfc/rfc4627.txt

(c)Leuville Objects 21-521

JSON

Notes

(c) Leuville Objects Architectures Orientées Services - JavaScript Object Notation 21-522
 Architectures Orientées Services - JavaScript Object Notation Version 5.1

Structure d’un document JSON

Syntaxe et types issus de Javascript

o Un document JSON ne comprend que deux éléments structurels :

o des ensembles de paires nom/valeur;

o des listes ordonnées de valeurs.

o Ces mêmes éléments représentent 3 types de données :

o des objets ;

o des tableaux ;

o des valeurs génériques de type tableau, objet, booléen, nombre, chaîne ou null.

(c)Leuville Objects 21-523

Structure d’un document JSON

Notes

(c) Leuville Objects Architectures Orientées Services - JavaScript Object Notation 21-524
 Architectures Orientées Services - JavaScript Object Notation Version 5.1

Structure d’un document JSON

Exemples
{"menu": {
"id": "file",
"value": "File",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}
]
}
}}

{
"product": {
"name": "Widget",
"company": "ACME, Inc",
"partNumber": "7402-129",
"prices": [
{ "minQty": 1, "price": 12.49 },
{ "minQty": 10, "price": 9.99 },
{ "minQty": 50, "price": 7.99 }
]
}
}

(c)Leuville Objects 21-525

Structure d’un document JSON

Notes

(c) Leuville Objects Architectures Orientées Services - JavaScript Object Notation 21-526
 Architectures Orientées Services - JavaScript Object Notation Version 5.1

Structure d’un document JSON

Représentation d’un objet

Représentation d’un tableau de valeurs

Valeurs possibles

(c)Leuville Objects 21-527

Structure d’un document JSON

Notes

(c) Leuville Objects Architectures Orientées Services - JavaScript Object Notation 21-528
 Architectures Orientées Services - JavaScript Object Notation Version 5.1

Structure d’un document JSON

Représentation d’une chaîne de caractères

(c)Leuville Objects 21-529

Structure d’un document JSON

Notes

(c) Leuville Objects Architectures Orientées Services - JavaScript Object Notation 21-530
 Architectures Orientées Services - JavaScript Object Notation Version 5.1

Structure d’un document JSON

Représentation d’une valeur numérique

(c)Leuville Objects 21-531

Structure d’un document JSON

Notes

(c) Leuville Objects Architectures Orientées Services - JavaScript Object Notation 21-532
 Architectures Orientées Services - JavaScript Object Notation Version 5.1

Avantages de JSON

Format léger

o Format portable, indépendant des plateformes et des langages de programmation.

o Permet de représenter n’importe quelle donnée concrète.

o Peu verbeux (moins que XML).

o Facile à apprendre.

o Types de donnés connus et simples à écrire.

(c)Leuville Objects 21-533

Avantages de JSON

Notes

(c) Leuville Objects Architectures Orientées Services - JavaScript Object Notation 21-534
 Architectures Orientées Services - JavaScript Object Notation Version 5.1

Utilisation de JSON

Permet de faire communiquer des applications dans un environnement hétérogène.

o Langage de transport de données utilisé par AJAX et les Services Web, transport effectué par HTTP

o Type mime associé : application/json

o Un document JSON représente un object JavaScript, son interprétation est donc simplifiée en JavaScript.

Utilisation avec JavaScript

o En JavaScript, il est très simple d’évaluer une expression JSON pour la transformer en objet natif

var donnees = eval('('+donnees_json+')');

o Attention, cette méthode évalue et exécute n’importe quel code JavaScript, y compris du code indésirable.

o On préfèrera utiliser: var doc = JSON.parse(donnees_json);

o Ce parseur reconnaît uniquement les textes au format JSON et rejette toute forme de script.

(c)Leuville Objects 21-535

Utilisation de JSON

Notes

(c) Leuville Objects Architectures Orientées Services - JavaScript Object Notation 21-536
Architectures Orientées Services Version 5.1
Présentation oAuth

o Objectifs du protocole oAuth

o Historique

o Possibilités de mise en oeuvre

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-538
 Architectures Orientées Services - Présentation oAuth Version 5.1

Présentation du protocole OAuth

http://oauth.net/

o Authentification/autorisation simple et standard depuis une application web ou une

application bureautique

o Permet d’interagir avec des données protégées tout en protégeant les Credentials des utilisateurs

o Permet à une application ou site web "Service consumer" d’accéder aux ressources protégées d’un service web
"Service provider" via une API

o Gère les autorisations sans avoir besoin de donner son identité

o Utilisé par de nombreux services:

o OpenStreetMap utilise OAuth pour ses API

o Twitter utilise exclusivement OAuth pour ses API

o Gmail utilisera également OAuth

o Foursquare utilise OAuth pour ses API

o Facebook utilise OAuth 2.0 pour ses API

o Windows Live utilisera OAuth 2.0 pour se connecter à sa plateforme.

(c)Leuville Objects 22-539

Présentation du protocole OAuth

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-540

 Architectures Orientées Services - Présentation oAuth Version 5.1

Historique

oAuth 1

o 1.0 : octobre 2007

o 1.0a : juin 2009

o Considérée comme obsolète

Faille de sécurité rendant obligatoire l’utilisation de la version 1a

oAuth 2

o http://tools.ietf.org/html/rfc6749

o Mai 2010

o Controversée

o le "leader" des travaux de spécification s’est retiré du projet et a demandé que son nom n’y figure plus

o nombreux choix laissés à l’implémentation, ce qui limite l’interopérabilité

o Mais largement utilisée par les réseaux sociaux

(c)Leuville Objects 22-541

Historique

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-542

 Architectures Orientées Services - Présentation oAuth Version 5.1

Fonctionnement général

Scénario typique

o Accès à l'application (Client App)

o L'application demande à s'identifier à l'aide d’un service tiers

(Facebook par exemple)

o L'utilisateur est redirigé vers une page de login de Facebook qui

en plus des informations d'identification demande si l'utilisateur
accepte l'accès à ses données Facebook par l'application (Client
App).

o L'utilisateur est identifié et a donné les permissions d'accès.

Facebook le redirige vers une page de Client app. Cette URI a été
fournie par Client App au moment de l'enregistrement de Client
App avec Facebook (préalable). Durant cet enregistrement
préalable, Facebook (Authenticating Application) fournit : un
client id et un client password. Cette URI est complétée par
Facebook avec un code d'authentification : il représente
l'authentification.

o L'utilisateur accède à la page. L'application contacte Facebook et

lui envoie : le code d'authentification, le client id et le client
password. Facebook retourne un access token.

o Une fois cet access token reçu par l'application, il peut être envoyé à Facebook pour accéder aux informations détenues
par Facebook et partagées avec Client App.

(c)Leuville Objects 22-543

Fonctionnement général

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-544

 Architectures Orientées Services - Présentation oAuth Version 5.1

Fonctionnement général

Vocabulaire

o Client id et Client password : informations fournies par l'application tierce d'authentification au moment de
l'enregistrement préalable de l'application cliente

o Redirect URI : URI fournie par l'application cliente au moment de l'enregistrement de celle-ci avec
l'application d'authentification

o Application d'authentification (Authenticating application) : Facebook

o Application client : Client App

o Authentication code (code authentification) : code fourni par l'application d'authentification suite à
l'identification.

o Access Token : jeton échangé par les applications permettant l'accès aux ressources. Durée de vie limitée.

(c)Leuville Objects 22-545

Fonctionnement général

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-546

 Architectures Orientées Services - Présentation oAuth Version 5.1

Rôles

o Resource Owner : Personne ou application qui détient l'information (ressources) qui doit être partagée. Par
exemple, l'utilisateur de Facebook.

o Client Application : Application demandant l'accès aux ressources stockées dans le Resource Server.

o Resource Server : Serveur qui héberge les ressources. Facebook est un resource server (en tout cas, en dispose
d'un).

o Authorization Server: Serveur qui donne l'autorisation d'accès aux ressources à l'application cliente.
L'Authorization Server et le Resource Server peuvent être le même serveur.

(c)Leuville Objects 22-547

Rôles

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-548

 Architectures Orientées Services - Présentation oAuth Version 5.1

Enregistrement préalable

Entre l’application cliente et le "tiers" d’authenfication

o L’application cliente doit obtenir auprès du "tiers":

o une clé "Consumer Key"

o un secret partagé "Shared Secret"

o Ensuite, il y a échange d’un jeton temporaire entre les deux partenaires

o Ce jeton temporaire est converti par le "tiers" en access token si l’utilisateur accepte l’accès à ses ressources

o Avec cet access token, le client peut utiliser l’API du tiers au nom de l’utilisateur, tant qu’il est valable

Limitations

o Pas de mécanisme granulaire d’autorisation permettant de décrire précisément les opérations concernées

o un utilisateur se connecte au service X grâce à ses informations de login chez Y

o X et Y se sont entendus préalablement sur la nature des accès faits par X sur Y

o Y vous présente (éventuellement) un descriptif succinct de ce qu’il fera sur X avec votre autorisation

o Redirections vulnérables au phishing

o Les secrets partagés doivent être bien protégés (TLS/SSL)

(c)Leuville Objects 22-549

Enregistrement préalable

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-550

 Architectures Orientées Services - Présentation oAuth Version 5.1

Exemple de processus

Selon Yahoo

o Entente préalable

o Demande d’accès à
l’utilisateur

(c)Leuville Objects 22-551

Exemple de processus

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-552

 Architectures Orientées Services - Présentation oAuth Version 5.1

Exemple de processus

Selon Yahoo

o Redirection vers l’application

suite à l’autorisation donnée par
l’utilisateur d’accéder aux
données détenues par Yahoo

o Obtention d’un Access Token

par l’application

o Eventuellement
"rafraichissement" de ce token
en cas d’expiration

(c)Leuville Objects 22-553

Exemple de processus

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-554

 Architectures Orientées Services - Présentation oAuth Version 5.1

Les types d’autorisations

Authorization grant

o L'authorization grant est fourni par le resource owner en collaboration avec l'Authorization Server (suite à la
question " autorisez-vous l'accès ? " et l'identification)

o Les spécifications OAuth 2 en définissent 4 à utiliser en fonction du type d'application cliente et de la nature
de l’authentification

Authorization Grant Type d’application cliente

Authorization Code Application web Le secret partagé peut être gardé confidentiel sur le ser-
veur.
Implicit Application navigateur Le secret ne peut pas être conservé confidentiel. Un autre
Application mobile mécanisme est employé.
Password Application sous la responsa- L’application client demande à l’utilisateur son mot de
bilité de l’Authorization Ser- passe enregistré sur Authorization Server. Dans ce scéna-
ver rio, l’application cliente a été créée par le responsable de
l’Authorization Server.
Client Credentials Application Mode utilisé pour authentifier une application et non un
utilisateur.

(c)Leuville Objects 22-555

Les types d’autorisations

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-556

 Architectures Orientées Services - Présentation oAuth Version 5.1

Authorization Code

Fonctionnement

o Le Resource owner (utilisateur) accède à l'application cliente.

o L'application cliente lui demande de s'identifier à l'aide de

l'authorization server (Facebook par exemple). L'application
cliente fournit le Client ID et le Client Secret. Ainsi, l'authorization
server peut identifier l'application cliente.

o L'utilisateur s'identifie auprès de l'authorization server.

o Après le succès de l'identification, l'utilisateur doit autoriser l'accès

à ses ressources hébergées sur le resource server à l'application
cliente. S'il accepte, il est redirigé vers l'URI de redirection fournie
à l'enregistrement de l'application cliente. L'authorization server
fournit l'authorization code. Il représente l'autorisation d'accès.

o L'utilisateur est redirigé vers l'URI de redirection

o L'application cliente envoie le client ID, le client secret et

l'authorization code à l'authorization server.

o Si celui-ci accepte ces valeurs, il retourne l'access token qui sera

utilisé par l'application cliente pour accéder aux ressources pendant
la durée de validité de l’acces token.

(c)Leuville Objects 22-557

Authorization Code

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-558

 Architectures Orientées Services - Présentation oAuth Version 5.1

Authorization Code: échanges HTTP

Authorization HTTP Request (envoyée par l’application cliente)

o response_type: valeur positionnée à code

o client_id: Obligatoire. Identification de l'application cliente

o redirect_uri: Optionnel. URI de redirection enregistrée par le client

o scope: Optionnel. Scope de la requête

o state: Optionnel (mais recommandé). Etat devant être fourni au client.

Exemple

o L’application cliente fournit un lien permettant de se logger

https://oauth2server.com/auth?response_type=code
&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos

o L’utilisateur voit alors une demande de type:

Une application souhaite se connecter à votre compte et obtenir l’accès à vos informations de profil et à vos
photos. Autorisez-vous cet accès ? <OUI> <NON>

(c)Leuville Objects 22-559

Authorization Code: échanges HTTP

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-560

 Architectures Orientées Services - Présentation oAuth Version 5.1

Authorization Code: échanges HTTP

Authorization HTTP Response

o code: Authorization code

o state: Obligatoire si présent dans la requête.

https://oauth2client.com/cb?code=AUTH_CODE

Authorization Error HTTP Response

o Le client n'est pas authentifié ou non reconnu (erreur dans l'uri de redirection, client id erroné….)

o Le client a pu être authentifié mais un autre problème est survenu.

o Contenu

o error: Code erreur.

o error_description: Optionnel. Texte description de l'erreur (format UTF-8)

o error_uri: Optionnel. URI d'une page web donnant des informations sur l'erreur produite.

o state: Obligatoire si présent dans la requête.

(c)Leuville Objects 22-561

Authorization Code: échanges HTTP

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-562

 Architectures Orientées Services - Présentation oAuth Version 5.1

Authorization Code: échanges HTTP

Token Request POST https://api.oauth2server.com/token

grant_type=authorization_code&
o grant_typeValeur positionnée à authorization_code code=AUTH_CODE&
o codeAuthorization code reçu redirect_uri=REDIRECT_URI&
client_id=CLIENT_ID&
o redirect_uriObligatoire si celle-ci a été inclue dans la client_secret=CLIENT_SECRET
requête d'autorisation. Elles doivent être identiques.

Token Response (format JSON) {

"access_token":"RsT5OjbzRn430zqMLgV3Ia"
o Le token reçu est au format JSON. }
{
"access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
"refresh_token" : "...",
}
o access_token: Valeur du token telle que positionnée par l'Authorization Server

o token_type: Type de token

o expires_in: Durée de validité du token en millisecondes.

o refresh_token: Token de rafraîchissement dans le cas où l'access token viendrait à expirer.

(c)Leuville Objects 22-563

Authorization Code: échanges HTTP

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-564

 Architectures Orientées Services - Présentation oAuth Version 5.1

Implicit

Fonctionnement

o Fonctionne presque comme l'authorization code. La

différence réside dans le fait que l'authorization server
communique directement à l'application cliente un
access token (au lieu de fournir un authorization code
puis un access token).

o Mode de fonctionnement à destination des applications

de type browser (javascript) ou application mobile où le
" client secret " ne peut être stocké de façon
confidentielle (puisque disponible). L'application cliente
ne fournira que le client ID.

(c)Leuville Objects 22-565

Implicit

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-566

 Architectures Orientées Services - Présentation oAuth Version 5.1

Implicit: Requêtes/réponses HTTP

Implicit Grant Request

o response_type: valeur positionnée à token

o client_id: Obligatoire. Identification de l'application cliente

o redirect_uri: Optionnel. URI de redirection enregistrée par le client

o scope: Optionnel. Scope de la requête

o state: Optionnel (mais recommandé). Etat devant être fourni au client.

Implicit Grant Response

o La réponse n'est pas au format JSON !

o access_token: Valeur du token tel que positionné par l'Authorization Server

o token_type: Type de token.

o expires_in: Durée de validité du token en millisecondes.

o scope: Optionnel. Scope de la requête

o state: Optionnel (mais recommandé). Etat devant être fourni au client.

(c)Leuville Objects 22-567

Implicit: Requêtes/réponses HTTP

Notes

En cas d’erreur d’authentification, la réponse d’erreur est au même format que dans le cas de l’authorization
code.

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-568

 Architectures Orientées Services - Présentation oAuth Version 5.1

Resource Owner password credentials

o L'application cliente collecte le login / password puis les fournit à l'authorization server pour obtenir l'access
token.

Request

o grant_type: Valeur positionnée à password

o username: Obligatoire. Format UTF-8. Nom du Resource Owner

o password: Obligatoire. Format UTF-8. Mot de passe du Resource Owner

o scope: Optionnel. Scope de l'autorisation

Response

o Le token reçu est au format JSON.

{
"access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
"refresh_token" : "...",
}

(c)Leuville Objects 22-569

Resource Owner password credentials

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-570

 Architectures Orientées Services - Présentation oAuth Version 5.1

Client credentials

o L'application cliente a besoin d'accéder à des informations qui ne sont pas spécifiques au resource owner
(l'utilisateur).

Request

o grant_type: Valeur positionnée à client_credentials

o scope: Optionnel. Scope de l'autorisation

Response

o Le token reçu est au format JSON.

{
"access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
}

(c)Leuville Objects 22-571

Client credentials

Notes

(c) Leuville Objects Architectures Orientées Services - Présentation oAuth 22-572

Architectures Orientées Services Version 5.1
Offre SOA

o Bus ESB commerciaux et open-source

o BEA

o Oracle

o IBM

o Microsoft

o TIBCO

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-574
 Architectures Orientées Services - Offre SOA Version 5.1

Bus ESB

Commerciaux

o Aqualogic Service Bus de BEA

o WebSphere Application Server V6 d'IBM

o webMethods ESB Platform de Software AG

o Sonic ESB de Progress Software

o SpiritWave de spiritsoft

o ENS Server de Kenamea

o Artix de Iona

o Cape clear de Cape clear

o Oracle Enterprise Service Bus de Oracle Corporation

o iWay SOA Middleware de iWay Software

o Information Builders

o TIBCO BusinessWorks™

o Sybase a aussi une offre ESB.

(c)Leuville Objects 23-575

Bus ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-576

 Architectures Orientées Services - Offre SOA Version 5.1

Bus ESB

Produits Open-source

o Servicemix de la fondation Apache

o Mule

o JBossESB de JBoss

o Celtix de Iona dans le cadre d'ObjectWeb qui implémente une pile conforme au standard JAX-WS

o PEtALS de EBM Websourcing qui est le conteneur JBI du consortium ObjectWeb.

o Open ESB

(c)Leuville Objects 23-577

Bus ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-578

 Architectures Orientées Services - Offre SOA Version 5.1

La vision SOA d’un fournisseur : BEA Systems

Gamme AquaLogic

o Une architecture de référence

o Une approche spécifique de

l’assemblage par configuration

o Un ensemble de produits

(c)Leuville Objects 23-579

La vision SOA d’un fournisseur : BEA Systems

Notes

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-580

 Architectures Orientées Services - Offre SOA Version 5.1

La vision SOA d’un fournisseur : BEA Systems

(c)Leuville Objects 23-581

La vision SOA d’un fournisseur : BEA Systems

Notes

http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/solutions/soa/

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-582

 Architectures Orientées Services - Offre SOA Version 5.1

La vision SOA d’un fournisseur : Oracle

(c)Leuville Objects 23-583

La vision SOA d’un fournisseur : Oracle

Notes

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-584

 Architectures Orientées Services - Offre SOA Version 5.1

La vision SOA d’un fournisseur : IBM

IBM SOA Foundation

o Une architecture de référence

o Des produits et outils : modélisation - assemblage - déploiement - administration

(c)Leuville Objects 23-585

La vision SOA d’un fournisseur : IBM

Notes

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-586

 Architectures Orientées Services - Offre SOA Version 5.1

La vision SOA d’un fournisseur : IBM

Un cycle de développement par les processus métier

(c)Leuville Objects 23-587

La vision SOA d’un fournisseur : IBM

Notes

http://www-306.ibm.com/software/fr/soa/offres/

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-588

 Architectures Orientées Services - Offre SOA Version 5.1

La vision SOA d’un fournisseur : IBM

Un modèle qui capitalise sur l’existant

(c)Leuville Objects 23-589

La vision SOA d’un fournisseur : IBM

Notes

D’après http://www.ibm.com/developerworks/webservices/library/ws-bdd/

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-590

 Architectures Orientées Services - Offre SOA Version 5.1

La vision SOA d’un fournisseur : MICROSOFT

D’une architecture de composants ou d’applications vers une architecture de services

(c)Leuville Objects 23-591

La vision SOA d’un fournisseur : MICROSOFT

Notes

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-592

 Architectures Orientées Services - Offre SOA Version 5.1

La vision SOA d’un fournisseur : MICROSOFT

Produits

o Construction de services Web

o Framework .NET: Windows Communication Foundation, Windows Workflow Foundation

o Visual Studio

o Intégration et Orchestration de services Web

o BizTalk Server

o Exposition et consommation de services Web

o Windows Vista

o Office 2007

o SharePoint Server 2007

o Office Business Applications (OBA)

(c)Leuville Objects 23-593

La vision SOA d’un fournisseur : MICROSOFT

Notes

http://www.microsoft.com/france/biztalk/utilisez/livres-blancs/soa/livre-blanc.mspx

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-594

 Architectures Orientées Services - Offre SOA Version 5.1

La vision d’un fournisseur: TIBCO

Définition et concepts SOA

o Style d’architecture et une façon de gérer le SI

o Capacité du SI à s’aligner sur les processus métier (agilité)

o Couplage lâche

o Importance de la notion d’événements métier

Une plateforme : TIBCO real-time enterprise platform

(c)Leuville Objects 23-595

La vision d’un fournisseur: TIBCO

Notes

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-596

 Architectures Orientées Services - Offre SOA Version 5.1

La vision d’un fournisseur: TIBCO

Service

o Adapter : supporte les

adaptations entre les
services et les
implémentations "legacy".

o Host System

o TIBCO
BusinessWorks

o Moteur BPM

(c)Leuville Objects 23-597

La vision d’un fournisseur: TIBCO

Notes

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-598

 Architectures Orientées Services - Offre SOA Version 5.1

La vision d’un fournisseur: TIBCO

TIBCO BusinessWorks

(c)Leuville Objects 23-599

La vision d’un fournisseur: TIBCO

Notes

Emploi d’une métaphore graphique pour représenter les processus métier.

(c) Leuville Objects Architectures Orientées Services - Offre SOA 23-600

Architectures Orientées Services Version 5.1
Les principaux outils Open Source

o Les outils Open Source s’intégrant dans une SOA

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects, est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-602
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les serveurs de messagerie

Apache Active MQ

o http://activemq.apache.org

o Message Broker de la fondation Apache.

o Développé suivant les Enterprise Integration Patterns

o API d’accès en divers langages, dont Java avec JMS.

Apache Qpid

o http://qpid.apache.org

o Autre système de messagerie de la fondation Apache.

o API d’accès en divers langage, dont Java avec JMS.

(c)Leuville Objects 24-603

Les serveurs de messagerie

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-604
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les serveurs de messagerie

Fuse Message Broker

o http://fusesource.com/products/enterprise-activemq/

o Basé sur Apache Active MQ, mais propose en plus Camel pour le routage et Fuse Integration Designer pour
la mise en oeuvre des EIP.

OpenJMS

o http://openjms.sourceforge.net/

o Implémentation Open Source de JMS.

JBoss Messaging

o http://www.jboss.org/jbossmessaging/

o Implémentation Red Hat de JMS.

(c)Leuville Objects 24-605

Les serveurs de messagerie

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-606
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les serveurs de messagerie

JORAM

o http://joram.objectweb.org/

o Implémentation JMS par ObjectWeb.

Open Message Queue

o https://mq.dev.java.net/

o Implémentation JMS du projet GlassFish.

(c)Leuville Objects 24-607

Les serveurs de messagerie

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-608
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les routeurs

Apache Camel

o http://camel.apache.org/

o Framework Open Source permettant d’implémenter les routeurs des EIP.

o Configuration par DSL (Domain Specific Language), par Spring (XML) ou via Scala DSL

(c)Leuville Objects 24-609

Les routeurs

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-610
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les frameworks Web Service

o Framework compatibles JAX-WS

Apache CXF

o http://cxf.apache.org/

o Framework de développement de Web Services, compatible JAX-WS.

o Permet également de développer des Services RESTful.

o Supporte les protocoles HTTP, JMS et JBI.

Apache Axis 2

o http://ws.apache.org/axis2/

o Framework de développement de Web Services, compatible JAX-WS.

Implémentation de référence

o https://jax-ws.dev.java.net/

o Implémentation de référence, intégré dans le projet GlassFish/Metro.

(c)Leuville Objects 24-611

Les frameworks Web Service

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-612
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les moteurs BPEL

Active BPEL

o http://www.activevos.com/community-open-source.php

Apache ODE

o http://ode.apache.org/

o Moteur BPEL de la fondation Apache

o Communication via Axis2 (Web Services) et JBI.

PXE

o http://sourceforge.net/projects/pxe

(c)Leuville Objects 24-613

Les moteurs BPEL

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-614
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les ESB

Apache Servicemix

o http://servicemix.apache.org/home.html

o ESB de la fondation Apache, développé suivant la spécification JBI.

(c)Leuville Objects 24-615

Les ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-616
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les ESB

Mule

o http://www.mulesource.org/display/MULE/Home

OpenESB

o https://open-esb.dev.java.net/

o Distribution stable : GlassFish ESB

o ESB développé suivant la spécification JBI.

(c)Leuville Objects 24-617

Les ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-618
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les ESB

Celtix

o http://celtix.objectweb.org/

o ESB Open Source par Object Web

PEtALS

o http://petals.ow2.org/

o ESB implémentant la spécification JBI.

(c)Leuville Objects 24-619

Les ESB

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-620
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les bundles

Fuse

o http://fusesource.com/

o Racheté par RedHat pour remplacer JBoss ESB

(c)Leuville Objects 24-621

Les bundles

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-622
 Architectures Orientées Services - Les principaux outils Open Source Version 5.1

Les outils de développement

Eclipse SOA Tools Platform Project

o http://www.eclipse.org/stp/

o Projet de plug-ins Eclipse facilitant le développement de composants SOA.

o Actuellement toujours en pahese d’incubation.

NetBeans

o http://www.netbeans.org/kb/trails/soa.html

o Ensemble d’outils facilitant le développement de composants SOA (BPEL, JBI, ...).

(c)Leuville Objects 24-623

Les outils de développement

Notes

(c) Leuville Objects Architectures Orientées Services - Les principaux outils Open Source 24-624
Architectures Orientées Services Version 5.1
WS-BPEL / Business Process Execution Language

o Utilité de l’orchestration des services

o Historique

o Concepts de base

(c) Leuville Objects. Tous droits de traduction, d’adaptation et de reproduction par tous procédés, réservés pour tous pays.
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit des pages publiées dans le présent ouvrage,
faite sans l’autorisation de Leuville Objects est illicite et constitue une contrefaçon (loi du 11 mars 1957 et code de la propriété
intellectuelle du 1er juillet 1992, articles L 122-4, L 122-5 et L 335-2).
(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-626
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

L’orchestration des Services Web

id ESB

Un besoin : l’intégration
«application» «application» «application»
o Concept déjà présent
.NET dans d’autres techniques : EAI, middleware, ... J2EE Legacy

o Fédérer différentes applications et systèmes d’informations de l’entreprise - > architectures SOA

«connecteur» «connecteur» «connecteur»

SOAP / HTTP JMS / JCA MQ Gateway

Enterprise Service Bus

ORCHESTRATION

«connecteur» «connecteur» Moteur de

SOAP / HTTP requêtes
SOAP / HTTP
distribué

Caractéristiques d’une
«service»orchestration «webservice» «base de données»
Partenaire Fournisseur SGBD
o Service Web de haut niveau résultant de l’assemblage d’autres Services Web

o Implémentation centralisée d’un processus métier appartenant à une seule organisation

o Décrite avec Business Process Execution Language (WS-BPEL)

(c)Leuville Objects 25-627

L’orchestration des Services Web

Notes

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-628
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

Historique BPEL

BPEL4WS 1.0 - juillet 2002

o Travail conjoint de IBM, Microsoft, BEA

o Langage inspiré de

o IBM Web Services Flow Language (WSFL)

o Microsoft XLANG

Soumission à l’OASIS

BPEL4WS 1.1 - mai 2003

o Contributions SAP et Siebel Systems

o Apparition d’offres commerciales plus conséquentes

WS-BPEL 2.0

o Version officielle OASIS

(c)Leuville Objects 25-629

Historique BPEL

Notes

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-630
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

WS-BPEL

Conçu pour modéliser des workflows

o langage de définition de processus métier et de workflows basé sur XML

o permet d’écrire des programmes qui sont des services web, et qui consomment des services web

o gère des états

Eléments principaux

o <process> : élément racine d’une définition WS-BPEL d’un processus métier, contient les éléments suivants

o <partnerLink> : permet de décrire les échanges entre deux partenaires = deux services web

o <variables> : permet de définir des moyens de stocker des informations d’état relatives à la logique métier

o <sequence> : permet de définir une série d’activités à exécuter

o <invoke> : invoque un service

o <receive> et <reply>

o <switch> <case> <otherwise>

o <assign>

o <copy> <from> <to>

(c)Leuville Objects 25-631

WS-BPEL

Notes

WS-BPEL définit un langage de programmation orienté workflow entre services web.

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-632
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

<process>

Elément racine BPEL = le processus métier

<process name="TimesheetSubmissionProcess"
targetNamespace="http://www.chezmoi.fr/process/imputation/"
xmlns="http://shemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:bpl="http://www.chezmoi.fr/process/imputation/"
xmlns:emp="http://www.chezmoi.fr/process/employe/"
...
xmlns:inv="http://www.chezmoi.fr/process/facturation/">

<partnerLinks>
</partnerLinks>

<variables
</variables>

<sequences>
</sequences>

</process>

o <partnerLinks> : décrit les web services participants à l’orchestration

o <variables> : permettent de stocker des informations relatives aux traitements exécutés au sein du processus

o <sequences> : ensemble d’activités constituant le processus

(c)Leuville Objects 25-633

<process>

Notes

Un processus BPEL est un web service.

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-634
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

<partnerLinks>

o Permet de décrire toutes les relations entre le processus BPEL et les services participants

o Les services participants peuvent avoir deux rôles

o client du processus BPEL

o fournisseur du processus BPEL

<partnerLink

o myRole est utilisé pour indiquer que le service décrit est client du processus BPEL

o partnerRole est utilisé lorsque le service décrit est appelé par le processus BPEL

<partnerLinks>

<partnerLink name="client" partnerLinkType="tns:TimesheetSubmissionType"

myRole="TimesheetSubmissionServiceProvider" />
<partnerLink name="Invoice" partnerLinkType="inv:InvoiceType"
partnerRole="InvoiceServiceProvider" />
<partnerLink name="Timesheet" partnerLinkType="tst:TimesheetType"
partnerRole="TimesheetServiceProvider" />
<partnerLink name="Employee" partnerLinkType="emp:EmployeeType"
partnerRole="EmployeeServiceProvider" />
<partnerLink name="Notification" partnerLinkType="not:NotificationType"
partnerRole="NotificationServiceProvider" />

</partnerLinks>

(c)Leuville Objects 25-635

<partnerLinks>

Notes

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-636
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

<partnerLinkType>

Définitions déportées au niveau des web services participants

o Incluses dans la description WSDL du service participant

o Lien entre le partnerRole et un portType WSDL

<definitions name="Employee"
targetNamespace="http://www.chezmoi.fr/tls/employee/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
...
<plnk:partnerLinkType name="EmployeeType"
xmlns="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
<plnk:role name="EmployeeServiceProvider">
<portType name="emp:EmployeeInterface"/>
</plnk:role>
</plnk:partnerLinkType>
...
</definitions>

(c)Leuville Objects 25-637

<partnerLinkType>

Notes

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-638
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

<variables>

Permettent de stocker des états associés à l’exécution du processus

o Trois types possibles

o messageType : permet de contenir un message complet, défini dans le WSDL

o element : référence à un elément XSD

o type : type simple XSD (simpleType)

<variables>
...
<variable name="ClientSubmission" messageType="bpl:receiveSubmitMessage"/>
<variable name="EmployeeHoursRequest" messageType="emp:getWeeklyHoursRequestMessage"/>
...
</variables>

messageType

o une variable définie pour chaque message en entrée et en sortie

o la valeur de l’attribut = nom du message au sein de la définition du service partenaire

(c)Leuville Objects 25-639

<variables>

Notes

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-640
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

<variables>

Fonctions associées

o Permettent d’accéder à des informations référencées par des variables

o getVariableProperty

o getVariableData

getVariableData (’InvoiceHoursResponse’, ’ResponseParameter’)

getVariableData (’imput’, ’payload’, ’/tns:TimesheetType/Hours/...’)

(c)Leuville Objects 25-641

<variables>

Notes

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-642
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

<sequences>

<sequence>

o Permet de définir un ensemble d’activités à exécuter séquentiellement

o Possibilités <sequence>
o receive : permet de définir les modalités de réception <receive> </receive>
d’informations envoyées par un service client
<assign> </assign>
o assign : affectation de variable
<invoke> </invoke>
o invoke : appel d’un service participant
<reply> </reply>
o reply : permet de définir le contenu d’une réponse à fournir à un
</sequence>
service appelant

o <switch> <case> <otherwise> : pour contrôler le flot d’exécution

o <faultHandlers> : pour déclarer des gestionnaires d’erreurs

(c)Leuville Objects 25-643

<sequences>

Notes

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-644
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

<assign>

<variables>
<!-- input of this process -->
<variable name="input"
messageType="tns:initiateLoanFlowSoapRequest"/>
<variable name="crInput"
messageType="crs:processCreditRatingServiceSoapRequest"/>
...
</variables

<assign>
<copy>
<from variable="input" part="parameters" query="//SSN"/>
<to variable="crInput" part="parameters"
query="/processCreditRatingService/ssn"/>
</copy>
</assign>

(c)Leuville Objects 25-645

<assign>

Notes

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-646
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

<invoke>

<invoke name="invokeCR"
partnerLink="creditRatingService"
portType="crs:CreditRatingService"
operation="process"
inputVariable="crInput"
outputVariable="crOutput"/>

<assign>
<copy>
<from variable="crOutput" part="parameters" query="//result"/>
<to variable="input" part="parameters"
query="/initiateLoanFlow/xmlLoanApp/CreditRating"/>
</copy>
</assign>

(c)Leuville Objects 25-647

<invoke>

Notes

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-648
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

<receive>

<sequence>

<!-- initiate the remote service -->

<invoke name="invokeUnitedLoan"
partnerLink="UnitedLoanService"
portType="tls:LoanService"
operation="initiate"
inputVariable="loanApplication"/>

<!-- receive the result of the remote service -->

<receive name="receive_invokeUnitedLoan"
partnerLink="UnitedLoanService"
portType="tls:LoanServiceCallback"
operation="onResult"
variable="loanOffer1"/>

</sequence>

(c)Leuville Objects 25-649

<receive>

Notes

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-650
 Architectures Orientées Services - WS-BPEL / Business Process Execution Language Version 5.1

<switch>

<switch>
<!-- comparaison de deux offres -->
<case condition="bpws:getVariableData('loanOffer1','parameters','result/APR') >
bpws:getVariableData('loanOffer2','parameters','result/APR') ">

<assign>
<copy>
<from variable="loanOffer2" part="parameters" query="result"/>
<to variable="selectedLoanOffer" part="parameters"
query="/onLoanFlowResult/result"/>
</copy>
</assign>

</case>

<!-- sinon -->

<otherwise>

<assign>
<copy>
<from variable="loanOffer1" part="parameters" query="result"/>
<to variable="selectedLoanOffer" part="parameters"
query="/onLoanFlowResult/result"/>
</copy>
</assign>

</otherwise>

</switch>

(c)Leuville Objects 25-651

<switch>

Notes

A noter qu’une proposition liée à BPEL 2.0 suggère de remplacer <switch> <case> <otherwise> par <if>
<then> <elseif>.

(c) Leuville Objects Architectures Orientées Services - WS-BPEL / Business Process Execution Language 25-652