Web Service et Messages-JMS

Les Web Services
Daniel Hagimont
IRIT/ENSEEIHT
2 rue Charles Camichel - BP 7122
31071 TOULOUSE CEDEX 7
[email protected]
http://hagimont.perso.enseeiht.fr
1
Motivations

Motivations
 Intégration d'applications à "gros grain"
 Unité d'intégration : le "service" (interface + contrat)

Contraintes
 Applications conçues indépendamment, sans avoir prévu une
intégration future
 Applications hétérogènes (modèles, plates-formes, langages)

Conséquences
 Pas de définition d'un modèle commun
 Utilisation d'une base commune de niveau élémentaire
• Pour les protocoles d'accès aux services (messages)
• Pour la description des services (interface)
 Outil de base : XML (car adaptable)
2
Les Web Services (WS)

Apport conceptuel
 Pas de nouveaux concepts fondamentaux …
 … alors, quelle est la nouveauté ?

Apport concret
 Avant tout, solution en vue au problème de
l'hétérogénéité
 Vers un schéma d'intégration et de coordination
d'applications à grande échelle
 Forte implication des principaux acteurs du domaine
3
Forme simple de WS : RPC-XML
Description en XML d'un appel de procédure à distance
Le type des paramètres est spécifié dans le schéma XML
<methodCall>
<methodName>meteo.temperature</methodName>
<params>
<param>
<value><int>31130</int></value>
</param>
</params>
</methodCall>
Description en XML du retour des résultats
<methodResponse>
<params>
<param>
<value><int>25</int></value>
</param>
</params>
</methodResponse>
Intérêt : indépendance par rapport
aux plates-formes et par rapport
au support de communication
4
Mise en œuvre d'un WS
5
Elements des WS

Description d'un service
 WSDL : Web Services Description Language
 Notation standard pour la description de l'interface d'un
service

Accès à un service
 SOAP : Simple Object Access Protocol
 Protocole Internet permettant la communication entre
applications pour l'accès aux services Web

Annuaire des services
 UDDI : Universal Description, Discovery and Integration
 Protocole pour l'enregistrement et la découverte de
services
6
Des outils

A partir d'un programme, on générè un skeleton de WS
 Exemple : à partir d'un programme Java, on génère
• une servlet qui reçoit du SOAP sur HTTP et reproduit l'appel sur une
instance de cette classe
• Un fichier WDSL qui décrit l'interface du service


Le fichier WSDL généré peut être donné aux clients
A partir d'un fichier WSDL, on génère un stub de WS
 Exemple : à partir d'un fichier WSDL, on génère les classes Java
à utiliser pour appeler le service distant


La programmation est simplifiée
On dispose de tels outils dans différents environnements
langages
7
Exemple : programmation de
Web Services



Eclipse JEE
Apache Axis
Création d'un Web Service
 A partir d'une classe Java
 Dans le runtime Tomcat
 Génération du fichier WSDL

Création d'une application cliente
 Génération des stubs à partir du fichier WSDL
 Programmation du client
8
Create a Dynamic Web Project




Eclipse JEE
Open JEE
perspective
Create a
Dynamic Web
Project
Add your
Tomcat
runtime
9
Create a Class
A Tomcat server was
created in Eclipse
10
From source file : Web Service → create Web
Service
11
Copy the generated WSDL file in
a new Java project
A servlet was deployed
on the Tomcat server
12
From the WSDL file
Web Service → Generate Client (Develop
Client)
13
Program a client
14
Run
15
WSDL généré
<wsdl:definitions targetNamespace="http://DefaultNamespace"
xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://DefaultNamespace"
xmlns:intf="http://DefaultNamespace" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.4
Built on Apr 22, 2006 (06:55:48 PDT)-->
<wsdl:types>
<schema elementFormDefault="qualified" targetNamespace="http://DefaultNamespace"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="doIt">
<complexType>
<sequence>
<element name="msg" type="xsd:string"/>
</sequence>
</complexType>
</element>
<element name="doItResponse">
<complexType/>
</element>
</schema>
</wsdl:types>
16
WSDL généré
<wsdl:message name="doItResponse">
<wsdl:part element="impl:doItResponse" name="parameters">
</wsdl:part>
</wsdl:message>
<wsdl:message name="doItRequest">
<wsdl:part element="impl:doIt" name="parameters">
</wsdl:part>
</wsdl:message>
<wsdl:portType name="MyService">
<wsdl:operation name="doIt">
<wsdl:input message="impl:doItRequest" name="doItRequest">
</wsdl:input>
<wsdl:output message="impl:doItResponse" name="doItResponse">
</wsdl:output>
</wsdl:operation>
</wsdl:portType>
17
WSDL généré
<wsdl:binding name="MyServiceSoapBinding" type="impl:MyService">
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="doIt">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="doItRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="doItResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="MyServiceService">
<wsdl:port binding="impl:MyServiceSoapBinding" name="MyService">
<wsdlsoap:address location="http://localhost:8080/HW/services/MyService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
18
Requête SOAP (TCP/IP Monitor)
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<doIt xmlns="http://DefaultNamespace">
<msg>hello</msg>
</doIt>
</soapenv:Body>
</soapenv:Envelope>
19
Réponse SOAP
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<doItResponse xmlns="http://DefaultNamespace"/>
</soapenv:Body>
</soapenv:Envelope>
20
Conclusion



Un RPC sur HTTP
Mais entre langages hétérogènes
Bilan
 XML-RPC est plus simple, mais incomplet
 WS est plus complet et trop complexe (mais soutenu et il
y a des outils)
 UDDI est trop complexe
21
Modèle à messages
Daniel Hagimont
IRIT/ENSEEIHT
2 rue Charles Camichel - BP 7122
31071 TOULOUSE CEDEX 7
[email protected]
http://hagimont.perso.enseeiht.fr
22
Modèle à messages
Introduction

Modèle client-serveur





Appels synchrones
Bon pour des composants fortement couplés
Désignation explicite du destinataire
Connexion 1-1
Modèle à message
 Communications asynchrones
 Désignation anonyme (ex : annonce sur un newsgroup)
 Connexion 1-N
23
Modèle à messages Introduction

Exemple d’application
 Surveillance des équipements d’un réseau
 Évolution des équipements et de l’état des équipements

Solution client-serveur
 Interrogation régulière

Solution messages
 Émission de notifications des changements
 Les administrateurs s’abonnent à ces notifications
24
Intergiciels à messages
… utilisé tous les jours


Les forums
électroniques (News)
 technologie pull
 le consommateur
s ’abonne à un forum
 le producteur publie
une information dans
un forum
 le consommateur va
lire le contenu du
forum quand il le
souhaite



Le courrier électronique
 technologie push
 listes de diffusion (multicast publish/subscribe)
 le consommateur s ’abonne à
une liste de diffusion
 le producteur envoie un
message à tous les abonnées
de la liste
 le consommateur reçoit les
messages sans avoir à faire
d’action
Asynchrone
Anonyme
1-N
25
Intergiciels à messages
Principes directeurs




Message Passing (communication par messages)
Message Queuing (communication par file de
message)
Publish/Subscribe (communication par
abonnements)
Events (communication événementielle)
26
Intergiciels à messages
Message passing

Communication par message
 dans une architecture classique : sockets
 dans un environnement de programmation parallèle : PVM,
MPI
 Dans d'autres environnements : portes (ex : Mach)
27
Intergiciels à messages
Message Queuing

Queue de messages
 persistantes ⇒ asynchronisme et fiabilité
Client
Serveur
send

recv
Indépendance de l'émetteur et du destinataire
 Le destinataire n’est pas forcément actif
28
Intergiciels à messages
Publish/Subscribe

Désignation anonyme
 L’émetteur envoie un message
• Basé sur un sujet (subject-based)
• Basé sur un contenu (content-based)
 Le récepteur s’abonne (à un sujet ou un contenu)

Communication 1-N
 Plusieurs récepteurs peuvent s’abonner
consommateur
producteur
publish
subscribe



recv
29
Intergiciels à messages
Events


Concepts de base : événements, réactions (traitements associés à
l’occurrence d’un événement)
Principe d’attachement : association dynamique entre un type
d’événement et une réaction
consommateur
producteur
publish
subscribe




react
Valable pour du Message Passing, du Message Queuing, ou du
Publish/Subscribe
30
Intergiciels à messages
Implantations
client
client
client
client
client
serveur
Serveur
client
client
serveur
client
serveur
serveur
client
Serveur centralisé
Serveur réparti
(Hub & spoke)
client
serveur
(Snow flake)
client
serveur
Bus logiciel
client
serveur
31
Java Message Service

JMS : API Java d'accès uniforme aux systèmes de
messagerie
 IBM, Oracle,
 Novell, Sybase, Tibco
 Message Queue
 Publish/Subscribe
 Evénements
32
JMS : une interface
(portabilité, pas hétérogénéité)
Client
Client
Client
JMS
Provider X
JMS
Client
Client
JVM
MQ X
Provider Y
JVM
MQ X
MQ Y
MQ Y
Interopérabilité : AMQP (Advanced Message Queuing Protocol)
33
Interface JMS







ConnectionFactory : objet pour créer une connexion avec
un serveur JMS
Connection : une connexion active avec un serveur JMS
Destination : une destination ou une source
Session : un contexte mono-thread pour émettre ou
recevoir
MessageProducer : un objet pour émettre dans une session
MessageConsummer : un objet pour recevoir dans une
session
Les implantations dépendent des fournisseurs …
34
JMS - Architecture
JNDI
Destination
JMS Client
ConnectionFactory
Connection
+
+
MessageProducer
MessageConsumer
Session
35
Interfaces PTP et P/S
Point-To-Point
Publish/Subscribe
ConnectionFactory
QueueConnectionFactory
TopicConnectionFactory
Connection
QueueConnection
TopicConnection
Destination
Queue
Topic
Session
QueueSession
TopicSession
MessageProducer
QueueSender
TopicPublisher
MessageConsumer
QueueReceiver
TopicSubscriber
36
JMS - initialization
Emetteur
Messaging
ConnectionFactory
Destinataire
Queue || Topic
Connection
Connection
Session
Session
ConnectionFactory connectionFactory =
new ActiveMQConnectionFactory(ActiveMQConnection.DEFAULT_BROKER_URL);
Connection connection = connectionFactory.createConnection();
connection.start();
Session session = connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
Destination destination = session.createQueue("myQueue");
Destination destination = session.createTopic("MyTopic");
37
JMS – producer / consumer
Emetteur
Messaging
ConnectionFactory
Destinataire
Queue || Topic
Connection
Connection
Session
Session
+
Producer
MessageProducer producer =
session.createProducer(destination);
+
Consumer
MessageConsumer consumer =
session.createConsumer(destination);
38
JMS - communication
Emetteur
Messaging
ConnectionFactory
Destinataire
Queue || Topic
Connection
Connection
Session
Session
+
send
Producer
TextMessage msg =
session.createTextMessage("...");
sender.send(msg);
+
receive
Consumer
TextMessage m =
(TextMessage)consumer.receive();
39
JMS - Listener
Emetteur
Messaging
ConnectionFactory
Destinataire
Queue || Topic
Connection
Connection
Session
Session
+
+
Consumer
Producer
Listener
consumer.setMessageListener(listener);
40
JMS - Listener
Emetteur
Messaging
ConnectionFactory
Destinataire
Queue || Topic
Connection
Connection
Session
Session
+
send
+
Producer
Consumer
Listener
onMessage
void onMessage(Message msg) throws JMSException {
// unpack and handle the message
}
41
JMS – les messages

TextMessage (une chaîne de caractères)
String data;
TextMessage message = session.createTextMessage();
message.setText(data);
String data;
data = message.getText();

BytesMessage (tableau de bytes)
byte[] data;
BytesMessage message = session.createByteMessage();
message.writeBytes(data);
byte[] data;
int length;
length = message.readBytes(data);
42
JMS – les messages

MapMessage (une suite de paire nom-valeur)
 une valeur est un type primitif
MapMessage message = session.createMapMessage();
message.setString("Name", "…");
message.setDouble("Value", doubleValue);
message.setLong("Time", longValue);
String name = message.getString("Name");
double value = message.getDouble("Value");
long time = message.getLong("Time");
43
JMS – les messages

StreamMessage (série de valeurs)
 une valeur est un type primitif
 La lecture doit respecter l'ordre de l'écriture
StreamMessage message = session.createStreamMessage();
message.writeString("…");
message.writeDouble(doubleValue);
message.writeLong(longValue);
String name = message.readString();
double value = message.readDouble();
long time = message.readLong();
44
JMS – les messages

ObjectMessage (objet sérialisé)
ObjectMessage message = session.createObjectMessage();
message.setObject(obj);
obj = message.getObject();
45
Conclusions

Communication par messages
 Modèle de programmation simple…
 possédant de nombreuses extensions, variantes, …
• bus logiciel à messages, modèles d’acteurs, plates-formes
à agents, systèmes multi-agents, ...
 très utilisé pour relier entre eux des « outils », existant,
indépendants, …

Attention… la simplicité ne peut être
qu’apparente
 propagation et récupération des erreurs
 outils de développement
46