Au même titre que pour des développements traditionnels J2EE, implémenter des services OSB nécessite d’être vigilant sur les aspects de production et d’exploitabilité. Aujourd’hui nous allons aborder un sujet classique avec Oracle Service Bus : l’exposition de services web applicatifs (ex: gestion de stock en temps réel) sur un bus de service et les précautions à prendre vis-à-vis d’un environnement de production.
Le développement de ce type de services (appelés « passe plat » car ils routent simplement les requêtes/réponses entre l’utilisateur et le service web applicatif), bien que trivial en termes d’implémentation, comporte des pièges à éviter.

Mauvaise gestion des threads du serveur d’applications : mise en place de timeouts HTTP

Par défaut un business service OSB utilisant le transport HTTP ne définit aucun timeout particulier. En l’essence, si le service web distant est très long à répondre (en cas de montée en charge par exemple) alors OSB attend indéfiniment, bloquant le thread utilisateur correspondant.
Les conséquences peuvent être désastreuses pour la production car la simple montée en charge d’un service web saturé provoque le blocage de tous les threads du serveur d’applications et l’indisponibilité des autres services OSB.
Il convient donc de positionner des gardes-fou sous la forme de timeouts HTTP. Il est possible et recommandé de positionner 2 types de timeout (voir onglet « HTTP Transport Configuration » du business service) :

• Connection Timeout: durée maximale d’attente en seconde pour établir la connexion HTTP avec le service distant
• Read Timeout: durée maximale d’attente en seconde pour obtenir la réponse du service distant (une fois que la requête utilisateur a été transmise)

Il ne s’agit donc ici que d’une simple configuration mais il est indispensable de l’incorporer dans vos bonnes pratiques de développement OSB.
Nous aborderons d’autres aspects de ce type dans de prochains billets « OSB pitfalls ».