1 / 61

Architectures orientées services

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.

kosey
Download Presentation

Architectures orientées services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Web services Objectifs Architecture Web services Protocole SOAP Architecture REST 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 Authentification (MTS) Fournisseur (J2EE) SOAP SOAP SOAP Serveur d’application Banque (MVS/CICS) SOAP SOAP SOAP Paiement CB (.NET) Livreur (CORBA)

  5. Standards techniques Publication des fonctionnalités WSDL 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

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

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

  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. 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 Contenu de l’annuaire Business Entity tModel Spécifs de services et taxonomies Business Service PublisherAssertion Relations entre deux parties Binding Templates 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 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

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

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

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

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

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

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

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

  27. Les briques à standardiser Choreography - CDL4WS Orchestration - BPEL4WS BusinessProcesses Transactions Quality ofService Coordination WS-Security WS-Reliability Context Management Discovery UDDI Description Description WSDL SOAP Message XML Transport HTTP, IIOP, JMS, SMTP

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

  31. 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"> …. Exemple commandeVacances reserverVacances Commande/classe=1 Commande/classe=2 reserverVoiture reserverHotel reserverAvion demandePaiement

  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)

  35. Serveurs d’application Architecture Le standard J2EE Etude de cas: EDF GDF .NET de Microsoft

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

  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é Cookie A,B En cas de panne de A, basculement automatique sur B Serveur A primaire Réplication de l’état des processus clients Serveur B Secondaire Cluster

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

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

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

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

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

  47. Principaux serveurs J2EE

  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

More Related