Vous pouvez utiliser le protocole de transport SOAP over JMS (Java™ Message Service) comme alternative au
protocole SOAP over HTTP pour la communication de messages SOAP entre
les clients et les serveurs.
Pourquoi et quand exécuter cette tâche
Ce produit prend en charge le protocole de norme industrielle émergent SOAP sur JMS.
La spécification SOAP
sur JMS fournit un ensemble standard d'instructions de mise en oeuvre pour l'utilisation d'un transport compatible JMS avec des messages SOAP pour activer l'interopérabilité entre les implémentations de différents fournisseurs. Cette norme permet l'interopération d'un ensemble de composants
client et serveur de différents fournisseurs lors de l'échange de messages de demande et
de réponse SOAP via le transport JMS pour les services Web JAX-WS (Java API
for XML Web Services) et JAX-RPC (Java API for XML-based RPC). L'utilisation de JMS permet à vos clients et serveurs de services Web basés sur les beans entreprise de
communiquer au moyen de files d'attente et de sujets JMS au
lieu de passer par des connexions HTTP.
Fonction obsolète: Dans les versions antérieures du serveur d'applications, un protocole SOAP/JMS propriétaire IBM®
était pris en charge pour des applications Java API for XML-based RPC (JAX-RPC). Dans WebSphere
Application Server 7.0 ou version ultérieure, ce protocole SOAP/JMS propriétaire est abandonné en faveur d'un protocole
SOAP/JMS standard. Vous pouvez utiliser le protocole propriétaire d'IBM
SOAP sur JMS avec JAX-WS (Java API for XML Web Services) ou
JAX-RPC mais il est recommandé d'utiliser le nouveau protocole SOAP
sur JMS standard. Si votre
application client appelle des services Web basés sur des beans enterprise pris en charge
par une version précédente de WebSphere Application Server, vous devez continuer
à utiliser le protocole SOAP/JMS propriétaire IBM
pour accéder à ces services Web. depfeat
L'utilisation du transport JMS présente les avantages suivants :
- Fiabilité du transport des messages pour la communication des messages de demande et de réponse.
- Souplesse du mode asynchrone pour les demandes unidirectionnelles
entre clients et serveurs. Par exemple, le serveur n'a pas besoin d'être actif lorsque le client envoie la demande unidirectionnelle. Des demandes unidirectionnelles peuvent être envoyées à plusieurs
serveurs simultanément via l'utilisation d'une rubrique.
- Les réponses bi-directionnelles synchrones sont prises en charge pour les clients JAX-WS (Java API for XML-Based Web Services) et JAX-RPC (Java API for XML-based RPC).
- Les demandes asynchrones sont prises en charge pour les clients JAX-WS.
La spécification SOAP sur JMS définit une syntaxe URI de noeud final JMS pour la spécification des destinations JMS.
Une URL de noeud final JMS est utilisée pour accéder aux services Web JAX-WS ou JAX-RPC à l'aide du transport JMS. Cette URL spécifie la fabrique de connexions et de destinations JMS, ainsi que le nom du composant de port pour la demande de services Web. Elle est similaire à l'URL de noeud final HTTP qui spécifie l'hôte et le port, ainsi que la racine de contexte et le nom du composant de port.
- Développez le bean enterprise que vous avez l'intention d'utiliser comme bean d'implémentation de services.
- Pour les applications JAX-WS, ajoutez l'annotation @BindingType à votre classe d'implémentation de noeud final et indiquez l'ID de liaison SOAP sur JMS pour votre noeud final. Par
exemple :
@WebService
@BindingType("http://www.w3.org/2010/soapjms/")
public class MyServiceBeanImpl {
...
}
L'annotation @BindingType permet d'indiquer le protocole (SOAP) et le transport (JMS) à utiliser lors de l'envoi de messages de demande et de réponse pour le noeud final.
- Assemblez les beans enterprise.
- Assemblez un
fichier JAR qui est activé pour des services Web à partir d'un bean
enterprise. Vous pouvez assembler les artefacts nécessaires à l'activation du module de beans enterprise
pour les services Web dans un fichier JAR (Java archive).
- Assemblez un fichier
JAR de beans enterprise activé pour des services Web en un fichier
EAR. Vous pouvez assembler les artefacts requis pour activer le fichier
JAR activé par services Web dans un fichier EAR.
- Activez les noeuds finaux basés sur les beans enterprise à l'aide de la commande endptEnabler. Utilisez l'option -transport jms pour demander à la commande endptEnabler de
créer un programme d'écoute MDB (message-driven bean) pour chaque fichier JAR d'EJB (Enterprise JavaBeans)
contenant les beans d'implémentation des services Web. Ce bean géré par message sert de programme d'écoute pour les demandes qui sont associées aux noeuds finaux de services Web contenus dans le fichier JAR d'EJB.
- Choisissez le nom et le type des objets JMS utilisés par votre application.
Avant d'installer votre application, procédez comme suit :
- Déterminez si le service Web reçoit les demandes d'une file d'attente ou d'un sujet.
- Choisissez d'utiliser une destination sécurisée ou une destination non sécurisée.
- Choisissez le nom de vos files d'attente et sujets, de la fabrique de la spécification d'écoute.
Utilisez les instructions suivantes pour choisir le nom et le type des objets JMS. En général, vous pouvez utiliser une file d'attente pour recevoir des demandes de services Web.
- File d'attente
- Une file d'attente reçoit tous les types de demandes. Les demandes valides comprennent les demandes unidirectionnelles, bidirectionnelles et synchrones. Les demandes asynchrones sont uniquement valides avec les services Web JAX-WS.
- Une file d'attente est uniquement utilisée par un seul fichier JAR EJB afin de recevoir les demandes des noeuds finaux de services Web contenus dans ce fichier JAR d'EJB.
- Rubrique
- Une rubrique est utilisée pour recevoir uniquement les
demandes
unidirectionnelles.
- Vous pouvez partager une rubrique entre plusieurs fichiers JAR
d'EJB. Chaque message de demande qui est envoyé à une rubrique est
traité par chacun des programmes d'écoute du MDB qui sont configurés
pour écouter cette rubrique. Cela signifie que chaque message de
demande est traité par chaque fichier JAR d'EJB associé à cette
rubrique spécifique.
L'exemple suivant décrit la configuration standard d'un seul fichier JAR d'EJB contenant des noeuds finaux de services Web :
- Supposons que le fichier JAR EJB s'appelle StockQuoteEJB.jar et qu'il contienne un
ou plusieurs noeuds finaux de services Web associés au service StockQuote.
- Vous disposez d'une seule file d'attente, StockQuote_Q, dont le nom JNDI est jms/StockQuote_Q pour recevoir les demandes.
- Vous disposez d'une fabrique de connexions, StockQuote_CF, dont le nom JNDI est jms/StockQuote_CF qui peut être utilisée par les clients pour se connecter au fournisseur JMS.
- Vous disposez également d'une fabrique de connexions, StockQuote_ReplyCF, dont le nom JNDI estjms/StockQuote_ReplyCF et qui permet au programme d'écoute du MDB du fichier JAR d'EJB de se connecter au fournisseur JMS lors de l'envoi des messages de réponse.
- Vous disposez d'une spécification d'activation, StockQuote_AS, dont le nom JNDI est jms/StockQuote_AS,
utilisée pour associer le programme d'écoute MDB du fichier StockQuoteEJB.jar à la file d'attente StockQuote_Q.
- Définissez les objets gérés par JMS.
Une fois les noms et les types des objets JMS choisis, définissez ces objets à
l'aide de la console d'administration ou de l'outil de scriptage wsadmin. Il existe plusieurs façons d'administrer des ressources JMS selon le type de fournisseur JMS utilisé. Pour plus de détails sur l'administration des ressources JMS, voir la rubrique sur la sélection d'un fournisseur de messagerie.
- Déployez l'application de services Web
Au cours du processus d'installation, vous êtes invité à préciser deux types
d'informations pour chaque fichier JAR de bean enterprise activé pour des
services Web et contenu dans votre fichier EAR :
- Le nom JNDI de la fabrique de connexions qui est utilisé par le programme d'écoute du MDB pour
envoyer les messages de réponse.
Si votre service Web
contient des opérations bidirectionnelles, le programme d'écoute du MDB défini par la commandeendptEnabler doit accéder à une fabrique de connexions de file d'attente afin d'ajouter un message de réponse à la file d'attente des réponses. Le programme d'écoute du MDB utilise la référence d'environnement de ressources java:comp/env/jms/WebServicesReplyQCF.
De ce fait, au cours du processus d'installation de l'application, vous devez fournir le
nom JNDI réel de la fabrique de connexions pour que le programme d'écoute du MDB utilise ce service Web. Dans l'exemple précédent, le nom JNDI est jms/StockQuote_ReplyCF.
- Le nom du spécification d'activation à utiliser par le programme d'écoute du MDB.
Un spécification d'activation est un objet utilisé pour associer une fabrique de connexions JMS à une destination JMS (file d'attente ou rubrique). Une fois déployé, un MDB est configuré avec la spécification
d'activation correcte afin que les messages émanant de la file
d'attente ou de la rubrique lui soient correctement distribués. Au cours du déploiement, vous
pouvez modifier le nom de la spécification d'activation associée à chaque programme d'écoute du MDB.
Le nom de la spécification d'activation contenu dans le fichier EAR d'entrée est affiché comme valeur par défaut. Si vous avez indiqué le nom de la spécification d'activation correct dans la commande endptEnabler, vous pouvez accepter la valeur par défaut. Sinon, entrez le nom de spécification d'activation correct.
- Choisissez d'utiliser le protocole SOAP/JMS de la nouvelle norme industrielle
ou le protocole SOAP/JMS propriétaire IBM.
Pratiques recommandées: C'est une meilleure pratique d'utiliser le protocole SOAP/JMS de norme d'industrie. Le protocole SOAP sur JMS propriété d'IBM est devenu obsolète avec cette édition. Cependant,si votre application doit interagir avec des versions
précédentes du produit, utilisez le protocole propriétaire.
bprac
- (Facultatif) Configurez les informations d'URL de noeud final pour les liaisons JMS.
Utilisez la console d'administration pour configurer un préfixe URL de noeud final JMS que vous pouvez associer à chaque module JAR d'EJB de votre application.
Le diffuseur de publication WSDL utilise cette chaîne d'URL partielle pour produire l'URL JMS
réelle pour chaque composant de port défini dans le fichier JAR de bean
enterprise. Les clients qui doivent appeler le service Web peuvent utiliser le fichier WSDL publié.
Effectuez cette étape uniquement si vous publiez le fichier WSDL de votre application.
- (Facultatif) Publiez le fichier WSDL de votre application.
La publication du fichier WSDL génère des documents WSDL qui peuvent être utilisés
pour développer vos applications client. Le processus de publication produit des URL de localisation de noeud final totalement résolues au sein des fichiers WSDL.
Effectuez cette étape uniquement si les fichiers WSDL publiés sont nécessaires pour le développement de vos applications client.
Que faire ensuite
Développement d'un client de services Web.