Servlet Jakarta

Un servlet Jakarta , anciennement Java Servlet, est un composant logiciel Java qui étend les capacités d'un serveur . Bien que les servlets puissent répondre à de nombreux types de requêtes, ils implémentent le plus souvent des conteneurs Web pour héberger des applications Web sur des serveurs Web et sont donc qualifiés d' API Web de servlet côté serveur . Ces servlets Web sont l' équivalent Java d'autres technologies de contenu Web dynamique telles que PHP et ASP.NET .

Un Jakarta Servlet est une classe Java dans Jakarta EE qui est conforme à l'API Jakarta Servlet, une norme pour l'implémentation de classes Java qui répondent aux requêtes. Les servlets peuvent en principe communiquer via n'importe quel protocole client-serveur , mais ils sont le plus souvent utilisés avec HTTP . En principe, n'importe quel servlet peut étendre la GenericServletclasse ; cependant, de manière réaliste, tous les servlets étendent la HttpServletclasse. Ainsi, « servlet » est souvent utilisé comme abréviation de « servlet HTTP ». Ainsi, un servlet peut être utilisé pour ajouter du contenu dynamique à un serveur Web à l'aide de la plate-forme Java . Le contenu généré est généralement du HTML , mais peut être d'autres données telles que du XML et plus communément du JSON .

L'API Jakarta Servlet a été, dans une certaine mesure, remplacée par deux technologies Java standard pour les services Web :

• les services Web Jakarta RESTful (JAX-RS 2.0) utiles pour les services AJAX, JSON et REST, et
• les services Web XML Jakarta (JAX-WS) utiles pour les services Web SOAP .

A Servletest un objet qui reçoit une requête et génère une réponse en fonction de cette requête. Le Servletpackage de base définit des objets Java pour représenter les requêtes et les réponses des servlets, ainsi que des objets pour refléter les paramètres de configuration et l'environnement d'exécution du servlet.

L' API Servlet , contenue dans la hiérarchie des packages Javajavax.servlet , définit les interactions attendues du conteneur Web et d'un servlet.

Le package javax.servlet.httpdéfinit des sous-classes spécifiques à HTTP du package GenericServlet. Ce package comprend des objets de gestion de session qui suivent plusieurs requêtes et réponses entre le serveur Web et un client.

Les servlets peuvent conserver l'état des variables de session sur plusieurs transactions serveur en utilisant des cookies HTTP ou un mappage d'URL . Il existe plusieurs façons de créer un servlet et d'utiliser le mappage d'URL avec un servlet. Avant la spécification servlet 3.0 (Tomcat 7.0), la configuration du fichier web.xml pour mapper un servlet à une URL était la seule option. Pour les applications utilisant la spécification servlet 3.0 ou une version ultérieure, l' @WebServletannotation peut être utilisée pour mapper n'importe quel servlet à un ou plusieurs modèles d'URL.

Les servlets peuvent être empaquetés dans un fichier WAR en tant qu'application Web .

Un conteneur Web est nécessaire pour déployer et exécuter un servlet. Un conteneur Web (également appelé conteneur de servlet) est essentiellement le composant d'un serveur Web qui interagit avec les servlets. Le conteneur Web est responsable de la gestion du cycle de vie des servlets, du mappage d'une URL à un servlet particulier et de la garantie que le demandeur d'URL dispose des droits d'accès appropriés.

Les servlets peuvent être générés automatiquement à partir de Jakarta Server Pages (JSP) par le compilateur Jakarta Server Pages . La différence entre les servlets et les JSP est que les servlets intègrent généralement du HTML dans le code Java, tandis que les JSP intègrent du code Java dans le HTML. En général, lors de l'utilisation de JSP, l'intégration de code Java dans JSP est considérée comme une mauvaise pratique. Au lieu de cela, une meilleure approche serait de déplacer la logique back-end de la JSP vers le code Java dans le Servlet. Cela garantit que le Servletest uniquement responsable du traitement et que la JSP est uniquement responsable de la présentation du HTML, permettant une séparation claire des préoccupations et la conformité au principe de responsabilité unique .

Bien que l'utilisation directe de servlets pour générer du HTML (comme indiqué dans l'exemple ci-dessous) soit devenue rare, le framework Web MVC de niveau supérieur dans Jakarta EE ( Faces ) utilise toujours explicitement la technologie des servlets pour la gestion des requêtes/réponses de bas niveau via le FacesServlet.

Une utilisation un peu plus ancienne consiste à utiliser des servlets en conjonction avec des JSP dans un modèle appelé « Modèle 2 », qui est une variante du modèle–vue–contrôleur .

L'API Java Servlet a été annoncée publiquement pour la première fois lors de la conférence inaugurale JavaOne en mai 1996. Environ deux mois après les annonces de la conférence, la première implémentation publique a été mise à disposition sur le site Web de JavaSoft. Il s'agissait de la première version alpha du serveur Web Java (JWS ; alors connu sous son nom de code Jeeves ) qui serait finalement livré en tant que produit le 5 juin 1997.

Dans son blog sur java.net , Jim Driscoll, vétéran de Sun et responsable de GlassFish, détaille l'histoire de la technologie des servlets. James Gosling a pensé pour la première fois aux servlets aux premiers jours de Java , mais le concept n'est devenu un produit qu'en décembre 1996, lorsque Sun a livré JWS. C'était avant que ce qui est maintenant le Jakarta EE ne soit transformé en spécification.

La spécification Servlet1 a été créée par Pavni Diwanji alors qu'elle travaillait chez Sun Microsystems , avec la version 1.0 finalisée en juin 1997. À partir de la version 2.2, la spécification a été développée dans le cadre du Java Community Process .

Trois méthodes sont essentielles au cycle de vie d'un servlet. Il s'agit de init(), service()et destroy(). Elles sont implémentées par chaque servlet et sont invoquées à des moments précis par le serveur.

• Au cours de la phase d'initialisation du cycle de vie du servlet , le conteneur Web initialise l'instance du servlet en appelant la méthode init(), en transmettant un objet implémentant l'interface javax.servlet.ServletConfig. Cet objet de configuration permet au servlet d'accéder aux paramètres d'initialisation nom-valeur à partir de l'application Web.
• Après l'initialisation, l'instance de servlet peut traiter les demandes des clients. Chaque demande est traitée dans son propre thread séparé. Le conteneur Web appelle la service()méthode du servlet pour chaque demande. La service()méthode détermine le type de demande effectuée et la répartit vers une méthode appropriée pour gérer la demande. Le développeur du servlet doit fournir une implémentation pour ces méthodes. Si une demande est effectuée pour une méthode qui n'est pas implémentée par le servlet, la méthode de la classe parent est appelée, ce qui entraîne généralement le retour d'une erreur au demandeur.
• Enfin, le conteneur Web appelle la destroy()méthode qui met le servlet hors service. La destroy()méthode, comme init(), n'est appelée qu'une seule fois dans le cycle de vie d'un servlet.

Voici un scénario d’utilisation typique de ces méthodes.

1. Supposons qu’un utilisateur demande à visiter une URL .
   • Le navigateur génère ensuite une requête HTTP pour cette URL.
   • Cette demande est ensuite envoyée au serveur approprié.
2. La requête HTTP est reçue par le serveur Web et transmise au conteneur de servlet.
   • Le conteneur mappe cette demande à un servlet particulier.
   • Le servlet est récupéré dynamiquement et chargé dans l'espace d'adressage du conteneur.
3. Le conteneur appelle la init()méthode du servlet.
   • Cette méthode est invoquée uniquement lorsque le servlet est chargé pour la première fois en mémoire.
   • Il est possible de passer des paramètres d'initialisation au servlet afin qu'il puisse se configurer lui-même.
4. Le conteneur appelle la service()méthode du servlet.
   • Cette méthode est appelée pour traiter la requête HTTP.
   • Le servlet peut lire les données qui ont été fournies dans la requête HTTP.
   • Le servlet peut également formuler une réponse HTTP pour le client.
5. Le servlet reste dans l'espace d'adressage du conteneur et est disponible pour traiter toutes les autres requêtes HTTP reçues des clients.
   • La service()méthode est appelée pour chaque requête HTTP.
6. Le conteneur peut, à un moment donné, décider de décharger le servlet de sa mémoire.
   • Les algorithmes par lesquels cette décision est prise sont spécifiques à chaque conteneur.
7. Le conteneur appelle la destroy()méthode du servlet pour abandonner toutes les ressources telles que les handles de fichiers qui sont alloués au servlet ; les données importantes peuvent être enregistrées dans un magasin persistant.
8. La mémoire allouée au servlet et à ses objets peut ensuite être récupérée.

L'exemple de servlet suivant imprime combien de fois sa service()méthode a été appelée.

Notez qu'il HttpServlets'agit d'une sous-classe de GenericServlet, une implémentation de l' Servletinterface.

La service()méthode de HttpServletclasse envoie des requêtes aux méthodes doGet(), doPost(), doPut(), doDelete(), etc. en fonction de la requête HTTP. Dans l'exemple ci-dessous, service()elle est remplacée et ne distingue pas la méthode de requête HTTP qu'elle sert.

importer java.io.IOException ;
importer jakarta.servlet.ServletConfig ; importer jakarta.servlet.ServletException ; importer jakarta.servlet.http.HttpServlet ; importer jakarta.servlet.http.HttpServletRequest ; importer jakarta.servlet.http.HttpServletResponse ;
classe publique ServletLifeCycleExample étend HttpServlet { private Integer sharedCounter ;
@Override 
public void init ( final ServletConfig config ) throws ServletException { super . init ( config ) ; getServletContext (). log ( "init() appelé" ); sharedCounter = 0 ; }
@Override 
protected void service ( final HttpServletRequest request , final HttpServletResponse response ) throws ServletException , IOException { getServletContext (). log ( "service() appelé" ); int localCounter ; synchronized ( sharedCounter ) { sharedCounter ++ ; localCounter = sharedCounter ; } response.getWriter (). write ( " Incrémentation du compte à" + localCounter ); // accès à une variable locale response.getWriter (). flush (); // vidage response }
@Override 
public void destroy () { getServletContext (). log ( "appelé destroy()" ); } }

La spécification de la technologie Servlet a été implémentée dans de nombreux produits. Consultez la liste des implémentations sur la page du conteneur Web .

Il existe également d'autres types de conteneurs de servlets tels que ceux pour les servlets SIP, par exemple SailFin .