Il y a quelques temps, j’avais fait une série d’articles sur resteasy-netty et resteasy-netty4.
Cette article repart du même besoin, à savoir disposer d’une stack légère pour réaliser un service REST, mais en utilisant Undertow plutôt que Resteasy-Netty.
Au niveau des besoins, ils seront identiques ie. :
utiliser JAX-RS, intégrer Swagger, intégrer Jolokia, générer un livrable autoporteur. RestEasy-Netty, même s’il existe de nombreux points d’entrée, demande quelques phases de hack (gestion du crossover domain par exemple) et dispose d’un mécanisme un peu limité concernant la partie sécurité.
Pour faire suite à mes articles resteasy-netty et resteasy-netty4, nous allons voir, dans cet article, comment il est possible de créer un service activator avec Spring Integration qui exposera via resteasy-netty4 un service REST.
Ce service REST esposera simplement une opération en POST qui, via Spring Integration, écrira dans un fichier et qui, pour le fun, écrira également sur la console.
Pour ce faire, rien de plus simple, un Service Activator de type gateway a été utilisé.
Pour faire suite à mon article précédent qui montrait comment il était possible de construire une stack légère basée sur Resteasy-Netty3, Jackson, Jolokia et Swagger, cet article montrera comment il est possible de faire la même chose avec Resteasy-Netty4 et Jackson 2.
Même si les changements ne sont pas énormes, il y a quand même quelques variantes, et, histoire d’être exhaustif, cela permet de faire le tour complet… ;-)
L’informatique évolue constamment et c’est également le cas des architectures qui ont tendance à s’orienter de plus en plus vers l’utilisation de services REST. Ces services REST doivent, en outre, être de plus en plus véloces afin de pouvoir répondre à une charge de plus en plus forte (que ce soit d’un point de vue temps de réponse mais également d’un point de vue charge suportée). C’est dans ce contexte que des solutions comme Restlet ou RestX (pour n’en citer que quelques-unes) ont vu le jour.
Dans des articles précédents, je m’étais déjà exprimé sur le fait que je trouvais qu’il était important de monitorer son application (qu’il s’agisse d’une application web, d’un batch ou d’une application standalone) (cf. ici). J’avais même creusé un peu la spécification JMX (cf. là).
Pour faire suite à ce besoin, je vais, dans cet article, faire un focus sur un outils que j’ai découvert récemment (merci Romain ;-) ) mais qui existe depuis un moment (la version 1.
