Architectures orientes services Web services Serveurs dapplication Intgration

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

Web services 1. 2. 3. 4. 5. 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. 3

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

Standards techniques 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 5

2. Architecture des Web services Service Registry Publish Client Find Service Requester Publish Request Service Provider 6 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 Service • 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 7 Port Binding (e. g. http: //host/svc) (e. g. SOAP) port. Type operation(s) in. Message out. Message Abstract interface

Description en WSDL <definitions name = ". . . " xmlns: …> <types>  … </types> <message>  … </message> <port. Type>  … </port. Type> <binding>  </binding> <service name= " … " > … </service> </definitions> 8

Exemple: Get. Last. Trade. Price <? xml version="1. 0"? > <definitions name="Stock. Quote"> <types> <schema> <element name="Trade. Price. Request"> <complex. Type> <all> <element name="ticker. Symbol" type="string"/> </all> </complex. Type> </element> <element name="Trade. Price"> <complex. Type> <all> <element name="price" type="float"/> </all> </complex. Type> </element> </schema> </types> <message name="Get. Last. Trade. Price. Input"> <part name="body" element="xsd 1: Trade. Price. Request"/> </message> <message name="Get. Last. Trade. Price. Output"> <part name="body" element="xsd 1: Trade. Price"/> </message> <port. Type name="Stock. Quote. Port. Type"> <operation name="Get. Last. Trade. Price"> <input message="tns: Get. Last. Trade. Price. Input"/> <output message="tns: Get. Last. Trade. Price. Output"/> </operation> </port. Type> <binding name="Stock. Quote. Soap. Binding" type="tns: Stock. Quote. Port. Type"> <soap: binding style="document" transport="http: //schemas. xmlsoap. org/soap/http"/> <operation name="Get. Last. Trade. Price"> <soap: operation soap. Action="http: //example. com/Get. Last. Trade. Price"/> <input> <soap: body use="literal"/> </input> <output> <soap: body use="literal"/> </output> </operation> </binding> <service name="Stock. Quote. Service"> <documentation>My first service</documentation> <port name="Stock. Quote. Port" binding="tns: Stock. Quote. Binding"> <soap: address location="http: //example. com/stockquote"/> </port> </service> </definitions> 9

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

Contenu de l’annuaire • • Business. Key Name Description Category. Bag Business. Services Contenu défini par un schéma XML Spécifications pour réplication Business Entity t. Model Spécifs de services et taxonomies Pages jaunes (Business. Service) • • • Pages blanches (Business. Entity) Service. Key Business. Key Name Description Category. Bag Binding. Templates Business Service Pages vertes (Binding. Templates) • • Bindin. Key Service. Key Description Access. Point Publisher. Assertion Relations entre deux parties 11 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 12

3. Protocole SOAP • Simple Object Access Protocol = RPC pour Web services • Standard du W 3 C par Microsoft et IBM • Pas simple, pas objet! • Basé sur XML RPC de David Winer (User. Land. Software) • 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 13

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

Exemple • www. stockquoteserver. com • float Get. Last. Trade. Price (Symbol) • Le dialogue : Application Middleware SOAP HTTP Request Reply Error Application Middleware SOAP HTTP www. stockquoteserver. com 15

La requête POST /Stock. Quote HTTP/1. 1 Host: www. stockquoteserver. com Standard HTTP Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI#Get. Last. Trade. Price « <SOAP: Envelope xmlns: SOAP="http: //schemas. xmlsoap. org/soap"> <SOAP: Body> <m: Get. Last. Trade. Price xmlns: m="Some-URI"> <symbol>DIS</symbol> </m: Get. Last. Trade. Price> </SOAP: Body> </SOAP: Envelope> 16

La réponse HTTP/1. 1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn Standard HTTP <SOAP: Envelope xmlns: SOAP="http: //schemas. xmlsoap. org/soap"/> <SOAP: Body> <m: Get. Last. Trade. Price. Response xmlns: m="Some-URI"> <Price>34. 5</Price> </m: Get. Last. Trade. Price. Response> </SOAP: Body> </SOAP: Envelope> 17

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

4. REST: REpresentational State Transfer Objectif: style d’architecture légère pour développer des applications Web, alternative à SOAP • Il faut éviter : WS 1 Appel (URL-L, SOAP) WS 2 Dispatcheur WS 3 • Et remplacer par : Appel URL 1 Appel URL 2 Appel URL 3 Centralisé et lourd: interprétation des URL-L, traitement SOAP WS 1 WS 2 WS 3 19 Messages courts et directs

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 20

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

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 22

REST: principes de conception • Identifier toutes les entités qui doivent être exposées comme des services: liste de produits, etc. • Créer un URL par ressource, en utilisant des noms, pas des verbes (pas “get. Part”) • 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) 23

REST versus SOAP • REST • SOAP • Echanges centrés sur des URL courtes entre ressources • Véritable RPC pour Web services • Échanges complexes • Échanges limités • Génération de code client avec WSDL • Provision pour transactions et sécurité • Pour des applications plus sophistiquées • Simplifie le code client et serveur • Pas de support pour transactions ou sécurité • Pour des applications simples 24

5. Composition de services Début • Objectifs • Modéliser des processus métiers (business process) • Composer des services Web distribués • Piloter l'exécution Réserver Hotel non OK ? oui • Orchestration d'activités • Echanges XML • Gestion de transactions Echec Réserver Avion • Business Process Management OK ? • Transaction • Workflow Louer Voiture non Réserver Train oui OK ? oui Succès 25 oui non OK ? Echec non Echec

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

Les briques à standardiser Choreography - CDL 4 WS Orchestration - BPEL 4 WS Business Processes Management Transactions WS-Reliability WS-Security Coordination Quality of Service Context UDDI Discovery WSDL Description SOAP Message XML HTTP, IIOP, JMS, SMTP 27 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 28

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

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

Exemple • Modélisation en XML reserver. Vacances an m m Co • Langage d'orchestration • Chorégraphie d'activités commande. Vacances de Commande/classe=2 la /c e ss =1 <activity reserver. Voiture reserver. Avion name="demande. Paiement"> <join condition=”(reserver. Voiture OR reserver. Avion) AND reserver. Hotel” when=”deferred”> </activity> <activity name="reserver. Avion"> demande. Paiement …. 31 reserver. Hotel

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

Exemple BPEL <sequence> <receive partner. Link=“customer” port. Type=“lns: purchase. Order. PT" operation=“send. Purchase. Order” variable=“PO” create. Instance="yes" /> <flow> <invoke partner. Link=“inventory. Checker” port. Type=“lns: inventory. PT” operation="check. INV" input. Variable="inventory. Request" output. Variable="inventory. Response" /> <invoke partner. Link="credit. Checker" port. Type=“lns: credit. PT" operation="check. CRED" input. Variable="credit. Request" output. Variable="credit. Response" /> </flow>. . . <reply partner. Link=“customer” port. Type=“lns: purchase. Order. PT” operation=“send. Purchase. Order” variable=“invoice"/> </sequence> 33

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

Serveurs d’application 1. 2. 3. 4. Architecture Le standard J 2 EE Etude de cas: EDF GDF. NET de Microsoft

1. Architecture avec SA Présentation Application Appareil mobile Serveur WAP Browser Web Serveur Web Client Java Parefeu Client VB/C++ Données SGBD Serveur Web Serveur d’application … … 36 Application ERP 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) 37

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 38

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 39

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

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

Composants encapsulant leurs données • Principe d’îlot de données Gestionnaire de commandes Commande • ensemble de données entièrement contenu dans un composant métier • exige une forte localité des données/composant + composants autonomes - performances Produit 42

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 43

2. Le standard J 2 EE (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. . . 44

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 45

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

Principaux serveurs J 2 EE Editeur Produit Points forts Ordre de prix BEA-Oracle Web. Logic Transactionnel, outils 10 K€ IBM Websphere 10 K€ Oracle AS Transactionnel, intégration avec DB 2 UDB Intégré dans l’offre Oracle HP Intégré avec les middlewares HP Basé sur Visibroker, outils 10 K€ Borland Total-eserver App. Server Sun Glass. Fish Logiciel libre (dernier né) Gratuit Redhat Jboss Logiciel libre Gratuit Apache Jeronimo Logiciel libre Gratuit Objectweb Jonas Logiciel libre Gratuit 47 10 K€

Web. Sphere Application Server • Support J 2 EE 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 DB 2 pour la gestion de données et le stockage de XML Tivoli pour la gestion de réseau Versant en. Jin pour les objets persistants 48

Web. Logic (BEA-Oracle) • Support J 2 EE 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 • Web. Logic Builder pour le développement Java • Web. Logic Workshop pour les Web services • Intégration avec • Nokia WAP server pour les mobiles • Top. Link (Web. Gain) pour le mapping objet-relationnel • Versant en. Jin pour les objets persistants 49

3. Etude de cas: EDF GDF • Application de relation client (CRM) : Niveau 1 • 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 agents • Déploiement plus rapide des nouvelles versions 50

Solution • Architecture n-tiers • Client léger • Web. Logic: serveur J 2 EE sur plusieurs serveurs • Scort: Progiciel d’intégration avec les applications mainframes avec des composants J 2 EE sur Web. Logic • Résultats obtenus • Satisfaction des besoins • Niveau 1 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 51

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 Top. Link • mapping vers une BD objet, par ex. Versant en. Jin • la plus productive et efficace selon SQLi 52

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

Avantages de Versant en. Jin • 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. 54

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 55

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

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 57

Exemple de code applicatif MTS Set ctx. Object = Get. Object. Context () // accès à l’objet contexte de MTS { code applicatif } Set obj. Exemple = ctx. Object. Create. Instance () // création d’un objet MTS { code applicatif } If (OK) ctx. Object. Set. Complete () // validation de la transaction Else ctx. Object. Set. Abort () // annulation de la transaction 58

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

Serveur J 2 EE versus. NET • Serveur J 2 EE • 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 60

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 • J 2 EE, Web services • plate-formes supportées • performances et débit transactionnel • environnement de développement 61