Schma Directeur des Espaces numriques de Travail Groupe

Schéma Directeur des Espaces numériques de Travail Groupe de Travail Interopérabilité Les Web Services Vision technologique Le 24 Novembre 2003 1 Thierry CAZENAVE www. cosmosbay-vectis. com SDET – Groupe de travail interopérabilité – 24 Novembre 2003

Agenda ¦ Le socle technologique de base SOAP u WSDL u UDDI u ¦ Les initiatives ¦ Les perspectives JSR 168 u WSRP u ESB u 2 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

Le socle technologique de base ¦ L’Architecture Web Services met en œuvre conjointement les spécifications : ¦ SOAP : Simple Object Access Protocole de type RPC utilisant XML pour la structuration de ses messages u Initialement proposé par Microsoft, désormais géré par le W 3 C u ¦ WSDL : Web Service Description Language Il faut être capable de décrire de manière unifiée les services pour pouvoir les invoquer u WSDL est une spécification de description des Web Services u WSDL est un complément de SOAP (peut être vu comme l’IDL de CORBA) u ¦ UDDI : Universal Description, Discovery and Integration u Annuaire des Services Web mis à disposition par les entreprises, permet la découverte, la sélection et la mise à disposition descriptions de services 3 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

SOAP - Le protocole ¦ Est un protocole entièrement basé sur le langage XML : u Définit la structure du message (l'enveloppe) et les données véhiculées (le corps) ¦ Utilise des protocoles standards de l'Internet : HTTP, SMTP ou encore FTP : u Le choix du protocole est guidé par les contraintes techniques du système ou encore le mode de communication désiré (synchrone ou asynchrone) ¦ Est extensible, il peut être complété par d’autres spécifications XML pour apporter des services de plus haut niveau tels que : u u u u Les pièces jointes Le routage et les intermédiaires La garantie de délivrance La sécurité Le contexte et la confidentialité Les transactions La qualité de Service (Qo. S) ¦ Le protocole SOAP peut être considéré comme un « standard de fait » de par son adoption par un grand nombre d’éditeurs et sa prise en main par le W 3 C 4 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

SOAP - Un exemple POST /Stock. Quote HTTP/1. 1 Host: www. stockquoteserver. com Content-type: text/xml; charset="utf-8" Content-length: nnnn SOAPAction: "Some URI" REQUETE <SOAP-ENV: Envelope xmlns: SOAP-ENV="http: //schemas. xmlsoap. org/soap/envelope/" SOAP-ENV: encoding. Style="http: //schemas. xmlsoap. org/soap/encoding/"> <SOAP-ENV: Body> <m: Get. Last. Trade. Price xmlns: m="Some URI"> <symbole>DIS</symbole> </m: Get. Last. Trade. Price> </SOAP-ENV: Body> </SOAP-ENV: Envelope> HTTP/1. 1 200 OK Content-type: text/xml; charset="utf-8" Content-length: nnnn <SOAP-ENV: Envelope xmlns: SOAP-ENV="http: //schemas. xmlsoap. org/soap/envelope/" SOAP-ENV: encoding. Style="http: //schemas. xmlsoap. org/soap/encoding/"> <SOAP-ENV: Body> <m: Get. Last. Trade. Price. Response xmlns: m="Some URI"> <Price>34. 5</Price> </m: Get. Last. Trade. Price. Response> </SOAP-ENV: Body> </SOAP-ENV: Envelope> 5 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 REPONSE

SOAP – Données échangées ¦ SOAP Véhicule des données au format XML Enveloppe, en-tête et corps u Données échangées dans le cadre de l’appel du service ( Contenu du corps, Pièces jointes éventuelles ) u ¦ Ces données peuvent être : Des données quelconques u Des données XML + Schéma ( XSD ) u Définies dans le Contrat ( WSDL ) u Document libre (forme et contenu) Document libre (contenu) Document métier définition externe Définition interne ¦ Du choix technique et de la granularité de description dépends : Le contrôle sur la qualité des données échangées ( typage +/- fort ) u Le travail d’analyse des données en réception u u u Requête Fournisseur de service Réponse Consommateur de service Le couplage technique entre consommateurs et fournisseurs u Le couplage métier entre consommateurs et fournisseurs u L’approche par document validé par un schéma combine : grand degrés de liberté, qualité des contrôles et interopérabilité 6 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

WSDL ¦ WSDL est un langage XML de description des Web Services ¦ Un document WSDL décrit : Ce que fait un Web Service u Où il se situe (i. e. quelles URLs et quels protocoles vont permettre son invocation) u Comment l’invoquer (i. e. quelles sont les méthodes disponibles et leurs paramètres, les types de données sont définies à base de XML Schema) u ¦ Le rôle de WSDL est essentiel, puisque ce sont les documents WSDL qui seront échangés entre les partenaires de manière à ce qu’ils puissent techniquement mettre en œuvre la communication basée sur les Web Services ¦ L’intérêt de WSDL réside dans les quatre points suivants : Le langage WSDL peut être utilisé pour définir complètement l’interface d’accès d’un service distant u Côté serveur, le fichier WSDL peut être généré automatiquement par introspection des classes qui implémentent le service u Côté client, le fichier WSDL peut être utilisé pour générer automatiquement un proxy (java, C#…) permettant d’invoquer le service u Le fichier WSDL peut être exporté dans un annuaire UDDI permettant ainsi qu’il soit découvert par interrogation de cet annuaire u 7 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

UDDI ¦ UDDI (Universal Description, Discovery, and Integration) distingue trois types de registres : Pages Jaunes Pages Blanches i i i Informations sur les contacts, adresses, téléphones, etc. Op Publier Comment enregistrer un nouveau service dans le registre Pages Vertes Catégorisation des différents services, basée sur l’utilisation de taxinomies standards Op Recher Comment on peut trouver un service Web particulier 8 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Informations techniques sur les Services proposés par une entreprise particulière Op Connecter Comment une application va pouvoir se connecter et interagir avec un Service Web

Les compléments du socle de base Présentation WSIA WSUI XUP WSIF XAML Processus, orchestrations & transactions Transactions XAML BTP Processus BPML XLANG XPDL WSFL Orchestrations BPEL 4 WS WSTx BPSS WSCI Registres & annuaires WS-Inspection UDDI Composants XLink XML Schema Transport & communication Securité Routage Transport XMLDsig WSDL XKMS XML Encrypt WS-Routing WS-Encrypt WS-Referral SOAP Maturité décroissante 9 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

Les initiatives liées à la couche présentation ¦ WSIF (Web Service Invocation Framework) - IBM (alpha. Works) u Interface générique d’invocation de Web Services ¦ WSUI (Web Service User Interface) – Epicentric u Langage de définition d’interfaces utilisateurs aux Web Services ¦ XUP (Extensible User Interface Protocol) - W 3 C u Protocole permettant de délivrer les événements d’interfaces utilisateurs pour traitement par des Web Services ¦ WSIA (Web Services for Interactive Application) – OASIS u Modèle de composant d’interface basé sur XML et les Web Services ¦ JSR 168 - JCP u Normalisation de la notion de Portlet JSR 168 Portal JAVA Application JSR 168 Portlet JAVA Proxy Contenu agrégé au format HTML, WML, Voice. XML. . . JSR 168 10 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 JSR 168

Les initiatives ¦ WSRP (Web Services for Remote Portals) – OASIS u Définition de Web Services « orientés présentation » ANY Portal ANY WSRP Web Service Application WSRP Web Service Contenu agrégé au format HTML, WML, Voice. XML. . . Fragments de présentation Transmis via SOAP ¦ POST ( Portlet Open Source Trading ) – Sun, Plumtree, Documentum, BEA u Partage de portlets Open Source ( JSR 168 + WSRP ) ( 03/11/2003 ) ¦ WS-I ( Web Services Interoperability org. ) – IBM, Microsoft u u u Suivi des évolution des spécifications et standards Élaboration d’un ensemble d’outils de test de conformité des implémentations OMG, OASIS, OAGI, POSC Associate Members ( 18/11/2003 ) 11 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

JSR 168 – Contexte et Objectifs ¦ Responsable de la spécification Sun Microsystems, Inc. - Alejandro Abdelnur u IBM - Stefan Hepper u ¦ Groupe d’expertise 1. Apache Software Foundation 2. Art Technology Group 3. Inc. (ATG) 4. BEA Systems 5. Boeing 6. Borland Software Corporation 7. Broadvision Inc. • Citrix Systems • EDS • Fujitsu Limited • IBM • Novell, Inc. • Oracle • SAP AG • SAS Institute Inc. • Sun Microsystems, Inc. • Sybase • TIBCO Software Inc. • Vignette ¦ L’objectif de la Java Specification Request 168 est de définir un ensemble d’API et de déclarations relatifs à: u u u L’agrégation d’informations La personnalisation La présentation La sécurité Le déploiement Intéropérabilité entre les portlets et les portails ¦ Spécification finale v 1. 0: 27 Oct, 2003 12 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

JSR 168 – Principe général ¦ Les Portlets sont des composants Web destinés à être composés au sein d’une page composite unique. Portail Portlet 1 Portal page Requête Portlet 2 N Sources d’informations Portlet N Page Mes achats Portlet 1 News Portlet 2 Conteneur de portlets • Gestion du cycle de vie des portlets • Gestion de la persistance 13 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

JSR 168 – Couverture de la spécification ¦ Définition des différents composants d’un portail Leurs interactions u Leurs cycles de vies u Leur sémantiques u ¦ Ces composants sont, entre autres: u u u Portlets Descripteur de déploiement API Portlet API pour la gestion de la sécurité (authentification (Single Sign On), autorisation…) Personnalisation et la gestion de la disposition des éléments à l’écran API d’extension ¦ La spécification définit certains fonctionnements des zones: u Les état minimum d’une fenêtre de Portlet: u u normal, minimale, maximale, . . ; Les modes Portlets u u Mode View (client final) Mode Edit (Ex. Contributeur du portlet) Mode Configuration (Ex. Administrateur du portlet) … 14 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

JSR 168 – Expression des besoins ¦ La spécification est basée sur la spécification des Servlets et doit être basée sur le même mode de développement beaucoup de similitudes. ¦ Les portlets doivent avoir accès: u u u A l’utilisateur courant et à son profil; A leur positionnement dans la page; Aux actions possibles; Aux informations du client Web A de l’information partagée entre les portlets ¦ Avoir une manière standard pour stocker et retrouver les données par utilisateur et par instance de portlet. ¦ Proposer un mécanisme de ré-écriture d’URL permettant d’invoquer des actions à destination de certaines portlets sans connaissance à priori du contexte. ¦ Les portlets doivent être contenus dans un fichier d’archive Web (WAR) contenant les descriptions de déploiement. ¦ Aucune restriction sur le protocole utilisé (Accès à différentes sources d’informations par des canaux différents). ¦ Autoriser l’exécution de Portlet distante (proxy, …) 15 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Proche WSRP

JSR 168 – Portlet ? ¦ Extension de J 2 EE 1. 4 ¦ Package javax. servlet. portlet ¦ Technologies sous-jacentes: XML, JAXP (Java Api for XML Parsing) u Servlet/JSP u JAAS (Java Authentication and Autorisation Service) u Et tous autres couches de la spécification J 2 EE u Page de portail Contrôles <titre> Fenêtre de portlet <Contenu> Fragment de portlet <titre> <Contenu> 16 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

JSR 168 – Interface Portlet ¦ L’interface Portlet contient les méthodes permettant de gérer le cycle de vie d’une portlet: Init() u process. Action() u render() u destroy() u ¦ L’API contient une implémentation de base Generic. Portlet. ¦ Il y a une seule instance de Portlet par conteneur. 17 Diagramme de séquence issu de Portlet specification 1. 0 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

WSRP – Contexte ¦ WSRP est une initiative de l’OASIS ¦ Sociétés impliquées : u BEA, Bowstreet, Citrix, Commerce One, Computer Associates, Cross. Weave, Divine, Drake Certivo, Factiva, France Telecom, Fujitsu, Gluecode, HP, IBM, Interwoven, Kinzan, Lexis. Nexis, Lotus, Mac. Donald Bradley, Microsoft, Moravia IT, Netegrity, Novell, Oracle, Peoplesoft, Perficient, Plumtree, Reed Elsevier, SAP, See. Beyond, Silverstream, Stellent, Sun Microsystems, Sybase, Tibco , Vignette, Web. Collage ¦ S’appuie sur le travail déjà réalisé : Portails et Portlets u OASIS WSIA Technical Comitee ( Web Services for Interactive Application ) u ¦ Avec pour objectifs : L’alignement sur les standards existants u L’interopérabilité au delà du monde Java ( Microsoft. NET, Open Source ) u Un intégration la plus « plug & play » possible u Faire de l’Internet une place de marché de Web Services WSRP u 18 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

WSRP - Web Services for Remote Portals ¦ WSRP défini la notion de « fragment d’information » basées sur les langages HTML, XHTML, Voice. XML… ¦ WSRP gère la notion de session et de persistance ¦ Un Web Service « WSRP » s’intègre dans un portail sans programmation et constitue ainsi une forme de « Portlet » distant et standardisé ¦ WSRP présente un enjeu important pour l’interopérabilité des portails et la standardisation de la mise à disposition d’informations ou de services entre partenaires 19 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

WSRP – Protocole mis en oeuvre Utilisateur Découverte Consommateur Recherche / Accès au service Découverte Méta-données Établissement connexion Négociation Service découvert Connexion établie Capacités Exigences Négociation Authentification Producteur Authentification Accès authentifié Demande page ( Action ) Authentification Autorisation Action Change état Appel service ( action ) OK Utilisation Appel service ( présentation ) Page ( personnalisée ) Terminaison Capacités Exigences Action Change état Terminaison 20 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Action Change état

WSRP – Cas d’utilisations Portail Service WSRP Portail Application Portail 21 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

ESB - Émergence des Enterprise Service Bus ¦ L’ESB introduit le concept d’architecture en bus de services L’architecture « Hub » centralisée, traditionnelle de l’EAI u L’architecture « Bus » décentralisée, mise en œuvre par l’ESB u ¦ Une architecture « Bus » présente des avantages en terme de montée en charge et de tolérance aux pannes ¦ L’ESB veut se positionner comme chaînon manquant capable de concilier le nouveau modèle d’architecture orienté service (SOA) avec l’intégration traditionnelle (EAI) souvent incontournable pour les systèmes propriétaires 22 SDET – Groupe de travail interopérabilité – 24 Novembre 2003

. . . 23 SDET – Groupe de travail interopérabilité – 24 Novembre 2003