Introduit dans la version 12.2.1.3.0 de WebLogic Server, le framework « ReadyApp » permet de gérer plus finement l’accès aux applications hébergées dans un domaine WebLogic.

La documentation est assez claire et permet de mettre en oeuvre la fonctionnalité.

Je souhaiterai apporter ici quelques précisions qui permettrons, j’espère, d’utiliser cette fonctionnalité à bon escient.

Le frameword « ReadyApp » permet d’introduire une notion de disponibilité jusque-là absente dans WebLogic Server. En effet, jusqu’à présent toute application déployée dans un serveur WebLogic est accessible par les utilisateurs dès que :

• le serveur est à l’état RUNNING
• et que l’application est à l’état ACTIF (ACTIVE en anglais), c’est à dire complètement déployée.

Cet état ACTIF reflète un état technique de l’application. Fonctionnellement, si l’application a besoin d’exécuter d’autres actions pour devenir complètement opérationnelle elle fait prendre le risque aux utilisateurs de tomber sur des erreurs pendant cette phase d’initialisation.

Avec le framework « ReadyApp », c’est l’application qui prend la responsabilité d’annoncer clairement sa disponibilité ou non, contrairement au mode ADMIN où c’est l’administrateur ou l’exploitant qui décide.

Techniquement, la fonctionnalité ne présente pas de difficulté dans sa mise en oeuvre ; il faut toutefois bien avoir à l’esprit ces quelques points :

• Pour bénéficier de cette fonctionnalité la ou les applications du domaine doivent s’enregistrer auprès du framework via une configuration dans le descripteur de déploiement weblogic-application.xml (ear) ou weblogic.xml (war) L’état par défaut est NOT READY.
• Cet état READY/NOT READY est porté au niveau du SERVEUR WebLogic et pas unitairement application par application. En conséquence :
  • Pour que le serveur passe à l’état READY toutes les applications enregistrées auprès du frameword ReadyApp doivent appeler la méthode weblogic.application.ready.ReadyLifecycleManager.getInstance().ready()
  • Tant qu’au moins 1 application enregistrée n’a pas appelé la méthode weblogic.application.ready.ReadyLifecycleManager.getInstance().ready(), ou qu’elle appelle la méthode weblogic.application.ready.ReadyLifecycleManager.getInstance().notReady() le serveur reste ou passe à l’état NOT READY.
• Une fois le serveur démarré (RUNNING) toutes les applications déployées et à l’état ACTIF sont techniquement accessibles via leur URL (http://localhost:7001/myWebApp par exemple)
  • WebLogic ne bloque pas l’accès à ces applications, même si le serveur est à l’état NOT READY.
  • Le verrouillage de l’accès à un serveur dont toutes les applications ne sont pas initialisées se fait obligatoirement par le serveur HTTP placé en amont (Apache HTTPD, HAProxy, Nginx par exemple) Il doit donc être configuré en conséquence avec une fonctionnalité de health-check. L’url de health-check se présente sous la forme http://[HOST]:[PORT]/weblogic/ready qui  renverra une page blanche et un code HTTP à interpréter :
    • 200 – OK : Les applications sont prêtes à recevoir des requêtes
    • 503 – Service Unavailable : les applications ne sont pas prêtes à recevoir des requêtes.

En résumé, la fonctionnalité est intéressante pour peu qu’on comprenne bien son fonctionnement. J’y vois un intérêt particulier pour répondre à un besoin récurrent de disposer d’un moyen facile pour ouvrir/fermer l’accès aux applications d’un serveur sans passer par la « plomberie » administrative de la console d’administration ou de WLST, ou de jouer avec la configuration des serveurs HTTP placés devant les serveurs WebLogic. L’état étant au niveau de chaque serveur, il est donc ainsi possible de « sortir » un serveur du service assez facilement pour quelque raison que ce soit sans avoir besoin de modifier une quelconque configuration. Une fois l’opération terminée le serveur peut être de nouveau opérationnel pour le service.

Petit regret quand même, cette information n’est pas accessible depuis la console d’administration ou depuis les MBeans (donc depuis WLST) La seule solution est d’utiliser l’url de health-check ou d’activer l’option de debug correspondante.

Bonne lecture.