2. Composants
• Time to market
• Améliorer la productivité
• Réduire la complexité
• Réutiliser si possible
• Assemblage plutôt que programmation
• Réduire les besoins en compétences
spécialisées
• Recentrage sur l’expertise du domaine
• Améliorer la qualité du logiciel
3. Web Services (1)
• Opération : action invocable
• Interface : partition des opérations
• Service : ensemble des interfaces utilisables pour une autre
application coopérative
Service Web
• Service invocable à travers le réseau
• Non basé sur le contenu (pages web)
• Délivre des données structurées à une
application
Profiter des standards du moment
4. Web Services (2)
• Utilisation pour l'intégration
• Dans un portail
• Applications d'entreprise
• B2B
Portail
Normalisation
d'adresse
traduction
Achat
vente
météo
traducteur
commande
B Processus
Service
météo
Intranet
Internet
5. Web Services (3)
SGBD procédures cataloguées
Adaptateur progiciels
Systèmes orientés Messages,
courtiers d'Intégration
Serveur d'applications
Orchestration de Flux
7. Plan
• SOAP
• Protocole de transmission de
messages XML
• WSDL
• Web Services Description Language
• UDDI
• Universal Description Discovery and
Integration
• Web Services
• Intégration avec l'existant
8. SOAP
• SOAP 1.1
• Un moyen de faire communiquer des
applications par RPC en utilisant HTTP
• Proposé à W3C en 2000 par UserLand, Ariba,
Commerce One, Compaq, Developmentor,
HP, IBM, IONA, Lotus, Microsoft etSAP
• SOAP 1.2
• travaux W3C
• Protocole de transmission de messages en
XML
9. SOAP ?
• SOAP protocole XML permettant la communication entre
composants logiciels et applications en s’appuyant sur des
protocoles standards de type http, smtp, …
• SOAP Simple Object Access Protocol
• SOAP Service Oriented Architecture Protocol
• SOAP est un protocole de transmission de messages
• SOAP est adapté à la communication entre applications
• SOAP est un format d’échange de messages
• SOAP est conçu pour fonctionner sur l’Internet
• SOAP est indépendant des plates-formes et des langages
• SOAP est basé sur XML
• SOAP est simple et extensible
• SOAP en voie de standardisation par W3C
10. OK, et CORBA alors? (1)
• CORBA prend aussi en compte tous ces points
• mais exige de compiler et distribuer des
stubs clients pour chaque type de clients
• pas toujours pratique pour un grand nombre
de combinaisons de plates-formes et de
langages ou lors de fourniture de services à
des clients anonymes au travers d’Internet
11. OK, et CORBA alors? (2)
• String-ware ?
• SOAP est un protocole basé sur XML
• En conséquence, particulièrement prolixe
• CORBA, au travers de IIOP, le battra en
performance car les opérations de
conversion et de déconversion
(marshalling et demarshalling) dans CORBA
sont plus efficaces et il y a moins de
données sur le réseau.
• Néanmoins les messages en xml sont
lisibles et utilisables : utile pour la mise au
point
12. SOAP Scenarii (1)
Envoi et oublie, avec
un ou n récepteurs
Noeud SOAP
émetteur
initial
Requête réponse, requête
avec acquittement ou RPC
sur un protocole de
transport assurant la
corrélation
Noeud SOAP
ultime
récepteur
Appli SOAP Appli SOAP
processeur
SOAP
processeur
SOAP
Niveau SOAP
Niveau
protocole de
transport
Hôte 1 Hôte 2
13. SOAP Scenarii (2)
Noeud SOAP
émetteur
initial
Appli SOAP
A Id
message
processeur
SOAP
Niveau SOAP
Niveau protocole de
transport
Corrélation de
Noeud SOAP
ultime
récepteur
Appli SOAP
B Id
message
processeur
SOAP
Noeud SOAP
émetteur
initial
Appli SOAP
B Id
message
processeur
SOAP
messages
Hôte 1 Hôte 2
Noeud SOAP
ultime
récepteur
Appli SOAP
A Id
message
processeur
SOAP
Hôte 2 Hôte 1
Requête réponse,
requête avec
acquittement ou RPC
sur un protocole de
transport n'assurant
la corrélation
14. SOAP Scenarii (3)
Noeud SOAP
émetteur
initial
Appli SOAP
A
routage
processeur
SOAP
Niveau protocole de
transport
Noeud SOAP
intermédiaire
Appli SOAP
B
routage
processeur
SOAP
Noeud SOAP
ultime
récepteur
Appli SOAP
A
routage
processeur
SOAP
Hôte 1 Hôte 2
Hôte 3
Niveau SOAP
Changement de
protocole possible
Requête réponse, requête avec
acquittement ou RPC via de
multiples intermédiaires
15. SOAP Scenarii (4)
• Requêtes avec cryptage du contenu ou de l'en-tête
• Echange avec tierce partie
• Conversation
• Messages asynchrones
• Multiples réponse asynchrones
• Echange de données Non-XML
• Notification d'événements
• Cache, cache avec expiration
• Qualité de service
• Echange avec analyse et traitement incrémental
• Routage, tracking
• Grilles
• Et autres, en fonction de l'imagination des architectes
16. SOAP message
• Un message SOAP valide est un document XML
au bon format. Le message doit avoir la forme
suivante:
• Une déclaration XML (optionnelle)
• Une Enveloppe SOAP (l'élément racine) qui
est composée de:
• Une En-tête SOAP (optionnel : infos nécessaires à
l'interprétation du message)
• Un Corps SOAP (données du message)
• Une section d’erreur SOAP
17. SOAP message
• Règles de syntaxe:
• un message SOAP MUST être codé en XML
• un message SOAP MUST avoir une enveloppe SOAP
• un message SOAP CAN avoir un entête SOAP (header)
• un message SOAP MUST avoir un corps SOAP (body)
• un message SOAP MUST utiliser l'espace de désignation de
l'enveloppe SOAP
• un message SOAP MUST utiliser l'espace de désignation d'encodage
SOAP
• un message SOAP MUST NOT contenir une référence à une DTD
• un message SOAP MUST NOT contenir des instruction de type XML
Processing
18. SOAP Exemple
• <Envelope> est la racine
• <Header>, <Body> et <Fault> sont les enfants :
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding
/">
<soap:Header>
... Header information...
</soap:Header>
<soap:Body>
... Body information...
<soap:Fault> ...Fault information...
</soap:Fault>
</soap:Body>
</soap:Envelope>
19. SOAP Enveloppe
•<SOAP-ENV:Envelope ... >le style d'encodage
de ce message SOAP suit le schéma défini dans
http://schemas.xmlsoap.org/soap/encoding
•Contient les définitions de namespaces.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/ 2001 /XMLSchema">
</SOAP-ENV:Envelope>
20. SOAP Entête (1)
• Mécanisme pour étendre un message de façon
décentralisée et modulaire, sans connaissance
a priori des parties de la communication.
• Typiquement authentification, transaction, …
• Règles :
• Identifié par un namespace et un nom local
• Les enfants immédiats qualifiés par le namespace.
21. SOAP Entête (2)
• 2 attributs particuliers utilisés pour indiquer
comment et par qui l’entrée est traitée
• mustUnderstand : Indiquer qu’une entrée est
obligatoire
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI" SOAP-ENV:
mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header>
• Actor : Indiquer qui peut utiliser l'entête ; par
défaut : l’ultime
<SOAP-ENV:Header>
<m:local
xmlns:m =’’http://www.w3edfRetD.edu/local/’’
soap:actor= http://www.w3edfRetD.edu/appli >
<m:language> dk </m:language>
</m:local>
</soap:Header>
22. Soap Body
• Mécanisme simple pour échanger les
informations avec l’ultime receveur du
message.
• Typiquement appels marshalling RPC calls et
des rapports d’erreur
• Une entrée du body est identifiée par un
namesapce et un nom local
<SOAP-ENV:Body>
<ns1:doubleAnIntegerResponse
xmlns:ns1="urn:MesSoapServices"
SOAP-ENV:
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:int">30</return>
</ns1:doubleAnIntegerResponse>
</SOAP-ENV:Body>
23. SOAP section d’erreur
• Utilisée pour porter les erreurs ou les statuts d’erreur d’un
message
• Doit apparaître comme une entrée du body
• Ne doit pas apparaître plus d’une fois
• Sous éléments :
• faultcode
• Identifier l’erreur
• faultstring
• Explication de l’erreur
<env:Body>
<env:Fault>
<faultcode><value>env:VersionMismatch</value>
</faultcode>
<faultstring>Version Mismatch</faultstring>
</env:Fault>
</env:Body>
24. SOAP encodage de graphes
• L’information est traitée comme un graphe
constitué de noeuds intermédiaires ou
terminaux et de liens entre ces noeuds.
• Il existe des règles d’encodage de ces graphes
• Valeurs simples
• XML schema Built-in datatypes et dérivés
• Ou SOAP-ENC pour des éléments
indépendants d’un type hétérogène
• Valeurs composites
• Tableaux et structures
31. SOAP Array
• Définis par le type "SOAP-ENC:Array"
ou dérivé
• Représentés comme des éléments de
valeur sans contrainte sur le nom du
contenu
<element name="mesResultats"
type="SOAP-ENC:Array"/>
< mesResultats
SOAP-ENC:arrayType="xsd:int[2]">
<number>3</number>
<number>4</number>
</ mesResultats >
32. SOAP sur HTTP
• Message SOAP dans le corps HTTP
• En-tête HTTP 'soapAction'
POST http://www.w3edfRetD.fr http/1.1
Content-type:text/xml ; charset="utf-8"
SOAPAction: http://www.w3edfRetD.fr#service
<SOAP-ENV:Envelope
….
</SOAP-ENV:Enveloppe>
35. SOAP Principes RPC (1)
• Processus Client avec binding http
Construction
de l'appel de
méthode
Sérialise en
requête
SOAP-XML
Enveloppe la
requête
SOAP-XML
En requête
http
Requête
http
envoyée au
serveur
SOAP
Réponse
http reçue
du serveur
SOAP
Extrait la
réponse
SOAP-XML
de la réponse
http
Désérialise
la réponse
SOAP-XML
En réponse
de méthode
Retourne la
valeur
Package soap
Serializer/des
erializer
Encoding/de
coding http
36. SOAP Principes RPC (2)
• Processus Serveur avec binding http
Requête http
du client
SOAP
envoie
requête
décodeur
Décode la
requête http et
dé-sérialise la
requête SOAP-XML
Opération
du Service
sérialise la
réponse SOAP-XML
et encode
de la réponse
http
Envoie la
réponse
Retourne la
réponse http
au client
SOAP
Package soap
Servlet
SOAP
Encoding/de
coding http
et soap
Canal de
requête du
servlet
Canal de
réponse du
servlet
Invoque la
méthode
envoie
réponse
décodeur
37. SOAP Exemple (1)
• Service de normalisation d'adresses
• Capable de fournir une adresse postale normalisée à
partir d'informations de localisation
• Utilise des types de données complexes en entrée et en
sortie
NormAdresse getNorme( Local adresse_local)
Service NormalisationAdresse
getNorme
Application
Interface Implantation opération
Public et
standard
Privé et
propriétaire
wsdl
SOAP
XML
38. SOAP Exemple (2) : Serveur-Déploiement
Le WSDL associé
<Definitions> Racine et namespace
<Types> Quels types de données dont échangés
<Message> Quels messages sont transmis
<Port type>Quelles opérations sont supportées
<Binding> Comment les messages sont transmis sur la connexion
<service> Où est situé le service
A voir plus tard en détail
39. SOAP Exemple (3) : Serveur-Code
• Classe DoNorme
• Méthode getNorme : retourne une adresse
normalisée
• Local et NormAdresse : Bean
• Accesseurs (get_) et mutateurs (set_) pour chaque
attribut
• Afin d'utiliser un BeanSerializer
• Servlet d'initialisation de contexte
40. SOAP Exemple (4) : Client-Code
• Mapping des types
// Build the call.
Service service = new Service();
Call call = (Call) service.createCall();
// Map the types.
QName qn1 = new QName( "urn:NormAdresse", "Local" );
call.registerTypeMapping(Local.class, qn1,
new org.apache.axis.encoding.ser.BeanSerializerFactory(Local.class, qn1),
new org.apache.axis.encoding.ser.BeanDeserializerFactory(Local.class, qn1));
QName qn2 = new QName( "urn:NormAdresse", "NormAdresse" );
call.registerTypeMapping(NormAdresse.class, qn2,
new org.apache.axis.encoding.ser.BeanSerializerFactory(NormAdresse.class,
qn2),
new org.apache.axis.encoding.ser.BeanDeserializerFactory(NormAdresse.class,
qn2));
Serialiser la classe
Local
41. SOAP Exemple (5) : Client-Code
• Construire l'appel
call.setTargetEndpointAddress( new java.net.URL(endpointURL) );
call.setOperationName( new QName("NormAdresseService", "getNorme") );
call.addParameter( "AdresseDuLocal", qn1, ParameterMode.IN );
call.setReturnType(qn2,NormAdresse.class); //Build the params
le_local.setloc_no_voie(" 9 BIS");
le_local.setloc_l_voie1("Chemin de la Sablière ");
le_local.setloc_l_voie2("BP 12");
le_local.setloc_c_postal(" 91430");
le_local.setloc_l_bd(" Igny");
Object resp resp = call.invoke( new Object[] { le_local } );
Méthode
On aurait pu
directement
construire le XML
dans un
SOAPBodyElement[]
et le passer au call
42. SOAP Exemple (6) : Client-Code
• Exploiter le résultat
//
if (resp instanceof java.rmi.RemoteException)
{
throw(java.rmi.RemoteException) resp;
}
else
try {
NormAdresse value = (NormAdresse)resp;
if ( value != null )
{
System.out.println("retour :");
System.out.println("code"+value.getAdr_c_postal());
…
}
} catch(java.lang.Exception e) { …}
43. WSDL
Web Services Description Language
Vocabulaire XML, similaire dans le principe à IDL
• Il contient des informations opérationnelles concernant le service :
• L'interface du service
• Les détails d'implantation
• Les protocoles d'accès
• Les points d'activation (contact endpoints)
WSDL : convergence de deux langages
IBM's NASSL
Microsoft's SDL
44. WSDL
<definitions> : Définition du service. Racine de tout WSDL. Elle peut
contenir les attributs précisant le nom du service, et les espaces de
nommage. Il contient trois types d’éléments :
<message> et <portType> : Définissent les opérations offertes par
Le service. Un <message> correspond à un paramètre d’entrée ou de sortie
d’une <operation>. Un <portType> définit un ensemble d’opérations. Une
<operation> possède un nom et des paramètres d'E/S.
<binding> : Associe les <portType> à un protocole particulier. Par exemple
SOAP.
<service> : Précise les informations nécessaires à l'invocation d'un service, en
particulier l’URI du destinataire. Un <service> est une collection de <port> ;ie
d’associations de <binding> et d'URI.
Les types de données complexes peuvent être précisés dans une balise
<types> placée juste avant la balise <message>.
Chaque élément WSDL peut être documenté grâce à une balise
<documentation>.
45. WSDL : exemple (1)
L’exemple suivant est la description du service Echo précédemment défini :
<wsdl:definitions
targetNamespace="http://cli20ir:9595/axis/services/NormAdresseService/axis/se
rvices/NormAdresseService" xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://cli20ir:9595/axis/services/NormAdresseService/axis/services
/NormAdresseService-impl"
xmlns:intf="http://cli20ir:9595/axis/services/NormAdresseService/axis/services/
NormAdresseService"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns1="urn:NormAdresse"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/">
La première
partie du
fichier
définit les
espaces de
nommage
46. WSDL : exemple(2)
<wsdl:types>
<schematargetNamespace="urn:NormAdresse"
xmlns="http://www.w3.org/2001/XMLSchema">
<complexTypename="Local">
<sequence>
<element name="loc_no"nillable="true"type="xsd:string"/>
<element name="cli_ic_orig"nillable="true"type="xsd:string"/>
…
</sequence>
</complexType>
<element name="Local"nillable="true"type="tns1:Local"/>
</schema>
</wsdl:types>
On trouve ensuite les
types particuliers
utilisés
47. WSDL : exemple (3)
<wsdl:message name="getNormeResponse">
<wsdl:part name="return"type="tns1:NormAdresse" />
</wsdl:message>
<wsdl:message name="getNormeRequest">
<wsdl:part name="adresse_local"type="tns1:Local"/>
</wsdl:message>
<wsdl:portTypename="DoNorme">
<wsdl:operationname="getNorme"parameterOrder="adresse_local">
<wsdl:input message="intf:getNormeRequest"name="getNormeRequest"
/> <wsdl:output
message="intf:getNormeResponse"name="getNormeResponse" />
</wsdl:operation>
</wsdl:portType>
Puis les
paramètres
d’entrée et de
sortie des
opérations du
service
La définition abstraite du service Web est
faite par définition du
portType, indépendante de tout protocole
de communication. C’est l’interface du
service définissant les méthodes
exportées, et leurs paramètres d’entrée et
de sortie.
48. WSDL : exemple (4)
<wsdl:binding
name="NormAdresseServiceSoapBinding"type="intf:DoNorme">
<wsdlsoap:binding
style="rpc"transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operationname="getNorme">
<wsdlsoap:operation soapAction="" />
<wsdl:input name="getNormeRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespa
ce="http://cli20ir:9595/axis/services/NormAdresseService/axis/service
s/NormAdresseService"use="encoded" />
</wsdl:input>
<wsdl:outputname="getNormeResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespa
ce="http://cli20ir:9595/axis/services/NormAdresseService/axis/service
s/NormAdresseService"use="encoded" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
Ce service est associé à un protocole existant, via un binding
. Il définit les paramètres d’invocation du service spécifiques
au protocole. Les paramètres nécessaires à l’utilisation (lien
vers les spécifications du transport utilisé, règles d’encodage
pour les messages échangés, …).
49. WSDL : exemple (5)
<wsdl:service name="DoNormeService">
<wsdl:port binding="intf:NormAdresseServiceSoapBinding"
name="NormAdresseService">
<wsdlsoap:address location=http://cli20ir:9595/axis/services/NormAdresseService
/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
La définition du service se termine par la définition de
plusieurs bindings, associés à plusieurs URL, et ce en
utilisant la même définition abstraite du service.
50. WSDL
• WSDL créé automatiquement à partir de Java
avec Java2WSDL
• Utilisation
• Construire un proxy pour une utilisation
directe à partir du client ou d'un autre Service
avec WSDL2J
DoNorme binding = new
DoNormeServiceLocator().getNormAdresseService();
NormAdresse value = binding.getNorme(le_local);
•Exploiter dynamiquement le WSDL avec
WSDL4J
•Pour une invocation dynamique ou bien pour
automatiser l'enregistrement et la publication
dans un annuaire
51. UDDI
Universal Description, Discovery and Integration
Une spécification pour la description et la découverte de WebServices
• Les Businesses enregistrent des
informations publiques les
concernant
• Les développeurs, éditeurs de
logiciels, organismes de
standardisation enregistrent des
types de services techniques
White pages (informations générales)
Yellow pages (catégories de services)
Green pages (business rules)
White
Pages
Yellow
Pages
Green
Pages
52. UDDI
Pages blanches : noms, adresses, contacts, identifiants,… des entreprises
enregistrées. Ces informations sont décrites dans des entités de type Business
Entity. Cette description inclut des informations de catégorisation permettant de
faire des recherches spécifiques dépendant du métier de l’entreprise ;
Pages jaunes : détails sur le métier de l’entreprise, les services qu’elle propose. Ces
informations sont décrites dans des entités de type Business Service ;
Pages vertes : informations techniques sur les services proposés. Les pages vertes
incluent des références vers les spécifications des services Web, et les détails
nécessaires à l’utilisation de ces services. Ces informations sont décrites dans deux
documents : un Binding Template, et un Technology Model (tModel).
58. UDDI
• Enregistrer séparément les descriptions des
Compagnies et les descriptions des services
• Développeurs, éditeurs de logiciels, organismes
de standardisation enregistrent des types de
services
• Les Compagnies enregistrent les services
qu'elles supportent
59. UDDI
• UDDI4J simplifie l'interaction avec un annuaire
UDDI
• Pour l'enregistrement et la découverte
• Utilisation de l'objet UDDIProxy
UDDIProxy p = new UDDIProxy();
p. setInquiryURL( “ http:// …” );
p. setPublishURL( “https:// …” );
62. UDDI
Client
Noeud
annuaire
UDDI
Requête
UDDI SOAP
Réponse
UDDI SOAP
Serveur
HTTP
Serveur
SOAP
Annuaire
UDDI
Noeud WS
WSDL
WebService
UDDI4J
Utilisation UDDI
URI="http://…"
Communication
avec le WS
63. UDDI : exemple (1)
• Retrouver une BusinessEntity, un des services
qu'elle propose
• Invoquer ce service
Dans la pratique on
rechercherait plutôt par
catégorie
Retrouver la BusinessEntity
Vector names = new Vector();
names.add(new Name("EDF-RetD"));
BusinessList businessList = proxy.find_business(names, null, null,null,null,null,10);
Vector businessInfoVector = businessList.getBusinessInfos().getBusinessInfoVector();
BusinessInfo businessInfo = null;
….
Boucle dans businessInfoVector pour vérifier que c'est le bon
BusinessEntity
Vector serviceInfoVector = businessInfo.getServiceInfos().getServiceInfoVector();
…
Boucle dans serviceInfoVector pour retrouver le serviceInfo
64. UDDI : exemple (2)
Retrouver les détails pour le service référencé par les différentes
clés
ServiceDetail serviceDetail = proxy.get_serviceDetail(serviceInfo.getServiceKey());
Vector businessServices = serviceDetail.getBusinessServiceVector();
Boucle dans businessServices pour retrouver le Service
BusinessService businessService = null;
On peut aussi faire
for (int i = 0; i < businessServices.size(); i++) {
un find_service
businessService = (BusinessService)businessServices.elementAt(i);
if (serviceName.equals(businessService.getDefaultNameString())) {…}
Maintenant,il faut retrouver l'Overview URL du tModel :
Grâce au businessServices, retrouver le bindingTemplates puis le
point d'accès basé sur http
Vector bindingTemplateVector =
businessService.getBindingTemplates().getBindingTemplateVector();
AccessPoint accessPoint = null;
BindingTemplate bindingTemplate = null;
65. UDDI : exemple (3)
Boucle dans bindingTemplateVector pour retrouver le
bindingTemplate corrrespondant
if (accessPoint.getURLType().equals("http")) …
Il faut enfin retrouver le tModel associé
Vector tmodelInstanceInfoVector =
bindingTemplate.getTModelInstanceDetails().getTModelInstanceInfoVector();
String wsdlImplURI = null;
Boucle dans tmodelInstanceInfoVector pour retrouver
l'OverviewURL corrrespondant
TModelInstanceInfo instanceInfo =
(TModelInstanceInfo)tmodelInstanceInfoVector.elementAt(i);
InstanceDetails details = instanceInfo.getInstanceDetails();
OverviewDoc wsdlImpl = details.getOverviewDoc();
wsdlImplURI = wsdlImpl.getOverviewURLString();
66. UDDI : exemple (4) avec WSDL
Il est alors possible d'invoquer
dynamiquement le service en utilisation l'api
WSDL4J
Il faut en particulier analyser le WSDL et extraire
Le target namespace
Le nom du service
Le nom du port le nom de l'opération ainsi que ces
paramètres
67. UDDI
• En pratique les clés de classification et d'identification
devraient être gérées et fournies par des agences
mondiales
• Les informations du niveau "yellow pages" de UDDI sont
typiquement fondées sur deux standards :
• NAICS (the North American Industry Classification System)
• projet des gouvernements du Canada, du Mexique et des US.
• http:// www.naics.com
• UNSPSC (the Universal Standard Products and Services
Classification).
• Efforts conjoints de Dun & Bradstreet et du programme de
développement des nations unies pour une unification des
classifications
• http://www.unspsc.org
68. UDDI
• Application directe
• La recherche du document WSDL associé au
service est facilitée par une référence spécifique
de nom "uddi-org:types" et de valeur "wsdlSpec"
Lors de l'enregistrement cette clé est définie de la
manière suivante :
KeyedReference kr = new KeyedReference("uddi-org:types","wsdlSpec","");
69. UDDI
• Type d'annuaire utile pour la découverte de
BusinessEntity ou de BusinessService
• Identification et catégorisation
• Encore peu implanté
• Nécessité d'un modérateur
• Mise en oeuvre relativement complexe
• On lui préfère une approche plus pragmatique
• WSIL
• Fournit une liste simple des services
disponibles
70. WSIL
• WebService Inspection Language
• Une méthode de découverte de services décentralisée
• Considère que l'on connaît déjà le fournisseur de
services, donc pas de notion de businessEntity
• WSIL représente une entité spécifique, ses services, ses
contacts et est fourni directement par celui qui le
représente
• Un fichier WSIL références tous les documents qui
décrivent les services de l'entreprise, y compris UDDI
WSIL
XML
UDDI
WSDL
HTML
71. WSIL : exemple
<?xml version="1.0" encoding="UTF-8"?>
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/">
<abstract>The EDF-RetD W Service Search API</abstract>
<service>
<abstract>NormAdresse Search</abstract>
<description
referencedNamespace="http://schemas.xmlsoap.org/wsdl/"
location="http://www.edf-RetD.fr/NormAdresse.wsdl"/>
<description
referencedNamespace ="http://www.w3c.org/html/"
location ="http://www. edf-RetD.fr
/1999/NormAdresse_Deployment.html" />
<description
referencedNamespace ="http://www.uddi.org/"
location ="http://www. edf-RetD.fr /soapuddi/" />
</service>
</inspection>
Une fois le fichier créé, on peut le placer sous
http://www.EDF-RetD.fr/WS/inspection.wsil
72. Web Services et l'existant
• Une nouvelle technologie pour le middleware
• Curiosité, méfiance
Vraiment différent de J2EE ou
CORBA ?
• Que gagne-t-on ?
• Que perd-on ?
• Comment gérer la transition ?
73. Description des services
• Spécification CORBA
• Langage de description des interfaces (OMG IDL)
+ règles de projection vers des langages de
programmation
• Langage de description des implantations : OMG
CIDL + règles de génération de guides
d’implantation.
• Structure des messages échangés déduite de la
description des interfaces (explicite en WSDL).
• Choix du protocole d’échange et de l’encodage des
messages lié à l’ORB (explicite en WSDL).
• Localisation des services déterminée au déploiement
(explicite en WSDL).
Orientation service de WSDL
74. Description : Coexistence
• Spécification en cours à l’OMG
• RFP « CORBA to WSDL/SOAP interworking »
• Réponse commune de Cape Clear, Fujitsu, HP, IONA,
Sankhya avec le support d’IBM
• J2EE 1.4 conteneur de service
Serveur d'applications
Port (représentation du web service)
Service endpoint
interface
Wsdl :portType
Service instance
Wsdl :service
Usine à stubs
Service interface
Ejb ou JAX-RPC web
component
Cycle de vie de la
responsabilité su
serveur d'applications
Wsdl :portType,
transport et
encoding binding
Wsdl:portadress
75. Localisation
• Spécification CORBA
• Référence CORBA – chaîne de caractère ou URL
• Annuaire de services (Naming Service)
• Registre d'interfaces et d'implantation(Interface and
Implementation Repository)
• Courtier (Trading Service)
• J2EE : JNDI
client courtier serveur
1 - import 2 - export
• Passerelle vers des répertoires d’entreprises
• Et JNDI SPI vers Corba
• Répertoire centralisé des objets J2EE
• Fabrique d’objets « Home »
• Variables et ressources partagées
ORB
3 - interaction
76. Localisation : WebService
• UDDI
• Universal Description, Discovery and Integration
• Le référentiel UDDI vu comme un annuaire
• pages blanches (informations de contact)
• pages jaunes (classification par catégories)
• pages vertes (informations techniques sur le service)
• WSIL
• WebService Inspection Language
• Une méthode de découverte de services décentralisée
Découverte de service
77. Localisation
• Annuaire et découverte de service commun aux
WebServices et aux architectures CORBA, J2EE
• Qualité de service pas dans UDDI mais peut
être associée à ebXML
79. Communication
• CORBA - IIOP
• Invocation d'opération ou One-way
• Relocalisation,
• Multiplexage client-serveur
• Abandon de requête
• SOAP
• one way
• Reconstruction de protocole
• Multiples intermédiaires
• Attachements SOAP permettent de véhiculer
des contenus MIME avec un message SOAP
80. Coexistence : CORBA - WS
• Exposer des composants CORBA sous forme de Web Services
• Web Services vus comme des composants CORBA
• Adaptation des environnements CORBA.
Conteneur d’applications Web
Référentiel
UDDI
Client
SOAP
Systèmes CORBA
Description
WSDL
Serveur
SOAP
Client
CORBA
Serveur Web
81. Coexistence : J2EE - WS
• J2EE 1.4
• API pour SOAP, WSDL, UDDI
• SOAP Messaging
• JAXM, SAAJ, JAX-RPC, JMS
• WSDL
• Java API for WSDL
• JAX-RPC
• UDDI
• JAXR
82. Coexistence : J2EE - WS
Conteneur de
servlet
Conteneur Ejb
Port Port
servlet jsp ejb
RMI/IIOP
RMI/IIOP
HTTP/SSL
SOAP/HTTP et
autres bindings
Noyau J2EE Noyau J2EE
83. Coexistence : J2EE - WS
• Paquetage pour déploiement
• Pour Web Component : fichier WAR
• Pour stateless session bean : fichier EJB JAR
• Descripteur de déploiement : webservices.xml
• Différents de celui associé à l'implantation du
service : web.xml ou ejb-jar.xml
• Déploiement
• Génération des classes d'aide : servlet, stub,
proxy,… pour le client (placement du service
implementation accessible par JNDI)
• Génération, mise à jour et publication du WSDL
84. Coexistence : J2EE - WS
• Développement sur J2EE
• WSDL de/vers Web service Endpoint Interface
(java)
• Endpoint Interface spécifiée dans JAX-RPC
• Utile pour servlet-based et EJB-based
endpoint
• Pour le cas EJB déclaration dans le
descripteur de déploiement du endpoint
• Implantation en classe Java (servlet) ou
Stateless session bean
• Création de descripteur de déploiement
• webservices.xml
85. Conclusion
• WS : De nombreuses caractéritiques en commun avec
les environnements répartis J2EE, CORBA, Net.
Réinventer la roue ?
• Principales différences
• Positionnement ?
• WS : middleware de middleware
• fonctionnement en mode déconnecté (connexions
transitoires et temporaires)
• pas de connaissance a-priori des parties qui entrent en
communication (accès aux informations sur le service)
86. Atouts
• Intégrer au niveau service
• Contrat métier
• Contrat technique
• Orchestration
• Intermédiation
Gagner en abstraction
87. Produits
• “HP WS” de HP
• eSpeak, HP-AS, HP-WS
• “E2A” de IONA
• E2A WS Interoperation, Application Server
• “Cape” de CapeClear
• CapeConnect, CapeStudio
• “.Net” de Microsoft
• .Net environment, .Net framework, .Net Visual Studio
• “Sun One Net” de Sun
• iPlanet, Sun One Studio
• “WebSphere” de IBM
• WebSphere, WebSphere Studio
• “WebLogic” de BEA
• WebLogic Server, Integration, Portal, Studio
• “Oracle 9i” de Oracle
• Oracle 9iAS
Des outils existent
88. Perspectives
• Perspectives
• Maturité WS : encore du travail
• Gestion de la sécurité (Microsoft, IBM, Verisign : WS-Security)
et des transactions (Microsoft, IBM, BEA :
WS-Transaction).
• Définition de modèles d’interaction (chorégraphie) et
de collaboration (processus métiers, recherche de
partenaires).
• Périmètre WS : des interrogations
• Persistance, gestion de l'état, …
Maturité et périmètre
89. WebServices : le futur ! (1)
• SOAP Recommandations W3C , version 1.2
• Points à voir
• La gestion des sessions
• L'asynchronisme
• …
• Des protocoles au dessus de SOAP
• Pour des sémantiques d'échanges
particulières
• SOAP : one way
• Basés sur la définition de patrons d'échanges
90. WebServices : le futur ! (2)
• WSDL Recommandations W3C , version 1.2
• On trouve encore plusieurs styles de
génération de WSDL ce qui complique
l'interopérabilité
• UDDI Recommandations UDDI.org, version 3.0
• Trouver la vitesse de croisière
• Le démarrage est difficile
• Mise en oeuvre assez complexe
• Pas de modérateur
IBM,
MicroSoft,HP,
Oracle, SAP,…
• WSIL version 1.0 une solution intéressante
91. WebServices : le futur ! (3)
• Stabilisation des autres niveaux de la pile de
protocole pour les WebServices
• En particulier l'orchestration ou encore la
chorégraphie des services
• dérouler des processus plus complexes que l’appel
d’opérations atomiques, avec plusieurs acteurs. Couvert
par la spécification BPEL4WS
• Notion d'intermédiaire entre acteurs de
différentes compagnies
