1 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Les Web Services Thierry...

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


Agenda

Le socle technologique de base

SOAP WSDL UDDI

Les initiatives

Les perspectives

JSR 168 WSRP ESB

3


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


. . .

1 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Les Web Services Thierry...

Documents

Transcript of 1 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Les Web Services Thierry...