Objectifs de WSIF
WSIF a pour objectif d'augmenter la flexibilité des services SOAP pour créer un modèle général d'appel de services Web, qui ne tient pas compte des protocoles de liaison ou d'accès sous-jacents.
Les liaisons SOAP pour les services Web font partie de la spécification WSDL (Web Services Description Language). C'est pourquoi lorsque la plupart des développeurs pensent à utiliser un service Web, ils pensent immédiatement à assembler un message SOAP et à l'envoyer via le réseau au noeud final de service à l'aide d'une API client SOAP. Par exemple, à l'aide d'Apache SOAP, le client crée et charge un objet Call qui encapsule le noeud final de service, l'identification de l'opération SOAP à appeler, les paramètres à envoyer, etc.
- Les services Web ne sont pas de simples services SOAP.
- Associer le code du client à une implémentation de protocole particulière.
- De la difficulté d'incorporer de nouvelles liaisons dans le code client.
- Utilisation de liaisons multiples selon différentes méthodes.
- Un environnement de services Web plus libre autorise la présence d'intermédiaires.
Les objectifs de WSIF (Web Services Invocation Framework) sont donc :
- d'offrir un mécanisme indépendant de toute liaison pour l'appel des services Web,
- de libérer le code du client de la complexité d'un protocole particulier utilisé pour accéder à un service Web,
- d'autoriser la sélection dynamique d'une liaison particulière parmi plusieurs liaisons menant à un service Web,
- d'aider au développement d'intermédiaires de services Web.
Les services Web ne sont pas de simples services SOAP
Vous pouvez déployer en tant que service Web n'importe quelle application dotée d'une description WSDL de ses aspects fonctionnels et de ses protocoles d'accès. Si vous utilisez l'environnement Java™ EE (Java Platform, Enterprise Edition) alors l'application est disponible via plusieurs transports et protocoles.
Par exemple, vous pouvez avoir une procédure stockée dans une base de données, l'exposer sous forme de bean session sans état, puis la déployer dans un routeur SOAP en tant que service SOAP. A chaque stade, le service fondamental reste le même. Seul le mécanisme d'accès change : il passe de JDBC (Java DataBase Connectivity) au protocole RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) puis à SOAP.
La spécification WSDL définit une liaison SOAP pour les services Web, mais vous pouvez ajouter des extensions de liaison au fichier WSDL pour que, par exemple, vous puissiez fournir un bean enterprise comme service Web qui utilise RMI-IIOP comme protocole d'accès. Vous pouvez même traiter une seule classe Java comme service Web avec des appels de méthode Java dans des unités d'exécution comme protocole d'accès. Avec cette définition plus large d'un service Web, l'appel nécessite un mécanisme indépendant de toute liaison.
Associer le code du client à une implémentation de protocole particulière
Si le code de votre client est étroitement couplé à une bibliothèque spécifique d'une implémentation de protocole particulière, sa maintenance peut s'avérer difficile.
Par exemple, si vous passez de la version Apache de SOAP à JMS (Java Message Service) ou un bean enterprise, le processus peut prendre un temps considérable et nécessiter beaucoup d'efforts. La solution passe donc par l'adoption d'un mécanisme d'appel des services indépendant de toute implémentation de protocole.
De la difficulté d'incorporer de nouvelles liaisons dans le code client
Pour qu'une application qui utilise un protocole personnalisé fonctionne comme un service Web, vous pouvez ajouter des éléments d'extensibilité à WSDL pour définir les nouvelles liaisons. Notez toutefois qu'atteindre ce niveau de fonctionnalité est complexe.
Par exemple, vous devez concevoir les API client de telle sorte qu'elles utilisent ce protocole. Si votre application utilise uniquement l'interface abstraite du service Web, vous devez créer des outils pour générer les raccords autorisant une couche d'abstraction. Ces différentes tâches peuvent nécessiter beaucoup de temps et de travail de développement. Vous avez besoin d'un mécanisme d'appel de service permettant la mise à jour de liaisons existantes et l'ajout de nouvelles liaisons.
Utilisation de liaisons multiples selon différentes méthodes
Pour tirer parti des services Web offrant plusieurs liaisons, un mécanisme d'appel des services est nécessaire, qui peut passer d'une liaison de service disponible à l'autre au moment de l'exécution, sans avoir à générer ou recompiler un raccord (stub).
Imaginons que vous ayez réussi à déployer une application qui utilise un service Web offrant plusieurs liaisons. Par exemple, vous disposez d'une liaison SOAP pour le service et d'une liaison Java locale qui permet de traiter l'implémentation du service local (une classe Java) comme un service Web.
La liaison Java locale du service ne peut être utilisée par un client que si ce dernier est déployé dans le même environnement que le service. Dans ce cas, il est plus efficace de communiquer avec le service en effectuant des appels Java directs au lieu d'utiliser la liaison SOAP.
Si vos clients peuvent librement basculer d'une liaison à une autre en fonction des informations disponibles au moment de l'exécution, ils peuvent aussi choisir le type de liaison le mieux adapté à chaque situation.
Un environnement de services Web plus libre autorise la présence d'intermédiaires
Les services Web offrent aux intégrateurs d'applications un paradigme "découplé". Dans de tels environnements, les intermédiaires peuvent être très puissants.
Les intermédiaires sont des applications qui interceptent les messages qui circulent entre un demandeur de service et un service Web cible et effectuent certaines tâches de médiation (par exemple, journalisation, haute disponibilité ou transformation) avant de transmettre le message. WSIF (Web Services Invocation Framework) est conçu pour faciliter la mise en place d'intermédiaires. A l'aide de WSIF, les intermédiaires peuvent ajouter de la valeur à l'appel de service sans besoin de programmation spécifique au transport.