1 sdet – groupe de travail interopérabilité – 24 novembre 2003 les web services thierry...
TRANSCRIPT
1
SDET – Groupe de travail interopérabilité – 24 Novembre 2003
Les Web Services
Thierry CAZENAVEwww.cosmosbay-vectis.com
Vision technologique
Le 24 Novembre 2003
Schéma Directeur des Espaces numériques de
TravailGroupe de Travail Interopérabilité
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
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 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 l’IDL 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
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 d’autres 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
SDET – Groupe de travail interopérabilité – 24 Novembre 2003
POST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-type: text/xml; charset="utf-8"Content-length: nnnnSOAPAction: "Some URI"
<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some URI">
<symbole>DIS</symbole></m:GetLastTradePrice>
</SOAP-ENV:Body></SOAP-ENV:Envelope>
REQUETE
SOAP - Un exemple
HTTP/1.1 200 OKContent-type: text/xml; charset="utf-8"Content-length: nnnn
<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some URI">
<Price>34.5</Price></m:GetLastTradePriceResponse>
</SOAP-ENV:Body></SOAP-ENV:Envelope>
REPONSE
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 l’appel 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 d’analyse 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 externeDéfinition interne
L’approche par document validé par un schéma combine :grand degrés de liberté, qualité des contrôles et interopérabilité
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 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)
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 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 d’invoquer le service Le fichier WSDL peut être exporté dans un annuaire UDDI permettant ainsi qu’il
soit découvert par interrogation de cet annuaire
8
SDET – Groupe de travail interopérabilité – 24 Novembre 2003
UDDI
UDDI (Universal Description, Discovery, and Integration) distingue trois types de registres :
Pages VertesPages 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 l’utilisation de taxinomies standards
i
Rechercher
Comment on peut trouver un service Web particulier
OpConnecter
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
SDET – Groupe de travail interopérabilité – 24 Novembre 2003
Les compléments du socle de base
Transport & communication
SOAP
WS-Routing WS-Referral
WS-Encrypt
Transport
Routage
Securité
ComposantsXLink
WSDL
Registres &annuaires
UDDI
WS-Inspection
Processus, orchestrations & transactions
XMLDsig XML Encrypt
XKMS
XPDL WSFL WSCI
XAML BTP WSTx
BPML BPSSXLANG
Présentation XUP
WSIF
WSIA WSUI
Orchestrations
Processus
Transactions
XML Schema
BPEL
4WS
XAML
Maturité décroissante
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 d’invocation de Web Services
WSUI (Web Service User Interface) – Epicentric Langage de définition d’interfaces utilisateurs aux Web Services
XUP (Extensible User Interface Protocol) - W3C Protocole permettant de délivrer les événements d’interfaces
utilisateurs pour traitement par des Web Services
WSIA (Web Services for Interactive Application) – OASIS Modèle de composant d’interface basé sur XML et les Web Services
JSR 168 - JCP Normalisation de la notion de Portlet
Portal Portlet
Portlet
Proxy
Application Portal
Application
JSR 168 JSR 168
JSR 168 JSR 168
JAVA
JAVA
Contenu agrégé au format HTML, WML, VoiceXML...
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 168 + WSRP ) ( 03/11/2003 )
WS-I ( Web Services Interoperability org. ) – IBM, Microsoft 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 )
Les initiatives
Contenu agrégé au format HTML, WML, VoiceXML...
Portal Web Service
Web Service
Web Service
Application
Fragments de présentationTransmis via SOAP
WSRPWSRP
WSRP
WSRP
ANY ANY
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 d’expertise
L’objectif de la Java Specification Request 168 est de définir un ensemble d’API et de déclarations relatifs à:
L’agrégation d’informations 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
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 d’une page composite unique.
Porta
l page
Portlet 1
Requête
Portlet 2
Portlet N
N Sources d’informations
PageMes achats
Portlet 1
NewsPortlet 2
Conteneur de portlets•Gestion du cycle de vie des portlets•Gestion de la persistance
14
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 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 d’extension
La spécification définit certains fonctionnements des zones: Les état minimum d’une 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
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 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,…)Proche WSRP
16
SDET – Groupe de travail interopérabilité – 24 Novembre 2003
JSR 168 – Portlet ?
<Contenu>
<titre>
<Contenu>
<titre>
<Contenu>
<titre>
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
SDET – Groupe de travail interopérabilité – 24 Novembre 2003
JSR 168 – Interface Portlet
Diagramme de séquence issu de Portlet specification 1.0
L’interface Portlet contient les méthodes permettant de gérer le cycle de vie d’une portlet: Init() processAction() render() destroy()
L’API contient une implémentation de base GenericPortlet.
Il y a une seule instance de Portlet par conteneur.
18
SDET – Groupe de travail interopérabilité – 24 Novembre 2003
WSRP – Contexte WSRP est une initiative de l’OASIS
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
S’appuie sur le travail déjà réalisé : Portails et Portlets OASIS WSIA Technical Comitee ( Web Services for Interactive
Application )
Avec pour objectifs : L’alignement sur les standards existants L’interopérabilité au delà du monde Java ( Microsoft .NET, Open Source ) Un intégration la plus « plug & play » possible Faire de l’Internet une place de marché de Web Services WSRP
19
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, VoiceXML…
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
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 connexionCapacitésExigences Négociation
Recherche / Accès au service
Authentification
CapacitésExigences
Page ( personnalisée )
Demande page ( Action )
Appel service ( action )ActionChange état
Authentification
OK
Utilisateur
Consommateur
Producteur
ActionChange état
ActionChange état
Terminaison Terminaison
Méta-données
Connexion établie
Accès authentifié Autorisation
Service découvert
Appel service ( présentation )
Page ( présentation )
21
SDET – Groupe de travail interopérabilité – 24 Novembre 2003
WSRP – Cas d’utilisations
Portal
WSRP Service
WSRP Service
WSRP Service
Application(e.g. Word, Outlook, ...)
WSRP Service
WSRP Service
WSRP Service
ServerPortalWSRP
InterfacePortals
Portlet
Portlet
Portlet
Portail Service WSRP
Portail Portail
Application Portail
22
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 L’architecture « Bus » décentralisée, mise en œuvre par l’ESB
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
23
SDET – Groupe de travail interopérabilité – 24 Novembre 2003
. . .