[AIX Solaris HP-UX Linux Windows][z/OS]

Intelligent Management : stratégies de routage et de service

Deux types de stratégie sont appliqués à une demande : les stratégies de routage et les stratégies de service. Vous pouvez créer des stratégies de routage pour les demandes HTTP et SOAP et des stratégies de service pour les demandes HTTP, IIOP, SOAP, JMS et SIP. De plus, les classes de travail peuvent contenir des règles de classification pour les deux types de stratégie sauf pour le service JMS. Les règles de classification ne sont pas prises en charge pour les classes de travail JMS.

Stratégies de routage valides

Tableau 1. Stratégies de routage
Stratégie de routage Description
permit:nom_application

nom_application est le nom de l'application vers laquelle effectuer le routage avec un spécificateur d'édition facultatif.

permitMM:nom_application

nom_application est le nom de l'application vers laquelle effectuer le routage avec un spécificateur d'édition facultatif. Ce type de routage permet de continuer le traitement de la demande selon la procédure normale. Le serveur doit se trouver en mode maintenance.

permitsticky:nom_application

La stratégie de routage permitsticky est similaire à la stratégie de routage permit, mais le routeur ODR (on demand router) gère également l'affinité client vers serveur pour les demandes futures émanant du même client. Dans ce cas, le routeur ODR ajoute un en-tête SET-COOKIE à la réponse avant d'envoyer la réponse au client.

L'action permitsticky indique que le routeur ODR établit activement une affinité entre le client et le serveur si l'affinité n'a pas encore été établie par l'application. Le routeur ODR effectue cette opération en ajoutant SET-COOKIE: WSJSESSIONID=xx:IDserveur; path=RacineContexteModuleWeb à la réponse si :
  • La réponse n'a pas encore de SET-COOKIE qui doit établir l'affinité de serveur et
  • La demande correspondante n'indique pas que l'affinité de serveur a déjà été établie.
serverID représente l'identificateur du serveur et s'appelle également l'ID de clone. webModuleContextRoot est la racine de contexte du module Web auquel la demande a été mappée.
permitstickyMM:nom_application

Cette stratégie de routage est identique à la stratégie de routage permit, sauf que le routeur ODR gère également l'affinité client vers serveur pour les demandes ultérieures provenant du même client. Dans ce cas, le routeur ODR ajoute un en-tête SET-COOKIE à la réponse avant d'envoyer la réponse au client. Le serveur doit se trouver en mode maintenance.

reject:code_erreur_HTTP

Avec cette stratégie de routage, le routeur ODR rejette des demandes associées au code d'erreur HTTP indiqué. Par exemple, reject:503 renvoie une erreur 503 de service indisponible.

reject:URL

Avec cette stratégie de routage, le routeur ODR redirige la demande vers l'URL spécifiée. Le format de l'URL est protocol://URI. Un exemple d'adresse URL valide est http://w3.ibm.com.

Stratégies de service valides

Les stratégies de service valides sont les noms de classe de transaction. La classe de transaction fait référence à une classe de service unique.


Icône indiquant le type de rubrique Rubrique de référence



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=rwve_odrworkclass
Nom du fichier : rwve_odrworkclass.html