Workshop e-business ISMIN 3A P2015

Transcription

1 Workshop e-business ISMIN 3A P2015 Philippe Lalevée 1 Votre semaine Durée : 30 heures (10 x 3h) dont ~6 heures de cours Cours : rappels sur les technologies Web, XML, modèles de programmation, architectures réparties, applications d entreprise et : «Web Services» «Service Oriented Architecture» (SOA) «Cloud Computing» Projet: sujet remis lundi ou mardi après-midi Évaluation : démonstrations commentées vendredi après-midi 2 Philippe Lalevée 1

2 Organisation générale Mise en œuvre des technologies Lundi AM: Cours de présentation générale Lundi PM Mise en œuvre des «machines» Deux TP de mise en jambe : Servlet/JSP et Node.js Mise en œuvre d un ERP Mardi AM: Technologies des Web Services (REST, SOA, Cloud) Mardi PM Deux TP de consolidation : Web Services Projet du Mercredi à Vendredi AM : 30 heures de travail Démonstrations : Vendredi PM 13h15-15h30 : passage des 4 groupes 15h30-16h : évaluation de la semaine 3 Bibliographie Web Services Architectures n-tiers et déploiement d applications Web. Caromel et al, INRIA, Construire des Services Web XML avec.net. Short, Microsoft Press, Services Web avec J2EE et.net. Maesano, Bernard, Le Galles, Eyrolles, 2003 Les Web Services. Kadima et Montfort, Dunod, 2003 Web Service Contract Design and Versioning for SOA. Erl et al, Prentice Hall Developing Web Services with Apache CXF and Axis2. Tong, Tiptec RESTful Web Services Cookbook. Allamaraju, O Reilly 2010 SOA SOA: le guide de l architecte. Fournier-Morel et al, Dunod, SOA Governance. Biske, Packtpub SOA Design Patterns. Erl, Prentice Hall Implementing SOA Using JEE. Kumar et al, Addison Wesley SOA Questions. Holley et Arsanjani, Prentice Hall SOA: An Integration Blueprint. Schmutz et al, Packtpub Cloud Cloud Application Architectures. Reese, O Reilly Cloud Computing and SOA Convergence in Your Enterprise. Linthicum, Addison Wesley Implementing and Developing Cloud Computing Applications. Sarna, Auerbach Host Your Web Site in the Cloud. Barr, Sitepoint The Cloud at Your Service. Rosenberg et Mateos, Manning Developing Applications for the Cloud. Betts et al, Microsoft Press Microsoft SQL Azure: Enterprise Application Development. Krishnaswamy, Packtpub Cloud Computing: Principles and Paradigms. Buyya et al, Wiley Code in the Cloud. Chu-Carroll, Pragmatic bookshelf Philippe Lalevée 2

3 Première partie RAPPELS ET INTRODUCTION GÉNÉRALE 5 Qu est-ce que le E-Business? Source IBM 6 Philippe Lalevée 3

4 Rappels et introduction générale RÉSEAUX ET PROTOCOLES 7 Les protocoles de l Internet OSI Model Layers Application Layer Presentation Layer Session Layer Transport Layer Network Layer Data Link Layer Physical Layer TCP/IP Protocol Architectu re Layers Application Layer Host-to-Host Transport Layer Internet Layer Network Interface Layer Telnet FTP SMTP DNS RIP SNMP HTTP ARP Ethernet TCP Token Ring IP TCP/IP Protocol Suite Frame Relay UDP IGM P Web ICM P ATM 8 Philippe Lalevée 4

5 Internet et le World Wide Web Internet/internet, intranet/extranet Basé sur Internet (protocole HTTP/TCP) Conséquences sur les applications Ressources accessibles 24/24 Notions générales de services (clients et serveurs) Pas (ou peu) d installation «côté client» Les informations sont reliées les unes aux autres Information hypertexte de type «chaîne de caractères» Propose une façon générique d accéder et de partager de l information hétérogène Contenus variés : médias (articles techniques, blogs, musique), achats, données brutes applicatives, etc. Accès variés : synchrone/asynchrone, fiable/non fiable, qualité de service/bande passante Est devenu une plate-forme de développement Applications accessibles depuis n importe où Vision fournisseur : applications pour les clients décentralisés Vision client : bibliothèque virtuelle de composants 9 Principes de conception Interopérabilité : les langages et protocoles du Web sont compatibles entre eux et indépendants des matériels et des logiciels Évolutivité : le Web est du coup capable de s adapter à de nouvelles technologies (interfaces simples) Modularité des ressources et des usages Extensibilité pour s adapter à la demande Décentralisation : facilite l extensibilité et la robustesse Pas de «centre» global (pas de contrôle de flux) Tout nœud diffuse et reçoit (symétrie) (conséquence: révolution «technico-sociale») Repose sur une architecture client/serveur 10 Philippe Lalevée 5

6 Les standards du Web Internet Engineering Task Force (IETF) Fondé en 1986 Standards basés sur des RFC (Request For Comments) disponibles sur Par exemple, HTTP : RFC2616 World Wide Web Consortium (W3C) Fondé en 1994 par Tim Berners-Lee Publie des rapports techniques et des recommandations OASIS Standards e-business (ebxml, OpenDoc, UDDI ) 11 Architecture du Web Clients Navigateur (Firefox/IE) Requête : HTTP request Réseau Internet (TCP/IP) Serveur Réponse : HTTP Response <html> </html> Serveur Web (Apache/IIS) 12 Philippe Lalevée 6

7 URI, URL et URN Uniform Resource Identifier (URI = URL ou URN) Est une courte chaîne de caractères identifiant une ressource Web physique ou abstraite, et dont la syntaxe respecte une norme d'internet mise en place pour le «World Wide Web» (voir RFC 3986) Uniform Resource Locator (URL) Est un URI qui fournit les moyens d'agir sur une ressource ou d'obtenir une représentation de la ressource en décrivant son mode d'accès primaire ou "emplacement" réseau (instructions explicites pour désigner la méthode d accès à la ressource sur Internet) Ex : ftp://ftp.lip6.fr/public, mailto:lalevee@emse.fr Uniform Resource Name (URN) Est un URI qui identifie une ressource par son nom dans un espace de noms Exemple : urn:isbn: est un URI qui, avec un ISBN (International Standard Book Number) autorise quelqu'un à faire référence à un livre, mais ne suggère où et comment en obtenir une copie réelle 13 Accès aux ressources Les ressources sont repérées par des URL (Uniform Resource Locator) protocol://id:pw@server:port/resource?param Exemple Syntaxe Protocole: http Identification pour accéder à la ressource : toto:passwd Nom du serveur : Numéro du port (application) : 80 Web page: req (index.html souvent par défaut) Paramètres avec la méthode GET : p=m2 14 Philippe Lalevée 7

8 HTTP Request : GET Méthode Ressource Version HTTP Lignes d entête GET /req?prenom=philippe&nom=lalevee HTTP/1.1 Host: Connection: close User-Agent: Web-sniffer/ (+ Accept-Charset: ISO ,UTF-8;q=0.7,*;q=0.7 Cache-Control: no-cache Accept-Language: de,en;q=0.7,en-us;q=0.3 Referer: Données associées à la ressource pour GET Ligne blanche (2 LF successifs) 15 HTTP Request : POST Méthode Ressource Version HTTP Lignes d entête POST /req HTTP/1.0 Host: Connection: close Referer: Content-type: application/x-www-form-urlencoded Content-length: 0 Connection: Keep-Alive If-Modified-Since: Sunday, 17-Apr-96 04:32:58 GMT prenom=philippe&nom=lalevee... Données POST Ligne blanche de séparation 16 Philippe Lalevée 8

9 Les méthodes HTTP GET Saisie URL ou clic Paramètres placés dans l URL (max ~240 octets) POST Formulaires ou fichiers Paramètres placés après l entête (taille non limitée par le protocole) Autres HEAD : obtention de l entête seule PUT : dépôt d une ressource DELETE : suppression d une ressource OPTIONS : interrogation du serveur TRACE : pour le débogage 17 HTTP Response Version HTTP Status code Raison Lignes d entête HTTP/ OK Date: Mon, 17 Feb :30:00 GMT Server: Apache/ (Red Hat) X-Powered-By: PHP/4.3.9 Content-Length: 1599 Connection: close Content-Type: text/html Données <!DOCTYPE html PUBLIC "-//W3C " " <html xmlns=" <head> <title>site Web de l EMSE</title> </head> Philippe Lalevée 9

10 Le protocole HTTP HTTP est un protocole «sans état» Exemples de la vie courante? Idempotence Le fait d être «sans état» a de grandes conséquences sur la conception des applications et leur extensibilité Connaissez-vous les propriétés ACID? Maintien de la connexion (keep-alive) pour plus d efficacité En HTTP 1.1, mode par défaut (Connection: close pour enlever) 19 Rappels et introduction générale ARCHITECTURES TECHNIQUES 20 Philippe Lalevée 10

11 Terminaux Architecture centralisée Applications monolithiques ENTREPRISE Service Ordinateur Réseau Service Concentrateurs BD BD BD Ordinateurs centraux 21 Programmation «mainframe» Architecture centralisée Ordinateur central (IBM 3090) Bases de données centrales Réseaux de terminaux clients Méthodes «systémiques» Séparation traitement/données : MERISE Langages impératifs : ex. Cobol Systèmes propriétaires Avantages / inconvénients? 22 Philippe Lalevée 11

12 Architecture client/serveur Partage des données Service ENTREPRISE Pare-feu Appli BD Stations de travail Service Internet Serveur Appli Appli Intranet Service BD Stations de travail Stations de travail 23 Programmation «répartie» Architecture décentralisée Chaque nœud est un ordinateur indépendant Bases de données accessibles à tout nœud Réseau local (LAN) ou distant (WAN) d interconnexion Algorithmique répartie (distribuée) Les applications sont multi-machines Les modules applicatifs de chaque machine coopèrent par échange de messages Nouvelles problématiques sécuritaires et transactionnelles Premiers systèmes libres (Unix) RPC, RMI, CORBA, DCOM SQL, HTTP Java EE,.NET Avantages / inconvénients? 24 Philippe Lalevée 12

13 RPC : Remote Procedure Call Mécanisme dissymétrique Le client émet une requête avec un message Le serveur lit et exécute la requête Le client obtient la réponse par un message 25 Appel de procédure appelant appelant Transmission des paramètres fonction Encapsulation des paramètres SEND Récupération des paramètres Appel local Communication synchrone Mode bloquant Contrôle des erreurs Récupération des résultats Client RECV fonction Encapsulation des résultats Serveur 26 Philippe Lalevée 13

14 Java EE RMI Application 1 Application 2 Enterprise Java Bean Enterprise Java Bean Stub (talon) Java RMI Middleware Réseau 27 OMG CORBA Client Serveur Proxy (souche) Serviteur (squelette) ORB ORB POA ORB core (Object Request Broker) BUS MIDDLEWARE 28 Philippe Lalevée 14

15 Architecture des applications Modèle MVC MVC : Model-View-Controller Étudié en 1979 par Xerox (pour smalltalk) Utilisé dans les applications GUI (AWT, Swing) Event-driven Programming Model réalise effectivement les traitements applicatifs sur les données ( Business Process) View obtient les données du «modèle» et les «présente» à l utilisateur ( Human-Machine I{nteraction nterface}) Controller reçoit et traduit les entrées en requêtes vers le «modèle» ou la «vue» ( Business Logic) 29 Architecture MVC Séparation des flux par des interfaces Affichage Vitrine View Arrièreboutique Model Controller Orienteur Côté Application 30 Philippe Lalevée 15

16 Architecture n-tier Découpage des applications en «étages» (tier) tier client tier du milieu (Middleware) tier ressource (S.I.) Côté serveur 31 Rôle du tier client Ici le client peut être de «toute» nature Utilisateur final humain Autres applications Systèmes de stockage IHM : interface graphique (GUI) ou console (CLI) Partie vue du modèle MVC Présentation des données Adaptation au «terminal» Transformations «à la volée» Prise en compte des caractéristiques de sortie (reporting) 32 Philippe Lalevée 16

17 Rôle du middle-tier (middleware) Gestion des composants fournit tous les services et outils pour gérer les composants du système et l implémentation de la «logique métier (business)» Transaction Management Une transaction comprend plusieurs opérations, dont toutes ou aucune doivent être effectuées pour protéger l intégrité des données Assure les propriétés ACID des transactions (atomicité, consistance, isolation et durabilité) Passage à l'échelle (scaling) Capacité du système d'accroître ses ressources matérielles pour supporter un nombre accru de requêtes utilisateur avec un temps de réponse constant 33 Rôle du middle-tier (middleware) Répartition de charge Capacité d envoyer une requête a différents serveurs en fonction de leur disponibilité Gestion aux différents étages, à partir du réseau Tolérance aux fautes, haute disponibilité Règle des 9 : 3 8h45 et 5 5 mn Redondance aux différents étages Sécurité Identification, authentification, autorisation Console de management Gestion centrale de tout le système 34 Philippe Lalevée 17

18 Le tier ressource (S.I.) Système de Gestion de Base de Données (database) JDO, SQL/J, JDBC, ADO.NET Systèmes existants (legacy systems) ERP (Enterprise Resource Planning) EAI (Enterprise Application Integration) Intégration avec : Connecteurs (JCA) : développement Protocoles propriétaires : dépendances 35 Serveur d applications Environnement complet de développement, de test et d exécution coté serveur Il comprend toujours un serveur de composants Serveur avec états Supporte la «logique métier» (Business Logic) décrite à l aide d objets, de règles et de composants Exemples Microsoft Server 2012 Visual Studio Serveurs Java EE : IBM WebSphere, Redhat JBoss, ObjectWeb JONAS, Oracle WebLogic / Glassfish Serveurs CORBA : Micro Focus VisiBroker / ORBacus 36 Philippe Lalevée 18

19 Intégration S.I. aux applications Web Service ENTREPRISE Stations de travail Internet Pare-feu Serveur Web HTML Appli Web Appli Web Appli Web? BD BD Service Stations de travail Ordinateurs centraux 37 Conséquences de l utilisation d Internet sur le S.I. Passage d un réseau propriétaire à un réseau public Nécessité de bâtir des Intranet d entreprise Politique de sécurité interne et non déléguée Prise en compte de cette sécurité dans les applications Sécurité Filtrage réseau : limites Cryptage : partage de clés (PKI) Culture d entreprise : services supports Plate-forme de développement Basée sur des standards et non des technologies Indépendante du type d application Prépondérance des interfaces Accessibilité étendue : progrès? 38 Philippe Lalevée 19

20 Architecture client/serveur Exécution de code en architecture client/serveur Client léger (navigateur) Applications Client lourd Applet ORB Serveur Serveur WEB Côté client Côté serveur 39 Programmation Web côté client Qu est-ce que du code «côté client»? Du logiciel qui est téléchargé d un serveur Web vers un navigateur et qui s exécute sur la machine du «client» Pourquoi du code «côté client»? Meilleure extensibilité : moins de travail pour le serveur Meilleure performance pour gérer l interface Créer des interfaces utilisateur non basées sur HTML (animations, validation des informations) Technologies DHTML, Javascript Composants 40 Philippe Lalevée 20

21 DHTML et JavaScript Encapsuler un script dans une page HTML Généralement écrit en JavaScript (ECMAScript, JScript) pour des raisons de portabilité Internet Explorer supporte aussi VBScript et d autres langages de script Mozilla est extensible par plug-in Chaque élément HTML devient un objet qui peut être associé à des événements (i.e. onclick) Les scripts fournissent du code qui sont exécutés lors de la production d événements de la part du navigateur 41 Les applets Basées sur du bytecode Java Portabilité garantie par les JVM : «Write once, run anywhere» Sûr : le code s exécute dans un «bac à sable» (sandbox) dont les accès sont contrôlés Compatibilité et performance permettent un usage intensif et une large diffusion À noter : le succès de Java est plutôt venu des applications côté serveur 42 Philippe Lalevée 21

22 Programmation Web côté serveur (1) Qu est-ce que du code «côté serveur»? Du logiciel qui s exécute sur le serveur Web et non sur la machine du client Il reçoit ses données en entrée à partir de : Les paramètres des URL Les données des formulaires HTML Les entêtes HTTP, y compris les cookies Il peut accéder à des bases de données côté serveur, des serveurs de mail, des machines de gestion, etc. Il construit dynamiquement une réponse adaptée à chaque requête client 43 Programmation Web côté serveur (2) Accessibilité Tout client peut atteindre Internet de n importe quel navigateur, n importe quelle machine, n importe quand, n importe où Gestion Ne nécessite pas la distribution du code des applications Facilité de changer le code Sécurité Le code source n est pas accessible Une fois le client authentifié, ses actions peuvent être autorisées ou interdites Extensibilité Extension facile avec l architecture «3-tier» 44 Philippe Lalevée 22

23 Browser Web Technologies côté serveur Codes Common Gateway Interface (CGI en C) Internet Server API (ISAPI) Netscape Server API (NSAPI) Scripts (PERL, RUBY, PYTHON ) Active Server Pages (ASP) Personal Home Page (PHP) Coldfusion de Macromedia (CFM) Codes et scripts mêlés Java Server Pages (JSP) ASP.NET 45 Compilation à la volée : JEE Analyse moteur JAVAC Génère Composants 1 ère Requête 2 ème Requête Fichier JSP Tomcat Instancie Classe générée Réponse Réponse Classe de la page Instanciation, traitement, affichage 46 Philippe Lalevée 23

24 Browser Web Compilation à la volée :.NET Analyse moteur ASPX Génère Classe Code Behind 1 ère Requête 2 ème Requête Fichier ASPX IIS Instancie Classe générée Réponse Réponse Classe de la page Instanciation, traitement, affichage 47 Web et MVC Traitement de la présentation (View) sur le client et le serveur (étage «front office») et du contrôle de processus (Controller) et de la partie métier (Model) sur le serveur (étage «back office») Adaptation de la présentation au «client» Données : HTML, WML, XML, PDF Terminal : PC, Tablette, PDA, SP, GSM Réseau Gestion «passive» ou «active» des changements d état Passive : «Adapter pattern» (interruption ou callback) Active : «Observer pattern» (scrutation) 48 Philippe Lalevée 24

25 Architecture n-tier : application au Web Le côté serveur Clients web Web services HTML, XML / HTTP, HTTPS SOAP / HTTPS Web Serveur Web Container Scripts (Fast CGI) Autres extensions SQL, propriétaire XML, RMI / HTTP, IIOP, JRMP, JMS Le tier ressource (EIS) Le tier du milieu Le tier client Contenu statique CGI scripts Le tier web SOAP / HTTPS Web Services Front Office Back Office 49 Enchaînements n-tier Le tier client Client Web SOAP / HTTPS tier web SOAP / HTTPS Web Services SOAP / HTTPS tier web SOAP / HTTPS tier web SOAP / HTTPS Web Services SOAP / HTTPS tier web 50 Philippe Lalevée 25

26 Bilan des architectures La solution doit intégrer les architectures existantes Mainframe : institutions Réseaux locaux d applications Client-serveur WEB Nouvelles solutions Réseaux de serveurs applicatifs (enchainements n-tier) Architectures orientées composants Politiques d intégration et de sécurité Évolutions EAI, SOA et Cloud computing 51 Bilan des technologies HTML (ou XHTML) : langage à balises hypertexte CSS (Cascading Style Sheet) : présentation des documents Javascript : code côté client XML (extended Markup Language) : description des données RSS (ou ATOM) : syndication des flux HTTP : protocole de transport des messages URI : identifiants universels XML-RPC (Remote Procedure Call) : invocation synchrone REST (Representational State Transfer) : accès aux ressources WS-* (Web Services) : invocation de services AJAX (Asynchronous Javascript and XML) : requêtes JSON sur HTTP en mode asynchrone en Javascript Technologies Applicatives Web 52 Philippe Lalevée 26

27 Rappels et introduction générale PUB! 53 Pub! Architecture.NET.NET est une stratégie de produits Microsoft Remplacement de Microsoft DNA 54 Philippe Lalevée 27

28 Pub! Architecture JEE JEE est un standard industriel contrairement à.net c est une spécification Actuellement, version 1.4 Une application JEE assemble des composants Web : servlets et JSP business : EJB écrits en Java, compilés en bytecode applications clientes, applets assemblés dans l application déployés dans un serveur Le serveur JEE fournit des conteneurs qui permettent de simplifier les composants et d offrir tous les services nécessaires 55 Pub! Modèles de développement Un langage Plusieurs plate-formes Plusieurs langages Une plate-forme Source : 56 Philippe Lalevée 28

29 Tableau comparatif JEE/.NET Langage Services Microsoft. NET C#, Multi- Langage BCL Présentation ASP.NET J2EE Java Java core API Servlet JSP Interprète CLR JVM GUI composants Win Forms Web Forms Swing différences essentielles C# a certains des JavaBeans et ajoute les metadata tags. L'intégration dans la syntaxe est différente. J2EE est plate-forme indépendant mais langage spécifique,.net est langage indépendant mais plate-forme spécifique. Similaire services ASP.NET utilise tout les langages supportes dans.net et est compile en code natif par le CLR. JSPs utilisent Java code (snippets, ou JavaBean références), compile en bytecodes. CLR permet a du code de plusieurs langages d'utiliser un ensemble de composants partages. Composants Web similaire ne sont pas disponible en Java. WinForms et WebForms sont complètement intègre a VisualStudio.net DB accès ADO.NET JDBC, JDO, ADO.NET est construit a partir d'une architecture XML SQL/J WebServices oui oui.net web services supposent un model de message base sur SOAP tandis que J2EE laisse le choix au developpeur. Implicit middleware oui oui Technologie Produit Standard J2EE est une specification,.net est une strategie de produits 57 Rappels et introduction générale XML 58 Philippe Lalevée 29

30 Représentation des données Brute («raw») Flux d octets (bits) Efficace mais sensible à son usage Textuelle Adoption d un jeu de caractères Conversions implicites (endianness, formats) Relationnelle Inspirée des MLD (Merise) Utilisation dans les bases de données relationnelles Arborescente Inspirée des «enregistrements» COBOL Représentation unique (non ambigüe) 59 Présentation rapide de XML Sous-ensemble de SGML Alors que HTML est une implémentation de SGML Métalangage avec balises (Markup) Fichier texte Conçu pour une représentation structurée de l information Sous forme hiérarchique (arborescente) Fournit un «contexte» aux données (signifiantes) Informations auto-descriptives Séparation de la présentation (HTML) des données (XML) Pas de sémantique associée Standard ouvert du W3C 60 Philippe Lalevée 30

31 Utilisation de XML Spécification de données «utilisable partout» Application A Application B XML Application C BD XML Intérêt applicatif : Validation XML et Définition Respect de la grammaire XML Respect de la définition de la structure 61 Description DTD : Document Type Definition Définition simple (et rapide) Obsolète aujourd hui Schéma Définition XML de la structure Typage fort des données Réutilisation possible 62 Philippe Lalevée 31

32 Manipulation Traitement séquentiel et événementiel De type «SaX» Les éléments sont lus «ligne à ligne» Chaque ligne déclenche un événement activable Traitement de l arbre De type «DOM» Le fichier (instance) est lu complètement en mémoire sous la forme d un arbre Cet arbre est vu comme une arborescence objet 63 Transformations Traitement de sortie Application de feuilles de styles : XSLT Sérialisation des données XSL : extensible Stylesheet Language XSL Transformations : XML Langage XSL-FO (formatting objects) mise en page Transformations PS, PDF, HTML, WML, ASCII et XML 64 Philippe Lalevée 32

33 XML et RPC/RMI RPC/RMI dans lequel : Le protocole de communication est HTTP L encodage des données est XML SOAP (Simple Object Access Protocol) Version proposée par Microsoft Reprise par les éditeurs de logiciels 65 Rappels et introduction générale URBANISATION ET INTÉGRATION 66 Philippe Lalevée 33

34 Scénarios n-tier L architecture n-tier permet plusieurs modèles d exécution des applications Applications Web (classiques) Applications B2C Applications Intranet Applications B2B Applications multi-tier Inspirés de Java EE, mais valables aussi en.net 67 Applications Web Requêtes HTTP par des URL Servlet : descripteur de déploiement JSP : extension du fichier 68 Philippe Lalevée 34

35 Applications B2C Le conteneur Web interagit avec le S.I. de l entreprise par des API ad hoc JavaMail, JDBC, JMS, JXTA 69 Applications intranet Le client accède directement aux ressources applicatives de l entreprise Intérêts : client «riche», sécurité simplifiée 70 Philippe Lalevée 35

36 Applications B2B Les conteneurs accèdent à leurs homologues Protocoles standards : CORBA, RMI, DCOM Technologies Web Services (architecture SOA) 71 Applications multi-tier Applications complètement intégrées Multiplateformes, multi-machines (cluster) Indépendance des parties (tier) 72 Philippe Lalevée 36

37 Urbanisation Construction «historique» 73 Conséquences sur le S.I. Gestion des données : ruptures Applications : mises à jour non répercutées Identifiants : plusieurs accès à une même information Chaîne informatique : échanges de données non «industrialisés» (sensibilité variable) Temporelle : délais de mise à jour longs Géographique : les données sont situées en des endroits différents Constats Duplication, saisies multiples Incohérences et erreurs 74 Philippe Lalevée 37

38 Urbanisation Urbaniser, c'est diriger la transformation continue du système d information pour le simplifier durablement Démarche d urbanisation Cartographie des systèmes existants Détermination des systèmes cibles 75 Principe d urbanisation n 1 Modularité et encapsulation Partitionnement du S.I. en sous-ensembles fortement cohérents Données et traitements conceptuellement proches et faiblement couplés Évolution de l un n a pas d impact sur les autres Services Fonctionnels Référentiels de données, accessibles par des interfaces publiques Traitements sous le contrôle de «pilotes» 76 Philippe Lalevée 38

39 Principe d urbanisation n 2 Sécurité du S.I. Infrastructure de confiance Authentification réciproque des acteurs Autorisation des échanges Les flux de contrôle sont toujours à l initiative du destinataire Mode Pull Chaque Service Fonctionnel garde le contrôle de ses données Fonctionnement autonome des Services Fonctionnels 77 Principe d urbanisation n 3 Localisation unique des informations Gestion en un point unique du S.I. Localisation unique et uniforme (URI) Distinction information/donnée Copie(s) possible(s) Archivage Gestion des délais (mémoire «cache») Redondance, clustering Non accessible aux traitements «métier» Intégrité des informations Propriétés ACID Modèle de données disjoints 78 Philippe Lalevée 39

40 Principe d urbanisation n 4 Localisation unique du pilotage Pilotage des activités du S.I. Modélisation sous forme d activités «métier» Toute activité métier est pilotée de bout en bout sans délégation par un unique Service Fonctionnel pilote Ce pilote enchaine les demandes de services aux référentiels Localisation unique et uniforme (URI) Modèle homogène Ressource : information ou traitement 79 Principe d urbanisation n 5 Urbanisation des échanges Architecture de communication point à point Chaque application métier «connaît» ses destinataires Elle assure le contrôle, la transformation, le suivi, la gestion des erreurs dépendances inter-application Découpage applicatif «urbain» Définition des zones (quartier/îlots/blocs) Définition des échanges entre zones Dictionnaire de données métier 80 Philippe Lalevée 40

41 Principe d urbanisation n 6 Sémantique des Protocoles Asynchronisme des pilotes Pas de contrainte point à point de synchronisation Modélisation doit permettre l activation simultanée «conversationnel/non conversationnel» Pas de connaissance «a priori» Gestion par messages Journalisation / invalidation des informations Services «sans état» État des référentiels toujours cohérents Facilite la gestion des transactions (à deux phases) 81 Intégration des Applications d Entreprise Intégration niveau de l Entreprise 82 Philippe Lalevée 41

42 Intégration des Applications d Entreprise Intégration Entreprise A2A : Application-to-Application Intégration des applications et des systèmes B2B : Business-to-Business Intégration des processus et des applications des partenaires/clients/fournisseurs B2C : Business-to-Consumer Intégration directe des clients finaux en processus «corporate» B2E : Business-to-Employee Intégration des fonctions de management de l organisation de l entreprise (RH, KM) 83 Intégration des Applications d Entreprise Types d intégration Portails Intégration d applications (portlets) au niveau utilisateur Données partagées Architecture d intégration au niveau de l accès aux données Fonctions partagées Architecture d intégration au niveau des fonctions ou méthodes Enterprise Application Integration o Partage de données et de processus métiers entre des applications connectées Service Oriented Architecture o Partage / échanges de services fonctionnels faiblement couplés 84 Philippe Lalevée 42

43 Intégration des Applications d Entreprise Principes EAI Partage des informations et des traitements entre «applications» Échanges d informations métier Enchaînement des processus métier Optimisation du S.I. Maintenance / erreurs et fautes Évolutivité des solutions technologiques La décentralisation (départementalisation) a entrainé Développement sur systèmes hétéroclites SGDB hétérogènes Réseaux non interopérables 85 Solutions actuelles Middleware Définition d interfaces applicatives Bus logiciel S.I. centré sur un ERP Intégration «propriétaire» Ces ERP sont des «silos» Applications WEB Développement «en dehors» du S.I. Notions intranet et Extranet Infrastructure «Orientée Message» Désynchroniser les traitements Adaptation des données Orchestration des processus BPM et Workflow Gestion des événements / séquences d action 86 Philippe Lalevée 43

44 Communications entre applications ERP ERP CRM SCM CRM SCM EAI Cli/Srv DataWH Cli/Srv DataWH Legacy Legacy 87 Intégration et XML Choix de XML Universalité de la solution Flexibilité des technologies Niveau des données Définition de formats de documents Validation des messages Transformations de format Niveau architecture technique Découplage des communications Applications hétérogènes 88 Philippe Lalevée 44

45 Middleware XML et les S.I. Applications métiers Annuaire ERP X M L X M L BUS XML X M L X M L X M L Bases de Données Services Distribués 89 Niveaux d intégration Plate-forme Connectivité matérielle, système et logicielle Données Passerelles bases de données et outils d extraction (datawarehouse) Composants Serveurs d applications, passerelles ERP, Tier du milieu Applications Adaptateurs dédiés ou Hub & Spoke Processus BPM (Business Process Management) : moteur de workflow, modélisation processus métiers 90 Philippe Lalevée 45

46 EAI : niveau application Intégration au niveau système mais aussi «sémantique» Différents aspects Nature des échanges : les messages sont des éléments du business (bon de commande ) Traitements particuliers liés aux échanges : «suivi», «stockage», «datawarehouse» Modèles de données mécanismes de conversion Intégration analyse business, sous forme d enchaînement de tâches enchaînement de programmes Architectures classique : point à point et pipeline Proposition d architecture centralisée : le «hub and spoke» 91 Architecture «hub and spoke» Le Hub Gestion centralisée des files d attente Communications 1/1 (question/réponse) ou 1/n (publier/souscrire) Le workflow Destination en fonction de l entête des messages Des valeurs contenues dans le message Séquences de traitement e-business (liste des étapes) Traitement des données Conversion métier Différent du codage Le Spoke Partie protocole réseau Adaptateur (JCA) Les messages (JMS, MSMQ) En XML Entête d identification Propriétés Application A Adaptateur Spoke File WorkFlow Hub File LDAP Application B Adaptateur File Traitement de données Spoke 92 Philippe Lalevée 46

47 EAI : niveau processus Métier Application 1 Workflow Backoffice Autres Systèmes Application 2 Services Application 3 Annuaire Services Bases Données 93 Deuxième partie WEB SERVICES TECHNOLOGIES ET ARCHITECTURES 94 Philippe Lalevée 47

48 Web Services: Technologies et Architecture PRINCIPES 95 Exemple type Agence de voyage Un produit «voyage» est la combinaison de plusieurs produits Billets de transport Chambres d hôtel Voitures de location Son élaboration est le résultat de services et d informations obtenus auprès de plusieurs fournisseurs Compagnies aériennes Chaînes hôtelières Loueurs de véhicules Quelles sont les solutions? 96 Philippe Lalevée 48

49 Les besoins des entreprises Les compagnies, les fournisseurs, les partenaires et les clients doivent être capables de travailler ensemble Plus vite que jamais auparavant À travers Internet Ou risquer la «mort par isolement» leurs systèmes d information se recouvrent Certains de leurs processus métier sont donc communs Assurer l interopérabilité? Évolutivité? Transparence? Sécurité? Loueurs de véhicules Compagnies aériennes Agence de voyage 97 Serveurs d applications Architecture 3-tier des applications Moyen puissant pour construire des applications Web extensibles et adaptables Mais de telles applications sont des silos L intégration est une conséquence «après coup» Elles peuvent être intégrées derrière le pare-feu de l entreprise (firewall) Même cela peut être un problème Elles ne fournissent pas de moyen pour s intégrer à travers les pare-feux (i.e. à travers Internet) 98 Philippe Lalevée 49

50 Les Web Services! Un Web Service expose ses fonctionnalités au client Par une description (contrat) XML Automatisation des processus métiers Basé sur des standards Web TCP/IP, HTTP, XML, SOAP, WSDL, UDDI, WS-* (d autres à venir) Par une URL programmable à travers Internet ou l intranet (REST ) Par des fonctions appelables sur Internet Implémentés dans n importe quel langage sur n importe quelle plate-forme Ils agissent comme des «boîtes noires» Garantie d interopérabilité «Composants logiciels réutilisables» Les Web Services reprennent les avantages du calcul réparti et des portails et n en possèdent pas les inconvénients En fournissant un mécanisme pour invoquer des «méthodes» à distance En utilisant des standards du Web (comme HTTP, SMTP, XML ) En proposant un «bus XML» garant de l interopérabilité En intégrant les applicatifs sans les remettre en cause 99 Web Services: Technologies et Architecture SCHÉMAS XML 100 Philippe Lalevée 50

51 Les acteurs Le client Celui qui utilise, invoque le Web Service Le fournisseur (prestataire) Serveur d application (par exemple, J2EE) Les services sont des composants (par exemple, des servlet/ejb) enveloppés dans une couche service L annuaire Publication du service dans un dépôt (registre) 101 Tâches associées Interroger un annuaire Pour connaître la nature, le rôle et le contenu des services Négocier avec les fournisseurs Nature exacte du service fourni Qualité, coût Interagir avec le service Modalités d interaction Introduire le service dans la chaîne de traitement Composer des services Publier des services 102 Philippe Lalevée 51

52 Relations entre les acteurs Demandeur de Services Web Client API SOAP 4. Invoque le service Fournisseur de Services Web Impl Publi Document WSDL 3. Recherche le WSDL 2. Recherche le service Annuaire UDDI 1. Publie le service Tous les messages sont des requêtes SOAP 103 Scénario complet Étape 1. Définition et description du service Contrat de service en WSDL Étape 2. Publication du service Annuaire UDDI Étape 3. Recherche du service Interrogation d un annuaire UDDI Étape 4. Enregistrement du service Contact avec le fournisseur et respect du contrat Étape 5. Mise en œuvre du service Invocation selon le contrat Étape 6. Composition Applications orientées service 104 Philippe Lalevée 52

53 Les protocoles et schémas Internet (le Web) HTTP, XML et DNS SOAP (Simple Object Access Protocol) IIOP pour CORBA RMI pour les EJB WSDL (Web Service Description Language) IDL pour CORBA Interfaces Java pour les EJB UDDI (Universal Description, Discovery and Integration) et DISCO CosNaming pour CORBA JNDI pour les EJB 105 Un exemple Source : Philippe Lalevée 53

54 Web Services: Technologies et Architecture CONCEPTION 107 Conception d un Web Service Un composant logiciel fabrique la concaténation à partir de deux chaines de caractères Les clients peuvent utiliser différents langages sur différentes plateformes Les échanges se font par Internet, en traversant des firewalls Principe : fournir un Web Service (SimpleService) à partir d un serveur ( L URL est appelée Web Service Endpoint Pour l instant, une seule opération concat est proposée 108 Philippe Lalevée 54

55 Structure du Web Service (1) Serveur Web : Web Service : /SimpleService Opération : Nom : concat Namespace : Opération : Nom : Ils constituent ensemble le EndPoint du Web Service Comment garantir que concat soit globalement unique? Utiliser un namespace! concat est un «local name» Le nom complet est appelé un QName (Qualified Name) Internet 109 Style RPC du Web Service Style RPC (Remote Procedure Call) Forme : Type Opération (Type par1, Type par2 ) Les paramètres sont transmis «un par un» Opération : Local Name : concat Namespace : Paramètres : s1 : string (w3.org/xmlschema) s2 : string Retour : string (w3.org/xmlschema) (w3.org/xmlschema) Que signifie string? Ce ne peut pas être un type d un langage, donc utiliser un schéma XML! 110 Philippe Lalevée 55

56 Organisation des messages Les RPC peuvent être proposés, sous forme de messages L appel est appelé «input message» La valeur de retour est appelée «output message» Les paramètres sont appelées «parts» Local Name: concat Namespace: Input Message: Part 1: Name: s1 Type : string (w3.org/xmlschema) Part 2: Name: s2 Type : string (w3.org/xmlschema) Output Message: Part 1: Name: retour Type : string (w3.org/xmlschema) 111 Appel du Web Service Local Name: concat Namespace: Input Message: Part 1: Name: s1 Type : string (w3.org/xmlschema) Part 2: Name: s2 Type : string (w3.org/xmlschema) Output Message: Part 1: Name: retour Type : string (w3.org/xmlschema) <miage:concat xmlns:miage=" xmlns:xsd="... XMLSchema"...> <s1 xsi:type="xsd:string">bonne</s1> <s2 xsi:type="xsd:string">journée</s2> </miage:concat> 112 Philippe Lalevée 56

57 Retour du Web Service Local Name: concat Namespace: Input Message: Part 1: Name: s1 Type : string (w3.org/xmlschema) Part 2: Name: s2 Type : string (w3.org/xmlschema) Output Message: Part 1: Name: retour Type : string (w3.org/xmlschema) <miage:concat xmlns:miage=" xmlns:xsd="... XMLSchema"...> <retour xsi:type="xsd:string">bonne journée</retour> </miage:concat> 113 Style DOCUMENT du Web Service Les données envoyées et reçues peuvent être validées Forme : Document Opération (Document) Les schémas des documents doivent être fournis dans l interface du WS Local Name: concat Namespace: Input Message: Part 1: Name: concatrequest Element: concatrequest Output Message: <xsd:schema targetnamespace=" <xsd:element name="concatrequest"> <xsd:complextype> <xsd:sequence> <xsd:element name="s1" type="xsd:string"/> <xsd:element name="s2" type="xsd:string"/> </...> </xsd:schema> 114 Philippe Lalevée 57

58 Port Type: quelles opérations? <miage:concatrequest xmlns:miage=" <s1>bonne</s1> <s2>journée</s2> </miage:concatrequest> Seul le document est envoyé dans la requête : comment transmettre l opération? Les Web Services ne contiennent pas la liste des opérations Les opérations sont groupées dans des «Port Type» Un Port Type peut être vu comme une classe Java et les opérations qu il contient comme des méthodes statiques Plusieurs Port Type peuvent être associés à un Web Service 115 Les WS avec des Port Type Serveur Web : Web Service : /SimpleService Schéma: Port Type: Name: stringutil NS: Opération : Nom : concat NS: Port Type: Name: dateutil NS: Opération : Nom : concat NS: Internet 116 Philippe Lalevée 58

59 binding : comment préciser le format? Le format des messages spécifie comment ils sont échangés : Texte (chaîne de caractères) éventuellement MIME XML : XML-RPC ou SOAP Le format textuel ne permet pas la validation Le standard W3C SOAP fournit une interface HTTP/XML robuste Support étendu des types de données Mais complexité de mise en œuvre (et efficacité?) Et aussi comment ils sont transportés GET ou POST SMTP GET et POST utilisent le protocole HTTP pour invoquer les Web Services en mode synchrone SMTP utilise le mail en mode asynchrone Les combinaisons sont appelées des «binding» 117 Les WS avec des Binding Web Service : /SimpleService Schéma: Port Type: Name: stringutil NS: Binding: Nom : Liaison1 Port Type: stringutil Format: SOAP Transport: HTTP Binding: Nom : Liaison2 Port Type: stringutil Format: TEXT Transport: SMTP POST /M2/TP2/WS.do HTTP/1.1 User-Agent: Mozilla/ <miage:concatrequest...> <s1>bonne</s1> <s2>journée</s2> </miage:concatrequest> FROM: lalevee@lalevee.net TO: lalevee@emse.fr concat(s1="bonne",s2="journée") 118 Philippe Lalevée 59

60 Port: sur plusieurs machines Un même Web Service peut être proposé sur plusieurs machines «Port» C est un «Binding» que l on place sur un «Port» Par exemple, dans l exemple précédent, on peut placer Liaison1sur les machines miage1, miage2 et miage3, et Liaison2 sur la machine miage3 Il y a dans ce cas QUATRE «Port» Un composant logiciel devra être présent pour mettre en œuvre le «Port Type» Les ports peuvent être de langage différent Sur une même machine (par exemple miage3), plusieurs formats et transports peuvent cohabiter 119 Retour sur les URI, URN et URL Les Web Services doivent définir un espace de nommage unique (en général, il est commun) en utilisant une URI, «Uniform Resource Identifier» Soit une URL, «Uniform Resource Locator» Soit un URN, «Uniform Resource Name» Choix d une URL Le domaine est géré par vous Cohérence possible avec l accès Mais risque de confusion Choix d un URN Indépendance avec l accès et la localisation Syntaxe : urn:name_identifier:name_specific Désignation standardisée par le IANA, mais utilisation possible du nom de domaine comme name_identifier Par exemple, pour notre Web Service : urn:miage.org:ns 120 Philippe Lalevée 60

61 Web Services: Technologies et Architecture WSDL 121 WSDL : présentation Les concepts que nous venons de voir constituent les éléments de schéma WSDL Un fichier WSDL regroupe les informations nécessaires pour interagir avec le Web Service Les types (schéma), types de port (classes), opérations (méthodes) Les parties (paramètres), liaisons (protocole de transport) et ports (localisation du service) La publication et la recherche de services au sein de l annuaire UDDI se font avec WSDL Le fichier retourné est celui contenant l implémentation du service Le fichier contenant l interface de mise en œuvre est fourni par le premier Schéma XML : deux fichiers distincts Définitions des interfaces des services Sémantique abstraite pour les Web Services Définitions de l implémentation du service Nom concret du nœud et adresse réseau où le Web Service peut être invoqué Délimitation claire entre les messages abstraits et concrets 122 Philippe Lalevée 61

62 Exemple : gestion de compte Pour illustrer les différentes parties, voici une interface Java pour une gestion de compte Le passage de Java vers WSDL se fait en général avec des outils fournis (wsdl2java) ou bien intégrés au serveur d application import java.util.*; public interface CompteInterface { public void depotde (int montant); public boolean retraitde (int montant); public int valeursolde (); public Vector listemouvements(); } 123 Partie 1. Les types La methode listemouvements retourne un Vector description de ce type <wsdl:types> <schema targetnamespace=" xmlns=" <import namespace=" /> <complextype name="vector"> <sequence> <element maxoccurs="unbounded" minoccurs="0" name="item" type="xsd:anytype" /> </sequence> </complextype> </schema> </wsdl:types> Pour cet exemple, les autres types sont prédéfinis 124 Philippe Lalevée 62

63 Partie 2. Les messages Les méthodes disposeront de deux messages : un pour l appel, un pour la réponse <wsdl:message name="listemouvementsrequest" /> <wsdl:message name="listemouvementsresponse"> <wsdl:part name="listemouvementsreturn" type="apachesoap:vector" /> </wsdl:message> <wsdl:message name="depotderequest"> <wsdl:part name="in0" type="xsd:int" /> </wsdl:message> <wsdl:message name="depotderesponse"> <wsdl:part name="depotdereturn" type="xsd:boolean" /> </wsdl:message> Partie 3. Les types de port Un type de port est composé des opérations abstraites applicables au service, ie les signatures de méthodes Java (dans l interface) Les opérations sont composées d une séquence de messages (un pour l appel, un pour le retour) à un mode d invocation particulier du service <wsdl:operation name="listemouvements"> <wsdl:input message="impl:listemouvementsrequest" name="listemouvementsrequest" /> <wsdl:output message="impl:listemouvementsresponse" name="listemouvementsresponse" /> </wsdl:operation> 126 Philippe Lalevée 63

64 Partie 3. Les types de port Dans l exemple, il y aura un seul type de port, composé des 4 opérations <wsdl:porttype name="compte"> <wsdl:operation name="listemouvements"> <wsdl:input message="impl:listemouvementsrequest" name="listemouvementsrequest" /> <wsdl:output message="impl:listemouvementsresponse" name="listemouvementsresponse" /> </wsdl:operation> <wsdl:operation name="depotde" parameterorder="in0"> <wsdl:input message="impl:depotderequest" name="depotderequest" /> <wsdl:output message="impl:depotderesponse" name="depotderesponse" /> </wsdl:operation>... </wsdl:porttype> 127 Partie 4. Les liaisons Les liaisons décrivent la façon dont un type de port (l abstraction du service) est mis en œuvre pour un protocole particulier (HTTP par exemple) Pour un mode d invocation particulier (RPC par exemple) Cette description est faite pour un ensemble d opérations abstraites Pour un type de port, on peut avoir plusieurs liaisons Différenciation des modes d invocation ou de transport des différentes opérations 128 Philippe Lalevée 64

65 Partie 4. Les liaisons <wsdl:binding name="comptesvcbinding" type="impl:compte"> <wsdlsoap:binding style="soap" transport=" /> <wsdl:operation name="depotde"> <wsdlsoap:operation soapaction="" /> <wsdl:input name="depotderequest"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded" /> </wsdl:input> <wsdl:output name="depotderesponse"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded" /> </wsdl:output> </wsdl:operation>... </wsdl:binding> 129 Partie 5. Les ports Un port spécifie une adresse URL de l implémentation d un service par un fournisseur Le port est associé à une «liaison» définissant ainsi un simple point de terminaison <wsdl:port binding="impl:comptesvcbinding" name="comptesvc"> <wsdlsoap:address location=" /> </wsdl:port> 130 Philippe Lalevée 65

66 Partie 6. Le service Un service est décrit comme un ensemble de points finaux du réseau : «port» <wsdl:service name="comptesvc"> <wsdl:port binding="impl:comptesvcbinding" name="comptesvc"> <wsdlsoap:address location=" /> </wsdl:port> </wsdl:service> 131 Web Services: Technologies et Architecture SOAP 132 Philippe Lalevée 66

67 SOAP : les principes Principe fondateur : «ne pas inventer de nouvelles technologies» Bâti à partir de standards Internet clé SOAP HTTP + XML Soumis au W3C Les spécifications SOAP définissent : Le format des messages SOAP Comment envoyer des messages Comment recevoir des messages L encodage des données 133 Structure des messages SOAP Message Headers SOAP Envelope SOAP Header Headers Le message complet SOAP Entêtes de liaison du protocole <Envelope> contient les données <Header> contient les entêtes Entête particulière SOAP Body Message Name & Data <Body> contient le nom du message SOAP Nom et données encodées en XML du message SOAP 134 Philippe Lalevée 67

68 Exemple complet d une requête <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle= " xmlns:xsi=" xmlns:xsd=" > <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="urn:monservicesoap"> <symbol>dis</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 135 Exemple complet d une réponse <?xml version= 1.0 encoding= UTF-8?> <SOAP-ENV:Envelope xmlns:soap-env= " SOAP-ENV:encodingStyle= http: //schemas.xmlsoap.org/soap/encoding/ xmlns:xsi=" xmlns:xsd=" > <SOAP-ENV:Body> <m:getlasttradepriceresponse xmlns:m= urn:monservicesoap"> <return xsi:type= xsd:float >34.5</return> </m:getlasttradepriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 136 Philippe Lalevée 68

69 Exemple : réponse avec une structure de données <soap:envelope...> <soap:body> <GetStockDataResult xmlns= > <result> <Description>Plastic Novelties Ltd</Description> <Prix>129</Prix> <Action>PLAS</Action> </result> </GetStockDataRseult> </soap:body> </soap:envelope> 137 Exemple d erreur <?xml version= 1.0 encoding= UTF-8?> <SOAP-ENV:Envelope xmlns:soap-env=" <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>soap-env:mustunderstand</faultcode> <faultstring SOAP Must Understand Error </faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 138 Philippe Lalevée 69

70 La sécurité des échanges Bâtie sur la sécurité offerte par HTTP HTTPS certificats X.509 Les développeurs choisissent quelle méthode exposer explicitement Les applications (source) ne sont pas concernées Compatible avec les pare-feux Compatible avec les types de données 139 SOAP et Tomcat : schéma simplifié Client Requête SOAP Réponse SOAP Serveur HTTP Tomcat SOAP Dispatcher Réseau Internet Implémentation Fournisseur de service 140 Philippe Lalevée 70

71 SOAP: Interopérabilité Java et Excel Tomcat Data Base Tableau Excel VB Macro SOAP Servlet SOAP DLL HTTP DLL SOAP jar JDBC jar Service Client Serveur Parser XML 141 Interactions WSDL et SOAP 142 Philippe Lalevée 71

72 Liaison entre services 143 Mécanismes mis en jeu 144 Philippe Lalevée 72

73 Insertion de services techniques 145 Web Services: Technologies et Architecture SOA AVEC REST ET WS-* 146 Philippe Lalevée 73

74 Retour sur les architectures Architecture logicielle Description de sa structure : composants logiciels, connecteurs (propriétés externes) et les relations entre eux (communication) Style Modèles de structure, vocabulaire de composants, contraintes de relation Caractérisation Trois grands styles Architectures orientées objet Architectures orientées ressources Architectures orientées services 147 Architecture orientée Objet Composant = objet Identificateur État Connecteur = interface Comportement Liste d opérations (méthodes) Relations = appel «bloquant/synchrone» RPC, RMI, DCOM Modèle client/serveur CORBA / JEE RMI /.NET 148 Philippe Lalevée 74

75 Architecture orientée Ressource Composant = URI «tout ce qui a une identité» État Connecteur = «copie» de la ressource Extraction par requête (HTTP get, SQL select) Gestion comparable à une mémoire cache Relations = WWW Standards Internet Modèle client/serveur WEB 2.0 / REST 149 Architecture REST REST = REpresentational State Transfer Inventé par Fielding en 1994 À la base du WWW : accès aux ressources Accès ressource = représentation de cette ressource par un serveur Clic sur un lien = transition d état (accès) Application Web = réseau de ressources permettant des transitions d état Exemples Standards W3C URI / URL / URN HTTP / HTTPS XHTML / XML / MIME 150 Philippe Lalevée 75

76 Les 10 principes REST 1. Identifier les ressources 2. Choisir celles dont la durée de vie est supérieure à une transaction/session 3. Les nommer avec une URI (logique) pour favoriser le couplage lâche 4. Utiliser des noms car ressource = état 5. Donner des URI stables (permanentes) 6. Nommer les ressources «métier» 7. Utilisation de GET pour la lecture (mémoire cache, sécurité) et POST pour la mise à jour 8. Services sans état (à la charge du client) 9. Services asynchrones 10. Représentation des données en XML 151 Architecture orientée Service Composant = fonction logicielle autonome Sans état Couplage faible Interopérabilité (agnostique) Connecteur = URI du prestataire Schémas XML Description par un «contrat» Relations = WWW Standards Internet Modèle consommateur/prestataire WS-* (SOAP-WSDL-UDDI) / REST 152 Philippe Lalevée 76

77 Le portail programmableweb.com Les 6 principes WS-* Message Enveloppe (entête / corps) Requester / Provider : agents Web Service Transport «abstrait» Action Exécutée par un agent (message, notification ) Service Ressource (URI) dont la description est accessible Description = interface des services Interface = messages reçus/envoyés par les actions Orchestration Enchainement des actions, sous couvert d une politique réalisation processus métier Chorégraphie Interactions de plusieurs Web Services dans leur intégration Politique de gestion Sémantique de communication Contrôle de flot (états successifs des services) Sécurité et qualité des services, «console de management» 153 Pour aller plus loin 154 Philippe Lalevée 77

78 developer.ebay.com 4,5 Mo!! 155 Architecture SOA Principe SOA (Service Oriented Architecture) toute application est un ensemble de processus coopérant en se fournissant mutuellement des services Englobe les architectures client/serveur (maître/esclave) et pair à pair (peer-to-peer) Architecture client/serveur «rendue» symétrique Architecture pair à pair applicative Application orientée services rôle de prestataire et de client dans les relations de service Les «Web Services» permettent de bâtir des applications SOA, mais ce n est pas le seul moyen 156 Philippe Lalevée 78

79 Intégration de la chaîne de valeur Source IBM 157 Évolution des technologies 158 Philippe Lalevée 79

80 Architecture technique (simple) 159 Les fonctions SOA 160 Philippe Lalevée 80

81 Architecture complète 161 Infrastructure généralisée 162 Philippe Lalevée 81

82 Enterprise Service Bus 163 ESB et SOA 164 Philippe Lalevée 82

83 SOAP/WSDL ESB! 165 Vision IBM: on demand Source IBM 166 Philippe Lalevée 83

84 Web Services: Technologies et Architecture CLOUD COMPUTING 167 Cloud computing Pourquoi «cloud computing»? 168 Philippe Lalevée 84

85 Premiers éléments 169 L architecture complète 170 Philippe Lalevée 85

86 Storage-as-a-Service Espace disque à la demande Accès à un espace de stockage distant «vu» localement Service de «base» dropbox, box.net, ubuntu one, Amazon S3 171 Database-as-a-Service SGBD distant «partagé» vu localement Différents modèles Relationnel Objet XML Document Externalisation administration Apache CouchDB, Amazon SimpleDB 172 Philippe Lalevée 86

87 Information-as-a-Service Capacité de traiter tout type de donnée, stockée à distance Définition d interfaces publiques Données métier Cours de la bourse Agences d information Service météorologique Validation d adresse Facebook, twitter, linkedin 173 Process-as-a-Service Réalisation de processus métier à partir de ressources distantes pouvant interconnecter des services et des données 174 Philippe Lalevée 87

88 Application-as-a-Service Ou Software-as-a-Service Application Web fournie à travers un navigateur Granularité variable Google Docs, Salesforce SFA, Zimbra, Yahoo, Bloomberg, Zoho 175 Platform-as-a-Service Plate-forme complète de développement d applications Basée sur un modèle «temps partagé» Conception, développement, déploiement, intégration, stockage, opérations Google app engine, Microsoft Azure, IBM Cloud, Sun Zembly 176 Philippe Lalevée 88

89 Integration-as-a-Service Fourniture de capacités d intégration aux applications : interfaces, contrôle de flux, orchestration Technologie EAI fournie sous forme de services Transformation Routage Interfaces journalisation 177 Security-as-a-Service Services de sécurité fournis à travers Internet Gestion centralisée d identification 178 Philippe Lalevée 89

90 Gouvernance-as-a-Service Gestion des services du «cloud» Topologie, utilisation des ressources, virtualisation, temps de service Définitions de politiques d accès aux données et aux services 179 Testing-as-a-Service Test de systèmes/applications utilisant des services hébergés Systèmes locaux ou distants Applications Web Systèmes d information d entreprise 180 Philippe Lalevée 90

91 Infrastructure-as-a-Service Service de type «data center» Fourniture de ressources de calcul Serveurs physiques Systèmes d exploitation Accès à l ensemble des ressources de machines Regroupe SaaS, DaaS, PaaS Amazon EC2 181 SOA et Cloud Computing Le cloud intègre les technologies Virtualisation des ressources Interfaces standards «service» 182 Philippe Lalevée 91