Architectures orientées services
description
Transcript of Architectures orientées services
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