L'infrastructure WSIF (Web Services Invocation Framework) fournit une API Java™ qui permet
d'appeler des services Web indépendamment de leur format et du protocole de transport à travers lequel ils sont joignables.
Avant de commencer
WSIF inclut un fournisseur EJB pour l'appel d'EJB via le protocole RMI-IIOP (Remote Method
Invocation over Internet Inter-ORB). Toutefois, dans le cas d'un appel de service Web basé sur EJB(IIOP),
appelez les services Web RMI-IIOP à l'aide de JAX-RPC.
Veillez à ce que votre application
n'utilise qu'une seule unité d'exécution (thread) pour appeler WSIF.
Pourquoi et quand exécuter cette tâche
L'API WSIF prend en charge l'appel de services Web définis dans WSDL (Web Services Description Language). WSIF est conçu pour être utilisé dans les clients WSIF et dans les intermédiaires de service
Web.
L'API WSIF s'appuie sur la description abstraite de services en WSDL ; elle
est complètement indépendante de la liaison utilisée. Cette indépendance rend l'utilisation de l'API plus naturelle car elle utilise des
termes WSDL pour faire référence aux parties de message, aux opérations et à d'autres éléments.
L'API WSIF a été conçu pour le modèle de syntaxe WSDL :
- Sélectionnez un port qui prend en charge le type de port nécessaire.
- Appelez l'opération en fournissant le message d'entrée abstrait nécessaire,
composé des parties requises, sans vous soucier de la manière dont ce message est mappé
vers un protocole de liaison spécifique.
D'autres API de services Web, par exemple les API SOAP, ne reposent pas sur
WSDL mais sur un protocole de liaison spécifique avec sa syntaxe associée, par exemple,
les URI cible et les styles de codage.
Les interfaces WSIF API principales sont décrites dans la procédure suivante.
Remarque : Apache ne prend plus en charge WSIF.
- Créer un message à envoyer à un port via l'interface WSIFMessage.
En WSDL, un message décrit le type abstrait de l'entrée ou de la sortie
d'une opération. La classe WSIF correspondante est WSIFMessage, qui représente en mémoire
l'entrée ou la sortie d'une opération. L'interface WSIFMessage sépare la représentation des données du type abstrait défini par WSDL.
Une classe WSIFMessage est un conteneur
dans lequel est placé un ensemble de parties nommées. Les classes WSIFMessage peuvent être envoyées entre les différentes machines virtuellesJava
(JVM).
- Indiquez si vous souhaitez représenter le message WSIF lors de son exécution en tant que
classe Java ou
en tant que XML.
Il existe deux moyens naturels de représenter un message WSDL dans un environnement d'exécution :
- la classe Java générée, basée sur un mappage de WSDL vers Java,
tel que celui fourni par JAX-RPC (Java API for XML-based remote procedure
call).
- la représentation XML des données, par exemple en utilisant le codage SOAP.
Chaque option a ses avantages dans différentes situations. La classe Java est
l'approche naturelle lorsque WSIF est utilisé dans un client Java standard.
Toutefois, dans d'autres cas de figure où WSIF
est utilisé dans un intermédiaire, il peut être plus efficace de maintenir un message WSDL
au format d'encodage SOAP. Le style utilisé pour définir les messages doit être cohérent. Ainsi, toutes les parties
d'un même message doivent être cohérentes. Une chaîne -
getRepresentationStyle() -
renvoie toujours
null.
Cela indique que les parties de la classe WSIFMessage
concernée sont représentées en tant qu'objets Java.
- Obtenez et définissez les parties du message WSIF.
Vous pouvez ajouter des parties à une classe WSIFMessage à l'aide des méthodes setObjectPart ou setTypePart. Chaque partie est nommée. Les noms de partie dans un message sont uniques.
Si
vous définissez une partie plus d'une fois, le dernier paramètre est celui utilisé.
Vous extrayez les parties en fonction du nom à partir d'une classe WSIFMessage à l'aide des méthodes getObjectPart ou getTypePart.
Si la partie nommée n'existe pas, la méthode renvoie une erreur WSIFException.
Vous pouvez utiliser des itérateurs afin d'extraire des parties du message à l'aide des méthodes
getParts() et getPartNames().
Si vous pouvez définir les parties dans n'importe quel ordre, l'implémentation du message peut être plus efficace si les parties sont définies dans le même ordre que celui des paramètres défini par WSDL.
Les classes WSIFMessage peuvent être clonées et sérialisées.
Si les parties définies ne peuvent être clonées,
l'implémentation peut tenter de les cloner en utilisant la sérialisation. Si les parties ne sont
pas sérialisables, une exception CloneNotSupportedException est lancée en cas de tentative
de clonage.
- Définissez le nom du message WSIF.
Outre les parties de message, une classe WSIFMessage possède aussi un nom de message.
Il est requis pour la surcharge des opérations, prise en charge par WSDL et WSIF.
Pour plus d'informations sur l'interface WSIFMessage (/wsi/org/apache/wsif/WSIFMessage.html), voir la documentation fournie avec WSIF.
- Recherchez une fabrique de port ou de service via l'interface WSIFService
et la classe WSIFServiceFactory.
L'interface WSIFService
est une fabrique de port qui modélise et supporte l'approche WSDL dans laquelle un service
est disponible sur un ou plusieurs ports. Cette fabrique masque l'implémentation du
port. WSIF prend en charge les ports dynamiques basés sur un protocole et transport particuliers,
et configurés à l'aide de WSDL lors de l'exécution. Par exemple, le port SOAP dynamique
peut appeler n'importe quel service SOAP basé sur la description WSDL de ce
service. Vous pouvez ainsi masquer et modifier l'ensemble de ports disponibles lors de l'exécution.
Pour trouver un service à partir d'un document WSDL à une adresse web précise ou à partir d'une base de code générée par code, vous utilisez la classe WSIFServiceFactory.
- Appeler une opération via l'interface WSIFPort et l'interface WSIFOperation
interface.
Une interface WSIFPort prend en charge les détails de l'appel d'une opération. Le port fournit l'accès à l'implémentation du service.
Un document WSDL peut fournir de nombreuses liaisons WSDL et ces liaisons
peuvent commander plusieurs ports. Le client peut choisir un port, le raccord de
service peut choisir un port, WSIF peut aussi choisir un port par défaut.
Le port offre une interface destinée à l'obtention d'un objet
opération. Une interface WSIFOperation offre la possibilité d'exécuter l'opération donnée.
Si le port est sérialisé et désérialisé plus tard, WSIF veille à ce que le client fournisse les informations correctes au serveur pour
identifier l'instance. Si l'instance de serveur concernée n'est plus disponible, il revient au serveur de décider s'il doit émettre une
erreur ou fournir une nouvelle instance. Ce comportement peut dépendre du type de service. Par exemple, pour un bean enterprise, l'interface
WSIFPort stocke l'interface home d'EJB et l'utilise pour sélectionner le bean avant chaque appel. Le client est responsable de la
sérialisation ou de la maintenance de l'instance de port si une prise en charge d'instance est nécessaire.
Le client doit créer une opération et des messages pour
chaque appel.