Configuration de la portée d'un port de service Web à l'aide de l'outil de scriptage wsadmin

Lorsqu'une application de services Web est déployée sur WebSphere Application Server, une instance est créée pour chaque application ou module. L'instance contient des informations de déploiement pour le module Web ou bean enterprise, ainsi que des informations relatives à la portée de l'implémentation, aux liaisons client et au descripteur de déploiement. On distingue trois niveaux de portée : application, session et requête (ou demande).

Avant de commencer

Si vous n'avez pas encore déployé le fichier EAR (d'archive d'entreprise), vous devez le préparer ou le déployer sur le serveur d'applications.

Pourquoi et quand exécuter cette tâche

Cette tâche a pour but d'activer la configuration de la portée du port d'un service Web. La portée définie à l'origine lorsque l'objet JavaBeans a été activé au cours du processus de développement en tant que service Web peut être modifiée à l'aide de la commande WebServicesServerBindPort. L'attribut de portée ne s'applique pas aux services Web qui utilisent le transport JMS (Java Message Service) ni aux beans enterprise.

La spécification Web Services for Java 2 Enterprise Edition (J2EE) indique que les implémentations de services Web doivent être sans état (stateless). Par conséquent, pour maintenir la conformité à la spécification, la portée peut rester au niveau application, car l'état relatif aux sessions ou demandes individuelles n'est pas supposé être conservé dans l'implémentation. Si vous souhaitez déroger à la spécification et permettre l'accès à une autre instance JavaBeans (afin d'obtenir des informations situées dans un autre JavaBeans), vous devez modifier le paramètre de portée.

Le réglage choisi pour la portée détermine la fréquence à laquelle une nouvelle instance de la classe d'implémentation d'un service est créée pour les ports du service Web dans un module. Si vous choisissez la portée de niveau application, la même instance de l'implémentation sera utilisée pour toutes les demandes adressées à l'application. Si vous optez pour la portée de niveau session, la même instance sera utilisée pour toutes les demandes d'une session particulière. Enfin, la portée de niveau demande entraîne l'utilisation d'une nouvelle instance pour chaque demande. Par exemple, si la portée choisie est application, tous les messages parvenant au serveur accèdent à la même instance de bean Java.

Pour modifier la portée à l'aide de l'outil wsadmin :

Procédure

  1. Lancez une commande de script. Pour plus d'informations, voir Démarrage du client de script wsadmin.
  2. Configurez la portée d'un port de service Web.

    Pour utiliser le port d'écoute existant au lieu d'utiliser ou de créer une spécification d'activation, déterminez si la version JAR d'EJB est inférieure à 2.1. Le système crée et utilise automatiquement une spécification d'activation que vous spécifiez à l'aide de l'option -usedefaultbindings pour déployer une application. Si une spécification d'activation existe, le système ignore le port d'écoute, mais utilise la spécification d'activation. Pour déployer une application avec une version JAR d'EJB supérieure ou égale à 2.1 utilisant les ports d'écoute définis au lieu d'une nouvelle spécification d'activation, attribuez la valeur true à la propriété système com.ibm.websphere.management.application.dfltbndng.mdb.preferexisting dans le fichier wsadmin.properties figurant dans le répertoire des propriétés du profil concerné.

    Utilisez les options install, installInteractive, edit ou editInteractive pour configurer la portée d'un port de service Web, comme la syntaxe suivante le décrit :

    $AdminApp install app_name {-usedefaultbindings -deployejb 
    -WebServicesServerBindPort {{<module_name> <Web_service> <port><scope_setting>}...}
    L'exemple suivant indique que la portée de plusieurs ports peuvent être modifiée à l'aide de la commande WebServicesServerBindPort, où :
    • nom_app est le nom de l'application (par exemple, WebServicesSample.ear).
    • nom_module est le nom du module (par exemple, AddressBookW2JE.jar).
    • service_Web est le nom du service Web (par exemple, AddressBookW2JE service/WSLoggerService2).
    • port est le nom du port (par exemple, AddressBook).
    • valeur_portée est le niveau de la portée (par exemple, Session).

Résultats

La portée d'un port de service Web est configurée.

Exemple

L'exemple suivant inclut l'application, le module, le service Web, le port et la portée tels qu'ils figurent dans la ligne de commande :
$AdminApp install WebServicesSamples.ear {-usedefaultbindings -deployejb -deployws 
-WebServicesServerBindPort {{AddressBookJ2WB.war AddressBookService AddressBook request} 
{AddressBookW2JB.war AddressBookService AddressBook application}}}

Que faire ensuite

Vous pouvez maintenant terminer les autres configurations, démarrer ou redémarrer l'application, puis vérifier le comportement attendu du service Web.

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=txml_scopewsadmin
Nom du fichier : txml_scopewsadmin.html