Jean FRANCOIS blog [Weblogic / Java EE / SOA]

 

 

 

 

Transports Bloquant
Dans le cas de Proxy/Business Service, vous pouvez déclarer un WorkManager spécifique et côté Business Service vous pouvez utiliser le Throttling (mécanisme de file mémoire de régulation).
Le Proxy Service et Business service (ou Nested Proxy) s’exécute dans le même thread d’exécution, et l’association d’un WorkManager associé à un Proxy ou Business correspond a une affectation sur le thread request ou response côté Inbound ou Outbound (a l’extérieure d’OSB). Le throtlling lui s’applique en interne d’OSB (thread activé).
(dans le cas d’un Business Service, le WorkManager ne s’applique que sur la reponse)
Dans le cas du WorkManager, pour remonter une erreur dans le cas d’empilement d’appels en blocage externe, vous pouvez utiliser une contrainte. Dans le cas du throttling, l’expiration des requêtes entraine une erreur côté client. Vous pouvez également mettre en place une désactivation automatique des artefacts selon un SLA comme présentée dans ce blog (non-natif au produit) :
Au sein des messages flow des Proxy Service, vous pouvez définir des appels de service de façons différentes impliquant une gestion de thread particulière pour chaque cas.

• Publish invocation asynchrone (one way) sans attendre la réponse dans le message flow.
• Callout Invocation multiple synchrone de service dans le message flow.
• Routing Invocation synchrone ou asynchrone d’un simple business Service en fin de message flow.

La gestion des threads est utilisée différemment selon les cas sachant que le mode Publish est asynchrone est donc n’attend pas de notification retour du service distant.
Dans le cas du Routing synchrone (ou publish synchone avec QoS=ExactlyOnce), ce n’est pas un seul thread, mais deux (Request/Response en thread dissocié) qui supporte l’activation du message flow (sauf dans le cas d’une transaction globale déclarée côté client (XAConnectionFactory) et le Proxy en transaction (QoS=ExactlyOnce).
La notification retour est déclenchée via le Muxer Weblogic (WLS AsyncResponseHandler callback) qui active un autre thread sur le message flow retour du Proxy Service. De cette façon, le thread Request ne reste pas bloqué sur l’attente de la réponse retour.
Dans le cas du Callout, la requête synchrone (Request/Response) est gérée par un seul thread, mais le retour est déclenché par un autre thread de notification activé par le même mécanisme Muxer que le Routing. Il y a donc toujours 2 threads utilisés, mais le Callout n’est supporté que par un seul Thread.
Dans le cas où un Proxy Service appel un autre Proxy Service, l’ensemble de l’appel s’exécute sur un même thread d’exécution (Thread Request/Thread Response).
WORKMANAGER
OSB permet d’associer un WorkManager à un Proxy et Business Service. L’intérêt étant de modifier les contraintes pour déclarer un minimum de thread afin d’éviter les inters blocage lié au mode de threading de l’appel ou un maximum afin d’éviter des saturations de service. On pourrait ainsi définir certains cas d’usage ou règles à appliquer lors de constatations de contention:

• Définir un MinThreadConstraint à 3 ou 5 thread sur un Proxy Service dans le cas où l’on a plusieurs Callout afin de ne pas attendre sur le thread de notification. Même remarque entre inter appel de Proxy Service sur une même instance Weblogic.
• On pourra utiliser un MaxThreadConstraint pour tuner un Proxy type MDB afin de gérer le throughput de dépilement ou borner les appels d’un service impliqué dans le Proxy.
• Eviter d’utiliser un même WorkManager pour un Proxy Service et un Business Service dépendant (inter blocage).

Les Outbound (appels sortants) peuvent être régulés par le WorkManager mais également par un mécanisme de file mémoire interne à OSB (Throttling). On pourra dans ce cas définir pour chaque Business une contrainte de requêtage request spécifique.
L’intérêt étant de ne pas devoir déclaré autant de WorkManager et de contrainte Max que de Proxy sachant que les contraintes étant globales et que l’affectation d’un WorkManager sur les flux sortants s’applique sur les Proxy (responsable des thread request).