Architectures orientées services

• Web services• Serveurs d’application• Intégration métier

• EAI, SOA, Cloud computing, B2B

Web services

1. Objectifs2. Architecture Web services3. Protocole SOAP4. Architecture REST5. Composition de Web services

3

1. Objectifs des Web services

• Faciliter la construction et la maintenance d’applications distribuées sur le Web avec• échange de données indépendant du stockage :

XML• appel de programmes indépendant du langage:

SOAP• Service web = module applicatif exposé sur

le Web• adresse URI• interface bien définie• implémentée avec des standards Web

• HTTP, XML, SOAP, UDDI, WSDL, etc.

4

Exemple : gestion de magasin en ligne

Serveurd’application

Fournisseur(J2EE)

Banque(MVS/CICS)

Paiement CB(.NET)

Livreur(CORBA)

Authentification(MTS)

SOAP

SOAPSOAPSOAP

SOAPSOAP

5

Standards techniques

Web services

Publicationdes fonctionnalités

WSDL

Décrits dansdes annuaires

UDDI

Publicationdes fonctionnalités

WSDL

Accessibles par desrequêtes sécurisées

HTTPS, SSL

Gérés par desserveurs de données

XML

Utilisables par touteapplication

SOAP

6

2. Architecture des Web services

Client

ServiceRequester

ServiceProvider

ServiceRegistry

ServiceProvider

Publish

PublishFind

Request

Request

7

Description des services: WSDL

• Formats des opérations en XML• Messages d’appel et de retour• Types des paramètres

• Ports d’accès à des groupes d’opérations• Association opérations -

messages• Liaisons (bindings) pour

accéder aux ports avec un protocole spécifique (HTTP, SMTP, MIME, …)

• Adresses URLs de ces ports pour recevoir les opérations

Service

Port(e.g. http://host/svc)

Binding(e.g. SOAP)

Abstract interface

portType

operation(s)inMessage outMessage

Port

Binding

8

Description en WSDL

<definitions name = "..." xmlns: …>   <types>

<!--Définition des types de données; basés sur ceux des schémas --> … </types> 

<message><!--Déclaration des messages (entrées et sorties)--> …

</message> <portType>

<!--Déclaration des opérations (par association des messages)--> … </portType>

<binding> <!--Définition de la liaison WSDL – SOAP (noms d'actions et

codages)--> </binding> <service name= " … " >

<!--Déclaration des ports (groupes d'opérations et protocoles d'accès)-->… </service>

</definitions>

9

Exemple: GetLastTradePrice<?xml version="1.0"?> <definitions name="StockQuote"><types> <schema> <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> </types>

<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>

<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>

</definitions>

10

Annuaire des services : UDDI• Universal Description, Discovery

Integration• Annuaire UDDI

• Décrit par un document WSDL ou autre• Accessible en SOAP• Contenu décrit par un schéma XML

• Fonctions• Enregistrement (publish)

• une société, des services, des opérations• Découverte (find)• Liaison à une service (bind)

11

Contenu de l’annuaire• Pages blanches (BusinessEntity)

• BusinessKey• Name• Description• CategoryBag• BusinessServices

• Pages jaunes (BusinessService)• ServiceKey• BusinessKey• Name• Description• CategoryBag• BindingTemplates

• Pages vertes (BindingTemplates)• BindinKey• ServiceKey• Description• AccessPoint

• Contenu défini par un schéma XML

• Spécifications pour réplication

BusinessEntity

BusinessService

tModelSpécifs de services

et taxonomies

PublisherAssertionRelations entre

deux parties

BindingTemplates

Infos techniques

12

Principaux fournisseurs

• IBM UDDI Registry• Un registre UDDI avec des fonctionnalités de recherche

• Microsoft UDDI Business Registry (UBR)• SAP UDDI Business Registry

• Public pour l'instant• Systinet Registry

• Support complet de UDDI• Oracle Application Server UDDI Registry

13

3. Protocole SOAP

• Simple Object Access Protocol = RPC pour Web services• Standard du W3C par Microsoft et IBM• Pas simple, pas objet!• Basé sur XML RPC de David Winer

(UserLandSoftware)• règles de codage des données en XML• envelope: définit le contenu du message • utilise la requête HTTP POST du client au

serveur• Objectifs

• Passer facilement au travers des firewalls (port 80)

• Portable, faciliter l'accès aux Web services

14

Message SOAP

Protocol Header

SOAP Envelope

SOAP Header

SOAP Body

XML content

Attachments

(obligatoire): nom du message etnamespace pour sa version de schéma

(optionnel): extensions de protocolePour l’authentification, le contexteTransactionnel, etc.

(obligatoire): opération et paramètres

En-tête de protocole

15

Exemple

• www.stockquoteserver.com• float GetLastTradePrice (Symbol)

• Le dialogue :

ApplicationMiddleware

SOAPHTTP

ApplicationMiddleware

SOAPHTTP

www.stockquoteserver.com

Request

Reply

Error

16

La requêtePOST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8" Content-Length: nnnnSOAPAction: "Some-URI#GetLastTradePrice« <SOAP:Envelope

xmlns:SOAP="http://schemas.xmlsoap.org/soap">  <SOAP:Body>       <m:GetLastTradePrice xmlns:m="Some-URI">           <symbol>DIS</symbol>       </m:GetLastTradePrice>   </SOAP:Body>

</SOAP:Envelope>

Standard HTTP

17

La réponse

HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8" Content-Length: nnnn

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap"/><SOAP:Body>    <m:GetLastTradePriceResponse xmlns:m="Some-URI">           <Price>34.5</Price>     </m:GetLastTradePriceResponse> </SOAP:Body>

</SOAP:Envelope>

Standard HTTP

18

Interopérabilité avec SOAP

XMLParser HTTP

JavaVBC

Perletc.

A component(e.g. EJB)

XMLParserHTTP

SOAPProcessorAPIApplication

serverSOAP

Processor

JavaVBC

Perletc.

API

A component(e.g. COM)

Applicationserver

TCP/IP

Construction du messageSOAP (par ex. en Java)

Conversion du messageSOAP et appel ducomposant (par ex, en VB)

Requête

Réponse

19

4. REST: REpresentational State Transfer

Objectif: style d’architecture légère pour développer des applications Web, alternative à SOAP

• Il faut éviter :

• Et remplacer par :

DispatcheurAppel

(URL-L, SOAP)

WS 1

WS 2

WS 3

WS 1

WS 2

WS 3

AppelURL1AppelURL2AppelURL3

Centralisé et lourd: interprétationdes URL-L, traitement SOAP

Messages courts et directs

20

REST: les trois piliers• Ressource

• Toute entité est une ressource : site Web, page XHTML, document XML, Web service, etc.

• URL• Toute ressource est identifiée de manière

unique par une URL logique• Opération simple

• Méthode de recherche, mise à jour, consultation, … directement adressée à la ressource avec un nombre limité de paramètres• Ne pas faire:

http://www.depot.com/parts:getpart?id=1• Faire: http://www.depot.com/parts/1

21

REST: concepts (1)

• Une syntaxe universelle pour adresser les ressources: URI logique comme API• noms sans paramètres

• Un protocole sans état: HTTP• client et requêtes gardent l’état

• Des échanges d’ hyperliens dans des documents XML• pour représenter les contenus et les transitions d’états

• Des types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg pour la représentation des données

• Sécurité par filtres lors du mapping URL ressource physique (ex. une page HTML statique)

22

REST: concepts (2) • Une application est un réseau dont les nœuds

sont des machines virtuelles (pages Web ou services Web)

• Le client invoque des URL et reçoit en réponse des URL

• Il change d’état ("transfers state") en choisissant un lien parmi ceux reçus en réponse

• Le Web est REST

23

REST: principes de conception• Identifier toutes les entités qui doivent être

exposées comme des services: liste de produits, produits, etc.

• Créer un URL par ressource, en utilisant des noms, pas des verbes (pas “getPart”)

• Diviser les ressources selon le mode:• Lecture: accessible uniquement par GET

• Sans effet de bord (pas de modif. de la resource)• Mise à jour: accessible par POST, PUT et/ou DELETE

• Utiliser les hyperliens pour obtenir plus de détails à l’intérieur d’une ressource• Ex: naviguer dans la liste de produits

• Spécifier le format des réponses avec un schéma (DTD, XML Schema) et les services (WSDL ou HTML)

24

REST versus SOAP

• REST• Echanges centrés

sur des URL courtes entre ressources• Échanges limités

• Simplifie le code client et serveur

• Pas de support pour transactions ou sécurité

• Pour des applications simples

• SOAP• Véritable RPC pour

Web services• Échanges complexes

• Génération de code client avec WSDL

• Provision pour transactions et sécurité

• Pour des applications plus sophistiquées

25

5. Composition de services• Objectifs

• Modéliser des processus métiers (business process)

• Composer des services Web distribués

• Piloter l'exécution• Orchestration d'activités• Echanges XML• Gestion de transactions

• Business Process Management

• Transaction• Workflow

Début

RéserverAvion

LouerVoiture

RéserverTrain

RéserverHotel

OK ?

OK ?

OK ?

OK ?

Echec

Echec

Echec

Succès

oui

oui

oui

oui

non

non

non

non

26

Exemple : Pilotage Fabrication

Fournisseur

ERP

Usine

Partenaire

Echange B2B

Mainframe

Serveur d'entreprise

InterfaceXML

XML

XML

XML

XML

XML

Client

WEB

27

Les briques à standardiser

Description

HTTP, IIOP, JMS, SMTP Transport

XMLMessage

SOAP

WSDL

UDDI Discovery

Transactions

CoordinationWS-SecurityWS-Reliability Quality ofService

Orchestration - BPEL4WS

BusinessProcesses

Context

Description

Man

agem

ent

Choreography - CDL4WS

28

Composition de services

• Objectifs• Alliances entre companies pour offrir des

services intégrés à valeur ajoutée en combinant des services existants

• Réutilisation et extension de services existants • Support pour la planification, la définition et

l'implémentation de services composés• Développement d'applications distribuées

composées de services web

29

Quelques définitions

• Processus métier (business process)• Module fonctionnel réalisé par enchaînement

d'activités business exécutées par des acteurs échangeant des messages et implémentant les objets et règles spécifiques à une entreprise.

• Orchestration d'activité• Mécanisme d'invocation, de contrôle et de

coordination des activités participant à la réalisation de processus d'affaire.

• Composition de services• Techniques permettant d'assembler des

services Web pour réaliser des processus métiers par des primitives de contrôles (boucles, tests, traitement d'exception, etc.) et d'échanges (envoi et réception de messages).

30

Modélisation par Workflow

• Graphe d'activités modélisant un processus métier

Les activités représentent les unités de traitement

Les liens de données définissent le flux d'information

[ WS]

Les activités peuvent être d'autres processus métiers

Les liens de contrôle définissent le flux d'exécution

Les activités correspondent à des services Web

31

Exemple

• Modélisation en XML• Langage d'orchestration • Chorégraphie d'activités

<activity name="demandePaiement"><join condition=”(reserverVoiture OR reserverAvion) AND

reserverHotel” when=”deferred”></activity><activity name="reserverAvion">

….

commandeVacances

reserverHotelreserverVoiture reserverAvion

demandePaiement

Commande/classe=1Commande/classe=2

reserverVacances

32

BPEL: Processus composé d'activités• Compositions des web services • Langage de programmation parallèle codé en

XML• Assignation de variables locales et globales

33

Exemple BPEL

<sequence> <receive partnerLink=“customer” portType=“lns:purchaseOrderPT" operation=“sendPurchaseOrder” variable=“PO” createInstance="yes" /> <flow> <invoke partnerLink=“inventoryChecker” portType=“lns:inventoryPT” operation="checkINV" inputVariable="inventoryRequest" outputVariable="inventoryResponse" /> <invoke partnerLink="creditChecker" portType=“lns:creditPT" operation="checkCRED" inputVariable="creditRequest" outputVariable="creditResponse" /> </flow> ... <reply partnerLink=“customer” portType=“lns:purchaseOrderPT” operation=“sendPurchaseOrder” variable=“invoice"/>

</sequence>

34

Qualité de services

• Nécessité de fiabiliser• Les messages (WS-Reliability)• Les activités (WS-Transactions)

• Courtes (Atomic Transactions)• Longues (Business Activity)

• Nécessité de sécuriser• Les échanges confidentiels (WS-Security)

Serveurs d’application

1. Architecture2. Le standard J2EE3. Etude de cas: EDF GDF4. .NET de Microsoft

36

1. Architecture avec SA

SGBD

ApplicationERP

BrowserWeb

Appareilmobile

ClientJava

ClientVB/C++

ServeurWeb

ServeurWAP

Parefeu

… Applicationmainframe

Serveurd’application

Présentation Application Données

…

ServeurWeb

37

Serveur d’application

• Serveur d’entreprise avec• support des composants

• standards CORBA, COM, EJB• middleware objet

• support des transactions• standards CORBA, Open Group (XA)

• environnement de développement intégré• composants, transactions

• équilibrage de charge entre serveurs• support de XML et des Web services• interface avec moniteurs transactionnels et MOM

• NB: serveur d’application serveur Web + servlet (ex. Apache+Tomcat)

38

Equilibrage de charge et disponibilité

Serveur A

Cluster

primaire

Serveur BSecondaire

Réplication de l’étatdes processus clients

Cookie A,B

En cas de panne de A,basculement automatiquesur B

39

Le problème d’accès aux données

• Compromis entre performances et flexibilité difficile à obtenir• performances : s’appuyer au maximum sur le

serveur BD => procédures stockées• flexibilité : composants métiers encapsulant

l’accès aux données

Composants métiers Procédures stockées

Où mettre la logique applicative ?

Serveur d’application Serveur de données

40

Accès BD en C/S 2 tiers• Développement d’applications BD en 2

étapes1 conception de la BD

• création des tables et des contraintes d’intégrité

2 programmation des procédures stockéesTrès efficace

• procédures stockées et contraintes d’intégrité exécutées sur le serveur BD

Evolution difficile• la modification d’une définition de données

implique la recompilation des procédures stockées

41

Composants avec accès BD

• Similaire au C/S+ efficace- composants non

autonomes

Gestionnaire decommandes

Commande Produit

Select C.a, P.b, …From C, PWhere …

42

Composants encapsulant leurs données

• Principe d’îlot de données• ensemble de données

entièrement contenu dans un composant métier

• exige une forte localité des données/composant

+ composants autonomes

- performances

Gestionnaire decommandes

Commande Produit

43

Comment améliorer les performances

• Faire des composants métiers à gros grain• encapsulation des données fortement corrélées

• par ex. 5 à 10 définitions de tables relationnelles

• Exploiter les vues relationnelles• pour les données partagées entre plusieurs

composants• Mettre en œuvre un cache de données au

niveau du serveur d’application• transformation objet/relationnel

44

2. Le standard J2EE (Sun et al.)• De nombreuses API

• EJB: modèle de composants serveurs• JNDI: accès aux services d’annuaire DNS, LDAP• RMI: invocation de méthodes Java à distance• JIDL: Java IDL - interface Corba• JSP: Java Server Pages (Java ds pages HTML) • JMS: Java Messaging Service• JTS: Java Transaction Service (basé sur OTS)• JDBC: accès aux BD via SQL• JDO: Java Data Objects• JAX: Java XML• JCA: Java Connector Architecture• ...

45

JAX

• Pour intégrer XML et les services web• JAX-RPC (Java API for XML RPC) pour effectuer

des appels de messages SOAP• JAXM (Java API for XML Messaging) pour

envoyer des documents XML via SOAP• JAXR (Java API for XML Registries) pour accéder

des annuaires de services de type UDDI

46

Support Comm.

TCP/IP, HTTP, RMI,IIOP, SOAP, etc.

Architecture d’un serveur J2EE

EntityBean

Container EJB

SessionBean

Logique de présentation Logique métier

Java ServerPage

Container Web

HTML/XML

ServletJavaBean

Services de base

JDBC, JTS, JNDI,JMS, JDO, JAX, etc.

47

Principaux serveurs J2EEEditeur Produit Points forts Ordre de prix

BEA-Oracle WebLogic Transactionnel, outils 10K€

IBM Websphere Transactionnel, intégration avec DB2 UDB

10K€

Oracle AS Intégré dans l’offre Oracle 10K€

HP Total-e-server

Intégré avec les middlewares HP

10K€

Borland AppServer Basé sur Visibroker, outils 10K€

Sun GlassFish Logiciel libre (dernier né) Gratuit

Redhat Jboss Logiciel libre Gratuit

Apache Jeronimo Logiciel libre Gratuit

Objectweb Jonas Logiciel libre Gratuit

48

WebSphere Application Server

• Support J2EE complet• Support des transactions

• Interopérabilité avec le moniteur TXSeries• Serveur HTTP basé sur Apache• Support des clusters

• partitionnement des applications et équilibrage de charge

• Intégration avec• Studio Application Developer• DB2 pour la gestion de données et le stockage de

XML• Tivoli pour la gestion de réseau• Versant enJin pour les objets persistants

49

WebLogic (BEA-Oracle)• Support J2EE complet• Serveur HTTP intégré

• Plugins pour Apache, IIS, Iplanet• Support des transactions

• interopérabilité avec le moniteur BEA Tuxedo• Support des clusters

• disponibilité et équilibrage de charge• Environnement de développement

• WebLogic Builder pour le développement Java• WebLogic Workshop pour les Web services

• Intégration avec• Nokia WAP server pour les mobiles• TopLink (WebGain) pour le mapping objet-relationnel• Versant enJin pour les objets persistants

50

3. Etude de cas: EDF GDF

• Application de relation client (CRM) : Niveau1• Utilisée par 25000 agents de clientèle répartis

sur 1300 agences• Gestion commerciale, gestion des contacts, outils

marketing, utilitaires (mailings, etc.)• Architecture technique

• C/S (client lourd) avec 2 nouvelles versions par an• SI sur mainframes IBM (un centre par département)

• Plusieurs BD et une partition CICS par centre• Besoins

• Réactivité croissante aux demandes des agents

• Déploiement plus rapide des nouvelles versions

51

Solution

• Architecture n-tiers• Client léger• WebLogic: serveur J2EE sur plusieurs serveurs• Scort: Progiciel d’intégration avec les

applications mainframes avec des composants J2EE sur WebLogic

• Résultats obtenus• Satisfaction des besoins• Niveau1 offre 2 modes d’accès transparents

aux clients:• Accès aux mainframes en récupérant une connexion

pour exécuter des transactions• Smart publishing: navigation en mode publication à la

volée

52

Le problème de la persistance des objets• L’état des objets modifiés par les entity

beans doit être sauvegardé durant l’exécution• Approche classique: BD relationnelle avec

mapping objet-relationnel• en général très inefficace avec des entity

beans CMP (cf étude de SQLi mars 2002)• Solutions

• propriétaire de type TopLink• mapping vers une BD objet, par ex. Versant

enJin• la plus productive et efficace selon SQLi

53

Versant enJin

Serveur d’application Bean

CommandeBean

Produit

Serveur d’application Bean

CommandeBean

Produit

transactions transactions

Tiers backend Bases de données

Mapping O/R automatique

Cache partagé

SGBDO Versant

54

Avantages de Versant enJin

• Persistance des objets Java transparente• simple pour le développeur

• pas besoin de programmer en JDBC ou autre• Cache d’objets partagés entre différents

serveurs• performances et cohérence via le SGBDO

Versant• Mapping objet-relationnel automatique

vers les BD existantes• définition de la fréquence de synchronisation

• online, batch, etc.

55

4. Microsoft .NET• Evolution majeure de la plateforme

Windows• les APIs Windows sont remplacées par des

bibliothèques de classes objet• intégration de C#, Linq• portabilité des applications .NET

• Microsoft Intermediate Language (MSIL) exécuté par CLR

• sécurité renforcée avec vérification de code• intégration avec COM et Microsoft Transaction

Server (MTS)• support direct des services Web, de XML et de

SOAP avec Visual Studio .NET

56

Architecture de MTS

MTS

Active ServerPage (ASP)

Internet InformationServer (IIS)

HTMLXML

Executive• threads• wrapper• context

• factory• trans.• cache

SQLServer

Oracle

Windows

Autres

ADO

HTTP

DCOM

57

Modèle de composants MTS• Composant

• pas d’état (équivalent à EJB session bean)• Container

• executive : entre client et composant serveur• context wrapper

• définition du comportement trans. du composant par le développeur (par positionnement d’attributs avec Explorer)

• context object• appelé automatiquement par MTS pour

coordonner les transactions en 2 phases• Serveur Windows

58

Exemple de code applicatif MTS

Set ctxObject = GetObjectContext ()// accès à l’objet contexte de MTS

{ code applicatif }Set objExemple = ctxObject.CreateInstance ()

// création d’un objet MTS{ code applicatif }If (OK)

ctxObject.SetComplete () // validation de la transactionElse

ctxObject.SetAbort () // annulation de la transaction

59

Le framework .NET

ASP.NETDocs HTML XML

BCL.NETBase class library

ADO.NETActive Data Objects

Common Language Runtime (CLR)

Windows et COM/MTS

VisualStudio.NET

OutilsSOAP

etXML

VB, C++, C#, Jscript, Java,etc.

60

Serveur J2EE versus .NET• Serveur J2EE

• limité à Java• transactions explicites

• généralité• objets avec état: entity beans

• problème de performances des beans CMP• portabilité

• .NET• multi-langage• transactions implicites

• simplicité• objets sans état

• utiliser ADO pour l’accès aux données• propriétaire, intégré dans le monde Windows

61

Conclusion sur les serveurs d’application• Un modèle d’architecture réellement

distribué• cache la complexité du middleware

• Critères de choix d ’un serveur d’application• support des standards

• J2EE, Web services• plate-formes supportées• performances et débit transactionnel• environnement de développement