خدمات Servlet في Java

الـ Servlet هي الوحيدة التي تحوّل فعليًا، في تطبيق Jakarta EE، طلب HTTP إلى استجابة. أما كل ما عداها — JSP وJSTL والمرشحات (filters) وحتى أطر العمل الكاملة مثل Spring MVC — فمبني فوقها. حين تكتب @RestController في Spring، ينتهي مساره داخل servlet تُسمى DispatcherServlet. وفهم هذه الفئة يعني فهم الأساس الذي يقوم عليه كل الويب في Java.

المشكلة التي تحلّها الـ servlet هي مشكلة التزامن. مئة زائر يطرقون خادمك في اللحظة نفسها. هل ينبغي إنشاء مئة كائن؟ ومئة خيط (thread)؟ ومن يتولى إتلافها؟ إن جواب المواصفة مخالف للحدس وله عواقب كبيرة: تنشئ الحاوية نسخة واحدة فقط من الـ servlet الخاصة بك، وتجعل جميع الخيوط تمرّ عبرها في الوقت نفسه. هذا القرار، المتخذ نيابةً عنك، يفسّر نصف أخطاء الإنتاج في تطبيقات Java للويب: فالحقل من حقول النسخة داخل servlet هو حالة مشتركة بين جميع المستخدمين.

يتتبع هذا الدرس الطلب من بدايته إلى نهايته: كيف تختار الحاوية الـ servlet التي ستستدعيها، ومتى تنشئ الكائن وتتلفه، وكيف تقرأ المعاملات والترويسات، وكيف تقرر بين إعادة التوجيه والتحويل الداخلي، وكيف تتعرف على الزائر من طلب إلى آخر مع أن HTTP لا يملك أي ذاكرة.

وسنرى أيضًا، بشكل منهجي، ما الذي يفشل: الـ servlet التي نسينا التصريح بها فتردّ بـ 404، وgetParameter التي تعيد null دون سابق إنذار، والحقل المشترك الذي يجعل الزائر A يرى بيانات الزائر B.