Architectures orientées services Web services Serveurs d’application Intégration métier EAI, SOA, Cloud computing, B2B

Web services Objectifs Architecture Web services Protocole SOAP Architecture REST Composition de Web services

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.

Exemple : gestion de magasin en ligne Authentification (MTS) Fournisseur (J2EE) SOAP SOAP SOAP Serveur d’application Banque (MVS/CICS) SOAP SOAP SOAP Paiement CB (.NET) Livreur (CORBA)

Standards techniques Web services Publication des fonctionnalités WSDL Accessibles par des requêtes sécurisées HTTPS, SSL Web services Décrits dans des annuaires UDDI Gérés par des serveurs de données XML Utilisables par toute application SOAP

2. Architecture des Web services Registry Find Publish Publish Client Service Requester Service Provider Request Request Service Provider

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) Port Binding (e.g. SOAP) Binding Abstract interface portType operation(s) inMessage outMessage

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>

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>

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)

Contenu de l’annuaire Pages blanches (BusinessEntity) BusinessKey Name Description CategoryBag BusinessServices Pages jaunes (BusinessService) ServiceKey BindingTemplates Pages vertes (BindingTemplates) BindinKey AccessPoint Contenu défini par un schéma XML Spécifications pour réplication Business Entity tModel Spécifs de services et taxonomies Business Service PublisherAssertion Relations entre deux parties Binding Templates Infos techniques

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

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

Message SOAP Protocol Header En-tête de protocole (obligatoire): nom du message et namespace pour sa version de schéma SOAP Envelope SOAP Header (optionnel): extensions de protocole Pour l’authentification, le contexte Transactionnel, etc. SOAP Body XML content (obligatoire): opération et paramètres Attachments

Exemple www.stockquoteserver.com float GetLastTradePrice (Symbol) Le dialogue : Application Application Request Middleware Middleware Reply SOAP SOAP HTTP HTTP Error www.stockquoteserver.com

La requête POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8"  Content-Length: nnnn SOAPAction: "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

La réponse HTTP/1.1 200 OK Content-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

Interopérabilité avec SOAP Application server SOAP Processor SOAP Processor Application server API API Requête Java VB C Perl etc. Java VB C Perl etc. XML Parser XML Parser HTTP HTTP TCP/IP A component (e.g. EJB) A component (e.g. COM) Réponse Construction du message SOAP (par ex. en Java) Conversion du message SOAP et appel du composant (par ex, en VB)

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 : WS 1 Dispatcheur Appel (URL-L, SOAP) Centralisé et lourd: interprétation des URL-L, traitement SOAP WS 2 WS 3 Appel URL1 WS 1 Appel URL2 Messages courts et directs WS 2 Appel URL3 WS 3

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

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)

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

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)

REST versus SOAP REST SOAP 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

5. Composition de services Début Réserver Avion Louer Voiture Train Hotel OK ? Echec Succès oui non 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

Exemple : Pilotage Fabrication Echange B2B Partenaire Serveur d'entreprise Usine XML XML XML WEB XML Interface XML ERP XML Fournisseur Mainframe Client

Les briques à standardiser Choreography - CDL4WS Business Processes Orchestration - BPEL4WS Transactions Quality of Service WS-Reliability WS-Security Coordination Context Management UDDI Discovery WSDL Description Description SOAP Message XML HTTP, IIOP, JMS, SMTP Transport

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

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

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 contrôle définissent le flux d'exécution Les activités correspondent à des services Web [ WS] Les liens de données définissent le flux d'information Les activités peuvent être d'autres processus métiers

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 reserverVacances Commande/classe=1 Commande/classe=2 reserverVoiture reserverAvion reserverHotel demandePaiement

BPEL: Processus composé d'activités Compositions des web services Langage de programmation parallèle codé en XML Assignation de variables locales et globales

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>

Qualité de services Nécessité de fiabiliser Nécessité de sécuriser 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 Architecture Le standard J2EE Etude de cas: EDF GDF .NET de Microsoft

1. Architecture avec SA Présentation Application Données … … Appareil mobile Serveur WAP SGBD Serveur Web Browser Web Serveur Web Serveur d’application Application ERP Client Java Parefeu Client VB/C++ Application mainframe … …

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)

Equilibrage de charge et disponibilité En cas de panne de A, basculement automatique sur B Cookie A,B Serveur A primaire Réplication de l’état des processus clients Serveur B Secondaire Cluster

Le problème d’accès aux données Où mettre la logique applicative ? Composants métiers Procédures stockées Serveur d’application Serveur de 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

Accès BD en C/S 2 tiers Développement d’applications BD en 2 étapes conception de la BD création des tables et des contraintes d’intégrité programmation des procédures stockées Trè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

Composants avec accès BD Gestionnaire de commandes Similaire au C/S + efficace - composants non autonomes Commande Produit Select C.a, P.b, … From C, P Where …

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 de commandes Commande Produit

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

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

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

Architecture d’un serveur J2EE Logique de présentation Logique métier Container Web Container EJB Java Server Page HTML/XML Session Bean Entity Bean Java Bean Servlet Support Comm. TCP/IP, HTTP, RMI, IIOP, SOAP, etc. Services de base JDBC, JTS, JNDI, JMS, JDO, JAX, etc.

Principaux serveurs J2EE Editeur Produit Points forts Ordre de prix BEA-Oracle WebLogic Transactionnel, outils 10K€ IBM Websphere Transactionnel, intégration avec DB2 UDB Oracle AS Intégré dans l’offre Oracle HP Total-e-server Intégré avec les middlewares HP Borland AppServer Basé sur Visibroker, outils Sun GlassFish Logiciel libre (dernier né) Gratuit Redhat Jboss Logiciel libre Apache Jeronimo Objectweb Jonas

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

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

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

Solution Architecture n-tiers Résultats obtenus 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

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

Versant enJin Serveur d’application Serveur d’application Bean Bean Commande Bean Produit Bean Commande Bean Produit Cache partagé transactions transactions SGBDO Versant Mapping O/R automatique Tiers backend Bases de données

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.

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

Architecture de MTS Internet Information MTS Server (IIS) ADO SQLServer ADO Executive threads wrapper context HTML XML HTTP Oracle Active Server Page (ASP) factory trans. cache DCOM Autres Windows

Modèle de composants MTS 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

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 If (OK) ctxObject.SetComplete () // validation de la transaction Else ctxObject.SetAbort () // annulation de la transaction

Common Language Runtime (CLR) Le framework .NET VB, C++, C#, Jscript, Java,etc. Outils SOAP et XML Visual Studio .NET ASP.NET Docs HTML XML BCL.NET Base class library ADO.NET Active Data Objects Common Language Runtime (CLR) Windows et COM/MTS

Serveur J2EE versus .NET Serveur J2EE .NET 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

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