La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Les Web Services Thierry CAZENAVE www.cosmosbay-vectis.com Vision technologique Le 24 Novembre.

Présentations similaires


Présentation au sujet: "1 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Les Web Services Thierry CAZENAVE www.cosmosbay-vectis.com Vision technologique Le 24 Novembre."— Transcription de la présentation:

1 1 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Les Web Services Thierry CAZENAVE Vision technologique Le 24 Novembre 2003 S chéma D irecteur des E spaces numériques de T ravail Groupe de Travail Interopérabilité

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

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

4 4 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 SOAP - Le protocole Est un protocole entièrement basé sur le langage XML : 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 : 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 dautres spécifications XML pour apporter des services de plus haut niveau tels que : 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 (QoS) 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 W3C

5 5 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 POST /StockQuote HTTP/1.1 Host: Content-type: text/xml; charset="utf-8" Content-length: nnnn SOAPAction: "Some URI" DIS REQUETE SOAP - Un exemple HTTP/ OK Content-type: text/xml; charset="utf-8" Content-length: nnnn 34.5 REPONSE

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

7 7 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 Où il se situe (i.e. quelles URLs et quels protocoles vont permettre son invocation) Comment linvoquer (i.e. quelles sont les méthodes disponibles et leurs paramètres, les types de données sont définies à base de XML Schema) Le rôle de WSDL est essentiel, puisque ce sont les documents WSDL qui seront échangés entre les partenaires de manière à ce quils puissent techniquement mettre en œuvre la communication basée sur les Web Services Lintérêt de WSDL réside dans les quatre points suivants : Le langage WSDL peut être utilisé pour définir complètement linterface daccès dun service distant Côté serveur, le fichier WSDL peut être généré automatiquement par introspection des classes qui implémentent le service Côté client, le fichier WSDL peut être utilisé pour générer automatiquement un proxy (java, C#…) permettant dinvoquer le service Le fichier WSDL peut être exporté dans un annuaire UDDI permettant ainsi quil soit découvert par interrogation de cet annuaire

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

9 9 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Les compléments du socle de base Transport & communication SOAP WS-RoutingWS-Referral WS-Encrypt Transport Routage Securité Composants XLink WSDL Registres & annuaires UDDI WS-Inspection Processus, orchestrations & transactions XMLDsigXML Encrypt XKMS XPDLWSFLWSCI XAMLBTPWSTx BPMLBPSSXLANG Présentation XUP WSIF WSIAWSUI Orchestrations Processus Transactions XML Schema BPEL 4WS XAML Maturité décroissante

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

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

12 12 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 JSR 168 – Contexte et Objectifs Responsable de la spécification Sun Microsystems, Inc. - Alejandro Abdelnur IBM - Stefan Hepper Groupe dexpertise Lobjectif de la Java Specification Request 168 est de définir un ensemble dAPI et de déclarations relatifs à: Lagrégation dinformations La personnalisation La présentation La sécurité Le déploiement Spécification finale v1.0: 27 Oct, 2003 Intéropérabilité entre les portlets et les portails Apache Software Foundation Art Technology Group Inc.(ATG) BEA Systems Boeing Borland Software Corporation Broadvision Inc. Citrix Systems EDS Fujitsu Limited IBM Novell, Inc. Oracle SAP AG SAS Institute Inc. Sun Microsystems, Inc. Sybase TIBCO Software Inc. Vignette

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

14 14 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 JSR 168 – Couverture de la spécification Définition des différents composants dun portail Leurs interactions Leurs cycles de vies Leur sémantiques Ces composants sont, entre autres: 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 dextension La spécification définit certains fonctionnements des zones: Les état minimum dune fenêtre de Portlet: normal, minimale, maximale,..; Les modes des Portlets Mode View (client final) Mode Edit (Ex. Contributeur du portlet) Mode Configuration (Ex. Administrateur du portlet) …

15 15 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: A lutilisateur courant et à son profil; A leur positionnement dans la page; Aux actions possibles; Aux informations du client Web A de linformation 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 dURL permettant dinvoquer des actions à destination de certaines portlets sans connaissance à priori du contexte. Les portlets doivent être contenus dans un fichier darchive Web (WAR) contenant les descriptions de déploiement. Aucune restriction sur le protocole utilisé (Accès à différentes sources dinformations par des canaux différents). Autoriser lexécution de Portlet distante (proxy,…) Proche WSRP

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

17 17 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 JSR 168 – Interface Portlet Diagramme de séquence issu de Portlet specification 1.0 Linterface Portlet contient les méthodes permettant de gérer le cycle de vie dune portlet: Init() processAction() render() destroy() LAPI contient une implémentation de base GenericPortlet. Il y a une seule instance de Portlet par conteneur.

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

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

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

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

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

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


Télécharger ppt "1 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Les Web Services Thierry CAZENAVE www.cosmosbay-vectis.com Vision technologique Le 24 Novembre."

Présentations similaires


Annonces Google