Récemment, chez un client nous avons positionné l’OSB pour sécuriser les échanges entre les différentes applications et Oracle SOA Suite.
L’OSB dispose de différentes fonctionnalités intéressantes permettant de sécuriser les échanges : Work Manager, Throttling, Timeout, etc.
Nous allons détailler dans cet article comment nous avons utilisé les Work Manager pour sécuriser Oracle SOA Suite et éviter de monopoliser les threads sur un canal de communication donné.

Point sur les threads dans OSB et les Work Manager

Dans un proxy, les requêtes et réponses sont exécutées par défaut dans des threads séparés.
Comment ?
Le transport http utilise les fonctionnalités asynchrones de Weblogic.
Pourquoi ?
Tout simplement pour éviter le blocage d’un thread lors de l’attente de la réponse.
Ce comportement par défaut est néanmoins modifiable en positionnant l’option « Exactly Once » via les options de routage. Aussi, lors d’un appel synchrone fait avec l’activité « Service Callout », le thread d’appel est bloqué.
Chacune des tâches / requêtes est exécutée via des threads mis à disposition dans un pool de threads. La taille du pool évolue en fonction de la demande. Les requêtes entrantes sont évaluées suivant différents algorithmes définissant des priorités de traitements.
Lorsque tous les threads sont occupés, les requêtes entrantes sont empilées dans une file de messages et seront traitées dès que des threads seront disponibles dans le pool.
On a la possibilité d’agir sur le composant Weblogic ordonnançant le traitement des requêtes pour typer les requêtes, les prioriser et les contraindre (Max, Min, etc.) via les Work Manager.
Sur les Work Manager, il est donc possible de positionner notamment des contraintes :

• Max Threads : limiter le nombre de threads concurrents exécutant un type de requête donné
• Min Threads : garantit la disponibilité d’un certain nombre de threads pour exécuter un type de requête donné
• Capacity Constraint : Une fois la contrainte maximale atteinte, les requêtes sont empilées dans une file dont la capacité peut être définie via cette contrainte. Toutes les requêtes arrivant alors que la file est pleine sont refusées (erreur 500). A noter que le temps passé dans cette file s’additionne au temps d’exécution et ne sera pas pris en compte si un timeout est positionné sur le Business Service en sortie.

Par défaut le pool de threads Weblogic est de 400 threads et il est partagé par toutes les requêtes.

Problème

Le problème est qu’en sortie, un applicatif ne supporte pas la charge et est appelé en synchrone par la SOA Suite dans laquelle aucun timeout n’a été paramétré.
En cas de volumétrie importante, les temps de réponse de l’application A2 augmentent et la monopolisation des threads devient de plus en plus importante. On sature rapidement et les appels vers les autres applicatifs ne peuvent plus se faire non plus puisque tous les threads sont monopolisés et en attente de A2.

Solution

La solution est donc de positionner l’OSB et des Work Manager pour limiter le nombre de requêtes parallèles pouvant être adressées à A2.
Un proxy est positionné en frontal de A2 et on lui associe un Work Manager qui lui est propre avec une contrainte maximale à évaluer en fonction des spécifications et des informations de volumétrie, de capacité relative à l’infrastructure, etc.
Par ailleurs, le routage vers A2 doit se faire avec l’option « Exactly Once » pour garantir que le thread se met en attente de la réponse sinon les threads sont libérés une fois le message envoyé et on ne maîtrise plus le nombre de requêtes adressées en parallèle à A2.
Ainsi, on garantit que l’application A2 ne monopolisera jamais plus de X threads et on garantit donc la disponibilité de la SOA Suite pour adresser des requêtes aux autres applicatifs qui ne sont pas engorgés.
J’espère que cet article vous aura aidé à mieux comprendre tous ces principes et que ce retour d’expérience pourra en aider quelques-uns 😉