LES WEB SERVICES
Les Web Services représentent l'implémentation
la plus utilisée pour appliquer l'architecture SOA. Le concept de Web
Service regroupe un ensemble de technologies basées sur XML, permettant
de créer des composants logiciels distribués, de décrire
leurs interfaces et de les utiliser en mettant en oeuvre des standards tels que
SOAP, XSD, WSDL et UDDI. Les Web Services respectent donc des protocoles et des
normes informatiques utilisés pour échanger des données
entre les applications : ils ont été définis, pour la plus
grande part, par le W3C (World Wide Web Consortium), qui a été
fondé pour promouvoir la compatibilité des technologies du Web et
émet des recommandations à valeur de standards industriels.
Un Web Service peut, dans un exemple simple, laisser un client
communiquer avec lui en utilisant des messages XML qui répondent au
standard SOAP (Simple Object ou Service Oriented Architecture Protocol). Il
représente donc le format d'échange de données dont les
protocoles primaires sont HTTP et HTTPS. On y trouve un en-tête et un
corps. Dans l'en-tête, on peut faire référence à un
fichier XSD (XML Schema Definition), permettant de définir les types des
différentes données échangées. Dans le corps, les
données indiquant la méthode utilisée et les bons
paramètres sont présents. Prenons un Web service donnant, pour un
identifiant client particulier et un identifiant produit, le prix du produit
désiré. Un message SOAP contenant les bonnes informations et un
champ prix vide pourra être envoyé au service. En retour, sera
renvoyé le message avec le prix du produit renseigné.
Un fichier WSDL (Web Services Description Language)
décrit un web service : c'est la fameuse interface évoquée
précédemment dans la description d'un service. Pour faire un
rapprochement, on peut voir ce fichier comme une interface en langage JAVA : on
connaît les méthodes mais par leur implémentation. Elle
contient aussi d'autres informations comme le fichier XSD (si jamais il y a des
types complexes) mais surtout les informations permettant d'accéder au
service (protocole, port et "EndPoint" - l'endroit où se trouve le
service).
Un registre UDDI Universal Decription Discovery and
Integration) est un annuaire basé sur XML qui permet de publier des
services et facilite leur découverte par d'autres services en
définissant comment ils interagissent. Un scénario d'utilisation
possible est donc la publication d'un fournisseur de service (donc de son WSDL)
auprès d'un registre en créant tout d'abord une entreprise et une
catégorie de service. Un client demande ensuite à un registre
UDDI la localisation d'un service qui correspond au service venant d'être
ajouté à l'annuaire. Le WSDL du service demandé est alors
reçu par le client qui peut communiquer avec le fournisseur de services
en SOAP.
1 - Service fournit le WSDL
2 - Le Client veut un service et reçoit son WSDL
3 - Le Client peut communiquer avec le service
Schéma volontairement simplifié au niveau du
middleware qui, ici, offre la possibilité d'accéder à un
registre UDDI..
Derrière l'acronyme BPEL (Business Process Execution
Language), se cache la notion d'orchestration qui est de plus en plus
utilisée et qui, comme son nom l'indique, fait jouer les web services
comme un chef d'orchestre. Cette couche, permettant de gérer le lien
entre plusieurs services, pourrait offrir, par exemple, de mélanger un
service d'envoi de SMS, un service donnant la température et un service
donnant des conseils pour s'habiller selon la température. BPEL appelle
un premier service pour connaître la température cet
après-midi, utilise ce résultat pour interroger le service
indiquant comment s'habiller et envoie la réponse avec le service
envoyant des SMS. Un client, faisant appel à un BPEL, pourrait savoir
qu'il doit emporter un pull car il va faire froid en fin de journée.
Derrière cet exemple très simple, on comprend
que BPEL est lui-même un web service : il possède son propre
WSDL. Mais son WSDL est particulier car il contient des informations
supplémentaires : entre autres, les WSDL des services qu'il va
invoquer pendant son exécution.
SOA est une théorie et on ne doit pas oublier que l'on
peut faire une architecture SOA sans Web Services et inversement car,
réaliser des web services, ne veut pas dire mettre en place une
architecture SOA. « Une façon de concevoir et
d'implémenter les applications de l'entreprise qui possèdent un
couplage faible, sont à grandes mailles et sont des services
réutilisables, accessibles par des interfaces bien définies et
indépendantes de toute plateforme. »
Cette définition n'inclut donc pas de protocole de
communication obligatoire et il n'y a aucune restriction évoquée
: pas d'obligation d'envoyer des messages SOAP en HTTP. SOA est beaucoup plus
que seulement des Web Services et sa vraie force intervient réellement
quand il n'y a plus ces restrictions et autorise les services à
être invoqués par une multitude de protocoles. L'ESB permet
justement de mettre en oeuvre un environnement ne se limitant pas aux limites
évoquées.
| 
