يعالج خادم الويب طلبات HTTP حصريًا، بينما يخدم خادم التطبيق منطق الأعمال لبرامج التطبيق من خلال أي عدد من البروتوكولات.
خادم الويب:
يتعامل خادم الويب مع بروتوكول HTTP وعندما يتلقى خادم الويب طلب HTTP، فإنه يستجيب باستجابة HTTP، مثل إرسال صفحة HTML مرة أخرى لمعالجة الطلب، قد يستجيب خادم الويب بصفحة HTML ثابتة أو صورة، أو يرسل إعادة توجيه، أو يفوض إنشاء الاستجابة الديناميكية إلى بعض البرامج الأخرى مثل البرامج النصية CGI و JSPs (صفحات JavaServer) و(servlets و ASP) (صفحات الخادم النشطة) أو JavaScripts من جانب الخادم أو بعض التقنيات الأخرى من جانب الخادم مهما كان الغرض منها، فإن مثل هذه البرامج من جانب الخادم تولد استجابة، غالبًا بتنسيق HTML، للعرض في مستعرض الويب.
إن نموذج تفويض خادم الويب بسيط إلى حد ما وعندما يأتي طلب إلى خادم الويب، يقوم خادم الويب ببساطة بتمرير الطلب إلى البرنامج الأكثر قدرة على التعامل معه ولا يوفر خادم الويب أي وظائف بخلاف مجرد توفير بيئة يمكن للبرنامج من جانب الخادم تنفيذ الاستجابات التي تم إنشاؤها وتمريرها وعادةً ما يوفر البرنامج من جانب الخادم لنفسه وظائف مثل معالجة المعاملات واتصال قاعدة البيانات والرسائل.
على الرغم من أن خادم الويب قد لا يدعم المعاملات أو تجميع اتصال قاعدة البيانات بنفسه، إلا أنه قد يستخدم استراتيجيات مختلفة للتسامح مع الأخطاء وقابلية التوسع مثل موازنة التحميل والتخزين المؤقت والتجميع – وهي ميزات في كثير من الأحيان يتم تعيينها عن طريق الخطأ كميزات محفوظة فقط لخوادم التطبيقات.
خادم التطبيق:
بالنسبة لخادم التطبيق، وفقًا لتعريفنا، يعرض خادم التطبيق منطق الأعمال لتطبيقات العميل من خلال بروتوكولات مختلفة، ربما تتضمن HTTP بينما يتعامل خادم الويب بشكل أساسي مع إرسال HTML للعرض في مستعرض الويب، يوفر خادم التطبيق الوصول إلى منطق الأعمال لاستخدامه بواسطة برامج تطبيقات العميل و يمكن لبرنامج التطبيق استخدام هذا المنطق تمامًا كما يستدعي طريقة على كائن (أو دالة في العالم الإجرائي).
يمكن أن تتضمن عملاء خادم التطبيقات هذه واجهات المستخدم الرسومية (واجهة المستخدم الرسومية) التي تعمل على جهاز حاسوب أو خادم ويب أو حتى خوادم تطبيقات أخرى ولا تقتصر المعلومات التي تنتقل ذهابًا وإيابًا بين خادم التطبيق والعميل على ترميز العرض البسيط بدلا من ذلك، المعلومات هي منطق البرنامج ونظرًا لأن المنطق يتخذ شكل استدعاءات البيانات والطريقة وليس HTML الثابت، يمكن للعميل استخدام منطق الأعمال المكشوف كما يشاء.
في معظم الحالات، يعرض الخادم منطق الأعمال هذا من خلال واجهة برمجة تطبيقات مكون، مثل نموذج مكون (EJB (Enterprise JavaBean الموجود على خوادم تطبيق J2EE )Java 2 Platform، Enterprise Edition) وعلاوة على ذلك، يدير خادم التطبيق موارده الخاصة و تشمل واجبات حفظ البوابة الأمن ومعالجة المعاملات وتجميع الموارد والرسائل مثل خادم الويب، قد يستخدم خادم التطبيق أيضًا تقنيات قابلية التوسع والتسامح مع الخطأ.
كمثال، ضع في اعتبارك متجرًا عبر الإنترنت يوفر معلومات عن الأسعار والتوافر في الوقت الفعلي وعلى الأرجح، سيوفر الموقع نموذجًا يمكنك من خلاله اختيار منتج وعند إرسال الاستعلام الخاص بك، يقوم الموقع بإجراء بحث وإرجاع النتائج المضمنة في صفحة HTML وقد يقوم الموقع بتنفيذ هذه الوظيفة بعدة طرق وسأعرض لك سيناريو واحد لا يستخدم خادم تطبيق والآخر يستخدمه و ستساعدك رؤية كيفية اختلاف هذه السيناريوهات على رؤية وظيفة خادم التطبيق.
السيناريو 1: خادم الويب بدون خادم تطبيقات
في السيناريو الأول، يوفر خادم الويب وحده وظائف المتجر عبر الإنترنت و يأخذ خادم الويب طلبك، ثم يمرره إلى برنامج من جانب الخادم قادر على معالجة الطلب و يبحث البرنامج من جانب الخادم عن معلومات التسعير من قاعدة بيانات أو ملف ثابت بمجرد استردادها، يستخدم البرنامج الموجود على الخادم المعلومات لصياغة استجابة HTML، ثم يرسلها خادم الويب مرة أخرى إلى متصفح الويب الخاص بك و يعالج خادم الويب طلبات HTTP من خلال الاستجابة بصفحات HTML.
السيناريو 2: خادم الويب مع خادم التطبيق:
يشبه السيناريو 2 السيناريو 1 في أن خادم الويب لا يزال يفوض إنشاء الاستجابة إلى برنامج نصي ومع ذلك، يمكنك الآن وضع منطق الأعمال للبحث عن الأسعار على خادم التطبيق و مع هذا التغيير، بدلاً من أن يعرف البرنامج النصي كيفية البحث عن البيانات وصياغة استجابة، يمكن للبرنامج النصي ببساطة الاتصال بخدمة البحث في خادم التطبيق و يمكن للبرنامج النصي بعد ذلك استخدام نتيجة الخدمة عندما يولد البرنامج النصي استجابة HTML الخاصة به.
في هذا السيناريو، يخدم خادم التطبيق منطق الأعمال للبحث عن معلومات تسعير المنتج وهذه الوظيفة لا تذكر أي شيء عن العرض أو كيف يجب على العميل استخدام المعلومات وبدلاً من ذلك، يرسل العميل وخادم التطبيق البيانات ذهابًا وإيابًا و عندما يتصل العميل بخدمة البحث في خادم التطبيق، تبحث الخدمة ببساطة عن المعلومات وتعيدها إلى العميل.
من خلال فصل منطق التسعير عن كود إنشاء استجابة HTML، يصبح منطق التسعير أكثر قابلية لإعادة الاستخدام بين التطبيقات و يمكن لعميل ثانٍ، مثل ماكينة تسجيل المدفوعات النقدية، أن يتصل بنفس الخدمة التي يقوم بها موظف يقوم بفحص العميل و في المقابل، في السيناريو 1، لا يمكن إعادة استخدام خدمة البحث عن الأسعار لأن المعلومات مضمنة في صفحة HTML للتلخيص، في نموذج السيناريو 2، يعالج خادم الويب طلبات HTTP عن طريق الرد بصفحة HTML بينما يخدم خادم التطبيق منطق التطبيق من خلال معالجة طلبات التسعير والتوافر.
حمولة XML في خادم الويب:
في الآونة الأخيرة، طمست خدمات الويب XML الخط الفاصل بين خوادم التطبيقات وخوادم الويب من خلال تمرير حمولة XML إلى خادم الويب، يمكن لخادم الويب الآن معالجة البيانات والاستجابة إلى حد كبير كما فعلت خوادم التطبيقات في الماضي بالإضافة إلى ذلك، تحتوي معظم خوادم التطبيقات أيضًا على خادم ويب.
مما يعني أنه يمكنك اعتبار خادم الويب مجموعة فرعية من خادم التطبيق و بينما تحتوي خوادم التطبيقات على وظائف خادم الويب، نادرًا ما ينشر المطورون خوادم التطبيقات بهذه السعة وبدلاً من ذلك، عند الحاجة، يقومون بنشر خوادم ويب مستقلة جنبًا إلى جنب مع خوادم التطبيقات ويساعد هذا الفصل في الأداء الوظيفي (لن تؤثر طلبات الويب البسيطة على أداء خادم التطبيق) وتكوين النشر (خوادم الويب المخصصة والتجميع وما إلى ذلك) ويسمح باختيار أفضل المنتجات.
