بغير درد جي. اچو ته جاوا EE، servlets ۽ انهن جي ڪنٽينرز بابت ڳالهايون

هن موضوع ۾، مان servlets جي باري ۾ منهنجي سمجھاڻي بابت واضح طور تي ڳالهائڻ چاهيان ٿو، servlet ڪنٽينرز ڪهڙا آهن، ڇا سڀ کان وڌيڪ، جيڪڏهن سڀ نه، ويب فرنٽ-اينڊ فريم ورڪ آهن، ۽ انهي موضوع تي پڻ رابطو ڪرڻ چاهيان ٿو ته ڪيئن سرورليٽ ڪنٽينرز ۽ ايپليڪيشن سرورز سان تعلق رکن ٿا. هڪ ٻئي، ۽ servlet ۽ ويب سرور ڪنٽينرز. ڳالهه ٻولهه شروع ڪرڻ کان اڳ، مان اهو نوٽ ڪرڻ چاهيان ٿو ته مان واقعي توقع ڪريان ٿو ته اتي بحث ٿيندو، ڇاڪاڻ ته... هتي مان ڪوڊ جو هڪ ٽڪرو ڏيڻ نه ٿو چاهيان، پر صرف ان جوهر تي ڌيان ڏيڻ چاهيان ٿو، جيڪو هميشه لفظن ۾ بيان ڪري سگهجي ٿو. مان انهن سڀني نقطن کي بيان ڪرڻ جي ڪوشش ڪندس جيڪي مون کي واضح نه هئا جڏهن مون پهريون ڀيرو شروع ڪيو. جڏهن مون مختلف فورمن تي سوال پڇيا ته ٽام ڪيٽ سرورٽ ڪنٽينر ڪنهن به ايپليڪيشن سرور کان ڪيئن مختلف آهي، چون ٿا WebSphere يا Geronimo، صرف اهي ماڻهو جن جواب ڏيڻ جي جرئت ڪئي، اهي گداگر هئا جيڪي ”وڪيپيڊيا تي ڏسو“ يا ”وڪيپيڊيا تي ڏسو“ کان سواءِ ٻيو ڪجهه به نه چئي سگهيا. اهو چوڻ ڏکيو آهي، سرور ايپليڪيشنون - هي ڪارپوريٽ ايپليڪيشنن لاء هڪ پيچيده انفراسٽرڪچر آهي، جيڪو ..." blah blah blah. مان اهڙن ماڻهن کي برداشت نٿو ڪري سگهان ۽ مان سمجهان ٿو ته توهان مان گهڻا نه آهن. تاريخي ناانصافي کي درست ڪنداسين. وڃ…

سروليٽس

ڪو مسئلو ناهي ته ڪو ڇا چوي، هڪ servlet هڪ ويب پيج آهي جاوا ۾ لکيل آهي. ڪجھ چوندو ته مان غلط آھيان ۽ اھو ھڪڙو servlet ھڪڙو ويب ايپليڪيشن آھي ۽ انھن تصورن ۾ فرق آھي، پر ائين نه آھي. هاڻي ڪو به فرق نه آهي، ۽ PHP ۾ لکيل سائيٽون پڻ محفوظ طور تي ويب ايپليڪيشنون سڏي سگهجن ٿيون. هاڻي اهو مڪمل طور تي قدرتي آهي، ڇاڪاڻ ته ... php مڪمل طور تي OOP کي سپورٽ ڪري ٿو، ۽ CMSs جهڙوڪ جوملا فعال طور تي استعمال ڪن ٿا. ڪوڊ سطح تي هڪ servlet ڇا آهي؟ هي هڪ طبقو آهي جنهن ۾ ڪيترائي طريقا آهن جيڪي ننڊ ڪن ٿا ۽ ڏسو ته ڪو ماڻهو انهن کي GET يا POST HTTP درخواستن ذريعي رسائي ٿو. اهي. اسان برائوزر ۾ ڪجهه GET درخواست ٽائيپ ڪئي، servlet ڪلاس جو لاڳاپيل طريقو ان کي قبول ڪري ٿو ۽ پوء HTML صفحي جي صورت ۾ ان جو جواب پيدا ڪري ٿو. servlet جي ڪلاسيڪي معنيٰ ۾، جيئن سج پاران تصور ڪيو ويو هو، هي صفحو ڪلائنٽ لائن ڏانهن ليڪ ذريعي موڪليو ويو، ليڪ <!DOCTYPE htm>> سان شروع ٿئي ٿو ۽ </html> سان ختم ٿئي ٿو. تنهنڪري جاوا ۾ هڪ بنيادي سروليٽ ڪلاس آهي جنهن کي سڏيو ويندو آهي Servlet. ان کان علاوه، ٻين طبقن جو ھڪڙو گروپ آھن جيڪي ھن بنيادي طبقي مان ورثي ۾ آھن ۽ ان جي ڪارڪردگي کي وڌايو. اھو اھو آھي جيڪو ھڪڙو سروليٽ آھي - وڌيڪ ڪجھ به نه. اهو صرف PHP ڪوڊ جو هڪ جاوا اينالاگ آهي، جيڪو پڻ سرور تي عمل ڪيو ويو آهي، ۽ صرف ويب برائوزر جي درخواست جو جواب ويب پيج جي صورت ۾ ڪلائنٽ ڏانهن موڪليو ويو آهي. سڀ.

ويب فرنٽ-اينڊ فريم ورڪ

ذيلي عنوان پيچيده آهي ۽ عام طور تي اهي صرف لکندا آهن فرنٽ-اينڊ فريم ورڪ يا ويب موزول ، پر مون هتي زور ڏيڻ جو فيصلو ڪيو ته جڏهن اسان فرنٽ-اينڊ فريم ورڪ بابت ڳالهايون ٿا، اسان هڪ ويب برائوزر ذريعي جاوا سان ڪم ڪرڻ لاءِ GUI بابت ڳالهائي رهيا آهيون. اهي. هتي ٻيهر اسان جاوا ۾ ويب سائيٽن بابت ڳالهائي رهيا آهيون، يعني. servlets جي باري ۾. ڇا لڳ ڀڳ ڪنهن به سامهون-آخر فريم ورڪ آهي، مثال طور، Apache Struts. اهو صرف طبقن جو هڪ سيٽ آهي جيڪو بنيادي طبقي کي وڌايو آهي Servlet. وڌيڪ ڪجھ به نه. اهي. اهو ساڳيو باقاعده servlet ٺاهڻ لاء صرف هڪ مختلف طريقو آهي. اهو صرف اهو آهي ته هن فريم ورڪ جي ڊولپرز (يا ٻين لفظن ۾، هن ٽيڪنالاجي جي ڊولپرز) سمجهي رهيا آهن ته انهن جي بنيادي Servletطبقي کي ڪجهه طريقن سان شامل ڪرڻ پروگرامر لاء گهٽ ڪارڪردگي جي ڀيٽ ۾ وڌيڪ آسان هوندو، جيڪو سج / اوريڪل کان کلاسک سرليٽ. آهي.

JSP صفحا

لڳ ڀڳ فوري طور تي، هڪ ٻيو خيال جاوا servlet تصور جي ڊولپر جي ذهن ۾ آيو. جيئن ته اسان هڪ servlet لکي رهيا آهيون، جنهن جو ڪم ڪلائنٽ ڏانهن هڪ html صفحو موڪلڻ آهي، ان ڪري اهو وڌيڪ صحيح ٿي سگهي ٿو ته هن html صفحي کي فوري طور تي لکي، ۽ جيڪڏهن توهان کي جاوا ۾ ڪنهن قسم جي منطق جي ضرورت آهي، ته پوء سڌو سنئون داخل ڪريو. html ۾. جيڪڏهن اهو واضح نه ٿيو، ته جملي مدد ڪري سگهي ٿي: هڪ jsp صفحو هڪ php صفحي جو هڪ اينالاگ آهي. مشڪل؟ پوءِ مان ٻيهر وضاحت ڪندس. PHP ۾ صفحو لکڻ وقت اسان ڇا ڪندا آهيون؟ اسان وٽ جامد html آهي، ۽ جڏهن اسان کي PHP ۾ ڪا منطق داخل ڪرڻ جي ضرورت آهي جهڙوڪ لوپس ۽ حالتون، اسان ان کي ٽيگ جي جسم ۾ داخل ڪندا آهيون <?php … ?>. jsp سان سڀ ڪجهه ساڳيو آهي، صرف منطق خالص جاوا ۾ لکيل آهي، جنهن جو ڪوڊ ٽيگ جي جسم ۾ داخل ڪيو ويو آهي <% … %>. اچو ته هڪ ڀيرو ٻيهر هڪ سروليٽ جي تصور ڏانهن موٽون. ذات ۾، هڪ JSP صفحو هڪ servlet آهي، پر ٿورو مختلف لکيو ويو آهي. هڪ باقاعده سرورٽ ۾، اسان هڪ طريقو لکندا آهيون جيڪو ڪجهه منطق انجام ڏئي ٿو ۽، ان جي نتيجن جي بنياد تي، ڪلائنٽ لاء هڪ HTML صفحو ٺاهي ٿو. اهو صرف اهو آهي ته ڪجهه وقت کان پوء، servlet ڊولپر سوچڻ شروع ڪيو: ڇا ٿيندو جيڪڏهن طريقي سان عملي طور تي ڪو منطق نه آهي، ۽ تقريبا صرف هڪ html صفحي جي ٺهڻ جي صورت ۾، پوء اهو آسان نه ٿيندو ته فوري طور تي هڪ html صفحو لکڻ جنهن کي گهٽ ۾ گهٽ جاوا داخل ڪرڻ لاءِ؟ خير، jsp صفحن بابت هڪ آخري شيء. پهريون ڀيرو اهڙي صفحي تائين رسائي حاصل ڪئي وئي آهي، اهو هڪ سرورٽ ۾ مرتب ڪيو ويو آهي ۽ پوء عمل ڪيو ويندو آهي. هن jsp صفحي تي ايندڙ درخواستون تيز ٿي وينديون ڇاڪاڻ ته اهو اڳ ۾ ئي مرتب ڪيو ويندو ۽ صرف عمل ڪرڻ جي ضرورت پوندي.

سروليٽ ڪنٽينر

تنهنڪري اسان هڪ servlet ڪلاس يا JSP صفحو لکيو. اڳتي ڇا آهي؟ انهن کي ويب سرور ۾ ڪيئن ڌڪيو وڃي، چئو apache، ته جيئن اهو انهن کي صارف جي ويب برائوزر ڏانهن موڪلي سگهي؟ ويب سرور صرف html موڪلي سگهي ٿو، ۽ جيڪڏهن اسان جي صفحي کي، چئو، php ڪوڊ، پوء ويب سرور پهريون ڀيرو صفحي کي هڪ مترجم جي ذريعي گذري ٿو جيڪو php کي html ۾ ترجمو ڪري ٿو، ۽ صرف پوء نتيجو ڪلائنٽ ڏانهن موڪليو ويو آهي. ساڳئي شيء بابت servlets سان ٿئي ٿي - موڪلڻ کان اڳ، انهن کي عمل ڪرڻ جي ضرورت آهي HTML صفحي کي پيدا ڪرڻ لاء، ۽ servlet ڪنٽينر بلڪل اها شيء آهي جيڪا servlets ۽ jsp صفحي جي ڪوڊ تي عمل ڪرڻ لاء ذميوار آهي. اهي. جاوا لاءِ هڪ سروليٽ ڪنٽينر ويب سرور ۾ php مترجم ماڊل جو هڪ اينالاگ آهي. اهڙيء طرح، جڏهن صارف ويب برائوزر ۾ هڪ ايڊريس داخل ڪري ٿو، درخواست ويب سرور ڏانهن موڪلي وئي آهي، ويب سرور سمجهي ٿو ته هڪ سرورٽ جي درخواست ڪئي پئي وڃي ۽ درخواست کي سرورٽ ڪنٽينر ڏانهن منتقل ڪري ٿو. ان کان پوء، servlet ڪنٽينر servlet تي عمل ڪري ٿو، نتيجو HTML صفحي کي ويب سرور ڏانهن موڪلي ٿو، جيڪو، موڙ ۾، ان کي ڪلائنٽ ڏانهن موٽائي ٿو. ڇا هڪ سروليٽ ڪنٽينر پنهنجو پاڻ تي هلائي سگهي ٿو، يعني ويب سرور کان سواء؟ Tomcat وانگر ڪجهه ضرور ڪري سگهي ٿو. ۽ جيڪڏهن اسان هڪ اهڙي سائيٽ ٺاهڻ چاهيون ٿا جنهن ۾ ٻيا html صفحا نه هجن سواءِ انهن servlets تي ٻڌل، ته پوءِ هڪ servlet ڪنٽينر اسان لاءِ ڪافي آهي. پر جيڪڏهن اسان هڪ سائيٽ کي گڏ ڪرڻ چاهيون ٿا servlets مان ۽، چئو، PHP صفحا، پوء اسان کي هڪ ويب سرور نصب ڪرڻو پوندو. ان کان علاوه، سڀني ويب سرورن ۾ ڊفالٽ طور تي شامل ڪيل سرورٽ ڪنٽينر نه آھي، پر تقريبا سڀئي توھان کي ان کي پلگ ان جي طور تي انسٽال ڪرڻ جي اجازت ڏين ٿا. تنهن ڪري، جيڪڏهن اسان چاهيون ٿا ته اسان جي ويب سائيٽ انٽرنيٽ تي ڪجهه هوسٽنگ تي، جتي Apache گهڻو ڪري هلندو آهي، پوء اسان کي فراهم ڪندڙ کان پڇڻو پوندو ته ڇا سرورٽ ڪنٽينر ڳنڍيل آهي.

جاوا اي

اتي جاوا ايس اي (جاوا معياري ايڊيشن) سڏيو ويندو آهي. هن تصور ۾ سڀ طبقا شامل آهن java، جن جي استعمال لاءِ اسان کي صرف انهن کي درآمد ڪرڻ جي ضرورت آهي (مثال طور، java.util.Date) يا ائين ڪرڻ جي به ضرورت ناهي (مثال طور، Stringڇاڪاڻ ته اهو پيڪيج ۾ واقع آهي java.lang). ۽ اتي جاوا EE (جاوا انٽرپرائز ايڊيشن) آهي. انهن طبقن جو تعلق پڻ Sun/Oracle سان آهي، پر فرق صرف اهو آهي ته انهن کي منصوبي ۾ استعمال ڪرڻ شروع ڪرڻ وڌيڪ مشڪل آهي. هڪ سادي لائن import…ڪافي نه هوندي، ڇاڪاڻ ته ... پروجيڪٽ گڏ نه ٿيندو. صورتحال کي درست ڪرڻ لاء، توهان کي javaee.jar لائبريري فائل ڳولڻ ۽ ان کي پروجيڪٽ ۾ شامل ڪرڻ جي ضرورت پوندي. اهو ترقي جي ماحول ۾ پروجيڪٽ جي ملڪيت جي ذريعي ڪري سگهجي ٿو. اهو اڪثر چيو ويندو آهي ته هن ڪنيڪشن جي عمل کي سڏيو ويندو آهي: رجسٽر ڪريو هڪ جار nickname in the build path or classpath of the project.

ايپليڪيشن سرور

ھاڻي تصور ڪريو ته اسان پنھنجي سروليٽ پروجيڪٽ کي مرتب ڪيو آھي جيڪو استعمال ڪري ٿو Java EE. هر شي عظيم آهي، پر هاڻي اسان کي اسان جي مرتب ڪيل طبقن کي هڪ سروليٽ ڪنٽينر ۾ رکڻ جي ضرورت آهي. اچو ته چوندا آهن ته اهي ڪيو. ڇا اسان جي درخواست ڪم ڪندو؟ جواب آهي نه. جڏهن servlet تائين پهچندي، استثنا اڇلايا ويندا ته ظاهر ڪن ٿا ته ڪجهه طبقا نه مليا آهن. ڇو؟ ڇو ته اسان ٺڪرائيندڙ کي ”ٺڳي“ ڪري ڇڏيو javaee.jar в classpath، يعني. مرتب ڪندڙ ڏٺو ته جاوا EE جا ڪلاس پنهنجي جاءِ تي هئا ۽ آرام سان، پر servlet ڪنٽينر انهن ڪلاسن کي نه ٿو ڏسي، پر اهو اسان جي servlet مان انهن جون لنڪس ڏسي ٿو. ڇا اها صورتحال هڪ servlet ڪنٽينر اندر حل ٿي سگهي ٿي؟ يقينا ها، توهان کي صرف javaee.jar لائبريري فائل کي فولڊر ۾ شامل ڪرڻ جي ضرورت آهي اسان جي سرورليٽ سان سرورليٽ ڪنٽينر ۾ . هاڻي تصور ڪريو ته اهڙا ڪيترائي منصوبا هوندا ۽ اهي سڀ هڪ ٽامڪيٽ سروليٽ ڪنٽينر ۾ هلندا آهن. ان جو مطلب اهو آهي ته توهان کي هن جار فائل کي هر سرور جي فولڊر ۾ نقل ڪرڻو پوندو. اهو ناگزير ۽ غلط آهي. صورتحال هڪ ايپليڪيشن سرور جي تصور کي متعارف ڪرائڻ سان حل ڪيو ويو، جنهن ۾ هي فائل ڊگهي عرصي کان هڪ ڪاپي ۾ آهي، ۽ سڀئي سرور ان تائين رسائي ڪري سگهن ٿا، ۽ انهن جي پنهنجي ڪاپي نه آهي. منهنجي خيال ۾، اهو تمام آسان ۽ منطقي آهي. قدرتي طور تي، سڀ تڪليف هڪ جار فائل جي سبب نه آهي (مون ان کي هڪ مثال طور ڏنو) - اهڙيون ڪيتريون ئي فائلون آهن. پر اهو سڀ ڪجهه ناهي ته ايپليڪيشن سرور اسان کي ڏين ٿا. ايپليڪيشن سرور پاڻ ڪيترن ئي وسيلن سان ڪنيڪشن برقرار رکي سگهن ٿا، مثال طور، هڪ ڊيٽابيس. انهي حالت ۾، اسان جي سرورٽ شايد اهڙي ڪنيڪشن پاڻ کي نه کولي، پر صرف ان کي ايپليڪيشن سرور کان وٺي. هڪ سروليٽ ڪنٽينر ۾، اهو ناممڪن آهي، ڇاڪاڻ ته ... هڪ ڪنٽينر آهي، هڪ خاص حد تائين، هڪ اسٽريپ ٿيل ايپليڪيشن سرور. هڪ ڪنٽينر ۾، هڪ servlet هميشه ڊيٽابيس سان ڪنيڪشن ٺاهڻ گهرجي. ڪجهه هن طرح... war-archive جنگ-آرڪائيو ڇا آهي؟ WAR ويب آرڪائيو آهي. حقيقت ۾، اهو صرف هڪ زپ فائل آهي، ڪنهن به جار وانگر. بنيادي طور تي، اهو صرف هڪ طريقو آهي اسان جي ويب سائيٽ کي ڪرم ڪرڻ جو، ڪيترن ئي ويب صفحن تي مشتمل آهي، jsp صفحا ۽ سرور ڪلاس، هڪ زپ فائل ۾. web.xml web.xml نام نهاد مقرري بيان ڪندڙ آهي. هي هڪ فائل آهي جيڪا بيوقوفيءَ سان بيان ڪري ٿي ته ڪهڙي ويب برائوزر لائن کي پروسيسنگ لاءِ ڪهڙي سرورٽ ڪلاس ڏانهن موڪلڻ جي درخواست ڪئي وئي آهي، انهي ڪري ته سرورٽ ڪنٽينر مونجهارو نه ٿئي، ڪهڙي سرورٽ ڪهڙي ذميوار آهي. عام طور تي، جاوا ۾ اهو تمام فيشن آهي ته سيٽنگون بيان ڪرڻ لاء سڀني قسمن جي xml فائلن ۾، پر تازو هن روايت کان پري وڃڻ جو رجحان آهي. ڪيئن، توهان پڇو؟ ۽ تشريح ذريعي. تشريح ڪلاس پاڻ ڪجھ به نه ڪندا آھن؛ اھي صرف ٺاھيا ويا آھن سڀني قسمن جي سيٽنگن کي بيان ڪرڻ لاءِ (ميٽا ڊيٽا) الڳ xml فائل ۾ نه پر سڌو ڪوڊ ۾. بلڪل آرام سان. بهرحال، هاڻي اتي هڪ خاص وچولي اسٽيج آهي، جڏهن ڪجهه سيٽنگون بيان ڪيل آهن، ۽ ڪجهه xml ذريعي، ۽ اهو مونجهارو ٿي سگهي ٿو، ڇاڪاڻ ته توھان ڏسو xml ۽ ھڪڙي سيٽنگ ڏسو، پر تشريح جي مطابق ھڪڙو ٻيو آھي. جنهن کي سڀ کان وڌيڪ ترجيح آهي؟ ڪير ڄاڻي…

نتيجو

هي لکڻ کان پوءِ، مون سوچيو ته اهڙو تڪڙو جائزو ڪنهن جي به مدد نه ڪندو، ڇاڪاڻ ته... نه ته ڪا خاص وضاحت آهي ۽ نه مثال، پر ٻئي طرف، جيڪو لکيو ويو آهي، ان کي نه هٽايو، تنهنڪري اهو ٿيڻ ڏيو.