Services web et processus métier

Les Services Web sont une implémentation concrète de l’architecture SOA (Service Oriented Architecture) [Davi00]. Cette dernière décrit un paradigme dans lequel les logiciels sont perçus comme un ensemble de services dont l’interface expose, d’une manière neutre par rapport aux plateformes logiciels et hardwares, les fonctions qui peuvent être appelées par toutes sortes de clients. Pour atteindre ce but, un langage universel qui permet une interopérabilité parfaite est nécessaire. Ce langage c’est XML [TJCE00]. De plus, nous aurons besoin de l’infrastructure des réseaux TCP/IP [Wiki11] (le type de réseaux les plus rependus) et plus particulièrement le protocole HTTP [Tber96] . Les services web peuvent aussi être perçus comme une évolution naturelle des Middleware des systèmes distribués [Hmah04], depuis les premiers mécanismes RPC (Remote Procedure Call) mono-langages [Sunm88] (principalement C et C++) aux EAI (Enterprise Application Integration) en passant par les Object Brokers [Grou11] et les MOM (Message-oriented middleware). L’adoption massive par le monde académique et industriel des web services fait qu’ils sont aujourd’hui incontournables dans tout système d’information moderne. Cette adoption est renforcée par une standardisation par le consortium WC3 (The World Wide Web Consortium -organisme de standardisation de toutes les technologies internet). WC3 valide (on non), les propositions de ces membres (entité académique ou industrielle) et se propose aussi de définir des « profiles » qui correspondent à des degrés divers d’interopérabilité (exemple le profile WS-I – The OASIS Web Services Interoperability – qui définit le strict minimum que chaque nœud doit avoir pour réussir une conversation web service).

Les technologies des Web Services

Dans la littérature spécialisée, plusieurs taxinomies ont été proposées (par exemple dans [BeMH07]) pour classer les différents aspects que peuvent avoir les services Web. L’une d’elles (celle qui est pertinente à ce travail), consiste à classer leurs propriétés en 2 catégories: Propriétés fonctionnelles et Propriétés non- fonctionnelles.

1. Les propriétés fonctionnelles (PFs) décrivent ce que fait exactement un service (ses fonctionnalités) et comment ces fonctionnalités sont accomplies.

2. Les propriétés non-fonctionnelles (PNFs) décrivent des contraintes sur les propriétés fonctionnelles lors de l’exécution des services. Parmi ces propriétés non-fonctionnelles, nous avons la qualité de services, la privacité (privacy), la confiance, etc…

Les propriétés Fonctionnelles

Dans cette section nous abordons les propriétés fonctionnelles d’un service. Ces dernières font l’objet d’un grand effort d’étude et de standardisation par les communautés académiques et industrielles. Le WC3 définit un service web comme suit: « Un service web est un logiciel identifié par une URI (Uniform Resource Identifier,), dont l’interface est publique et les liaisons sont définies et décrites en utilisant XML. L’environnement du service offre le moyen à d’autres logiciels de découvrir celui-ci. Ce service interagit avec les autres services web en respectant cette définition, donc en utilisant des messages basés sur XML acheminés par des protocoles Internet ». Cette définition ne présuppose ni l’utilisation du protocole SOAP (Simple Object Access Protocol,) [Mitr03] pour assurer le transport et la communication entre les entités, ni une description du service web par le langage de description WSDL (Web Services Description Language,)[EFGS01]. Mais l’architecture de référence d’un service web suppose que ce service possède un niveau d’abstraction dans lequel il est décrit par le langage de description WSDL et qu’il emploi le protocole de communication SOAP. Le protocole UDDI [Wwwo02] ne bénéficie pas aujourd’hui de l’appui des industriels (ni même du monde académique), et ne fait donc pas parti du « noyau de base » des protocoles web service. Malgré cela on le trouve souvent dans la littérature spécialisée associée à SOAP et WSDL, probablement pour des raisons historiques.

Description du modèle fonctionnel des web services
Les services web s’articulent autour du protocole d’échange de données SOAP (lui-même basé sur XML). Ce protocole se situe dans une couche supérieure des protocoles de niveaux applicatifs de l’Internet comme HTTP, FTP, SMTP, etc. Ces derniers encapsulent donc les messages XML issues du protocole SOAP dans leurs propres messages.

Les langages et protocoles utilisés par les services web
La description fonctionnelle précédente montre l’utilisation de nombreux langages et protocoles durant le déploiement et l’invocation du service web. Ce sont ces principaux langages et protocoles que nous allons décrire maintenant :

Le Protocole SOAP
Les communications entre les différentes entités impliquées dans le dialogue avec le service web se font par l’intermédiaire du protocole SOAP (Simple Object Access Protocol). Ce protocole est normalisé par le W3C.Le protocole SOAP est une surcouche de la couche application du modèle OSI des réseaux. Le protocole applicatif le plus utilisé pour transmettre les messages SOAP est HTTP, mais il est également possible d’utiliser les protocoles SMTP ou FTP ; la norme n’impose pas de choix. Le choix de l’utilisation de protocoles applicatifs, comme par exemple HTTP, est lié aux problèmes d’interconnexion connus des réseaux : le but des web services étant d’être réutilisables, après publication, à travers tout le réseau Internet, il faut alors leurs donner les moyens de passer les protections telles que les firewalls. Ces derniers autorisent généralement sans aucune restriction le trafic sur les ports liés aux protocoles tels que http (port 80), permettant ainsi le passage sans problème à travers les différents réseaux des messages générés par l’utilisation du protocole SOAP.

Dans un souci d’interopérabilité, et donc dans la continuité des différents langages et protocoles issus des web services, les messages échangés lors de l’utilisation du protocole SOAP sont basés sur le métalangage XML. Ces messages comportent plusieurs parties  que nous allons décrire et sont donc encapsulés dans des protocoles de niveau applicatif.

L’en-tête du protocole de transport :
Cette partie dépend du protocole de transport utilisé. Par exemple, si le protocole HTTP est utilisé, cet entête contient :

– la version de HTTP utilisée,
– la date de génération de la page (qui est ici le message SOAP lui-même),
– le type d’encodage du contenu (ici, l’encodage est généralement le type text/xml), etc.

Les messages SOAP (l’enveloppe) : La partie principale d’un message SOAP est l’enveloppe (symbolisée par la balise ). Cette enveloppe (SOAP Envelope) est-elle même, subdivisée en deux sous-parties : la partie en-tête et la partie corps du message. Elle permet également de spécifier des environnements de noms XML utilisés dans la suite du message.

L’entête du message SOAP : L’entête SOAP (SOAP Header) est optionnel et extensible. Les balises XML permettant de symboliser cette partie sont et </env:Header>. Ces balises peuvent être complétées par des attributs permettant de définir le domaine de noms du service web .