پیتھوس کے بغیر۔ آئیے جاوا ای ای، سرولیٹس اور ان کے کنٹینرز کے بارے میں بات کرتے ہیں۔

اس موضوع میں، میں servlets کے بارے میں اپنی سمجھ کے بارے میں واضح طور پر بات کرنا چاہوں گا، سرولیٹ کنٹینرز کون سے ہیں، سب سے زیادہ کیا، اگر سب نہیں، ویب فرنٹ اینڈ فریم ورکس ہیں، اور اس موضوع پر بھی بات کرنا چاہوں گا کہ سرولیٹ کنٹینرز اور ایپلیکیشن سرورز کس طرح سے تعلق رکھتے ہیں۔ ایک دوسرے، اور سرولیٹ اور ویب سرور کنٹینرز۔ بات چیت شروع کرنے سے پہلے، میں یہ نوٹ کرنا چاہتا ہوں کہ میں واقعی توقع کرتا ہوں کہ بحث ہوگی، کیونکہ... یہاں میں کوڈ کا ایک ٹکڑا نہیں دینا چاہتا، بلکہ صرف اس جوہر کو چھونا چاہتا ہوں، جسے ہمیشہ الفاظ میں بیان کیا جا سکتا ہے۔ میں ان تمام نکات کا خاکہ پیش کرنے کی کوشش کروں گا جو مجھے پہلی بار شروع کرتے وقت واضح نہیں تھے۔ جب میں نے مختلف فورمز پر اس موضوع پر سوالات پوچھے کہ Tomcat servlet کنٹینر کسی بھی ایپلیکیشن سرور سے کس طرح مختلف ہے، WebSphere یا Geronimo کا کہنا ہے کہ، صرف وہ لوگ جنہوں نے جواب دینے کی ہمت کی وہ گدھے تھے جو "ویکیپیڈیا کو دیکھو" یا "" کے علاوہ کچھ نہیں کہہ سکتے تھے۔ یہ کہنا مشکل ہے، سرور ایپلی کیشنز - یہ کارپوریٹ ایپلی کیشنز کے لیے ایک پیچیدہ انفراسٹرکچر ہے، جو..." blah blah blah. میں ایسے لوگوں کو برداشت نہیں کر سکتا اور میرا اندازہ ہے کہ آپ میں سے اکثر ایسا بھی نہیں کرتے۔ ہم تاریخی ناانصافی کو دور کریں گے۔ جاؤ…

سرولیٹس

اس سے کوئی فرق نہیں پڑتا ہے کہ کوئی کیا کہتا ہے، ایک سرولیٹ جاوا میں لکھا ہوا ایک ویب صفحہ ہے۔ کچھ لوگ کہیں گے کہ میں غلط ہوں اور یہ کہ سرولیٹ ایک ویب ایپلیکیشن ہے اور ان تصورات میں فرق ہے، لیکن ایسا نہیں ہے۔ اب کوئی فرق نہیں ہے، اور PHP میں لکھی گئی سائٹس کو محفوظ طریقے سے ویب ایپلیکیشنز بھی کہا جا سکتا ہے۔ اب یہ بالکل فطری ہے، کیونکہ... php مکمل طور پر OOP کو سپورٹ کرتا ہے، اور CMSs جیسے جملہ فعال طور پر اسے استعمال کرتے ہیں۔ کوڈ کی سطح پر سرولیٹ کیا ہے؟ یہ ایک ایسی کلاس ہے جس میں بہت سے طریقے ہیں جو سوتے ہیں اور دیکھتے ہیں کہ آیا کوئی GET یا POST HTTP درخواستوں کے ذریعے ان تک رسائی حاصل کرتا ہے۔ وہ. ہم نے براؤزر میں کچھ GET درخواست ٹائپ کی، سرولیٹ کلاس کا متعلقہ طریقہ اسے قبول کرتا ہے اور پھر HTML صفحہ کی شکل میں اس کا جواب تیار کرتا ہے۔ ایک سرولیٹ کے کلاسیکی معنی میں، جیسا کہ یہ سن کے ذریعے تصور کیا گیا تھا، اس صفحہ کو لائن کے ذریعے کلائنٹ لائن کو بھیجا گیا تھا، جو لائن <!DOCTYPE htm>> سے شروع ہوتا تھا اور لائن </html> پر ختم ہوتا تھا۔ تو جاوا میں ایک بنیادی سرولیٹ کلاس ہے جسے کہتے ہیں Servlet۔ اس کے علاوہ، دوسری کلاسوں کا ایک گروپ ہے جو اس بیس کلاس سے وراثت میں ملتا ہے اور اس طرح اس کی فعالیت کو بڑھاتا ہے۔ یہ وہی ہے جو ایک سرولیٹ ہے - اس سے زیادہ کچھ نہیں۔ یہ پی ایچ پی کوڈ کا صرف ایک جاوا اینالاگ ہے، جسے سرور پر بھی لاگو کیا جاتا ہے، اور صرف ویب براؤزر کی درخواست کا جواب ویب صفحہ کی صورت میں کلائنٹ کو بھیجا جاتا ہے۔ تمام

ویب فرنٹ اینڈ فریم ورک

سب ٹائٹل پیچیدہ ہے اور عام طور پر وہ صرف فرنٹ اینڈ فریم ورک یا یہاں تک کہ ویب muzzle لکھتے ہیں، لیکن میں نے یہاں اس بات پر زور دینے کا فیصلہ کیا کہ جب ہم فرنٹ اینڈ فریم ورک کے بارے میں بات کرتے ہیں، تو ہم ویب براؤزر کے ذریعے جاوا کے ساتھ کام کرنے کے لیے GUI کے بارے میں بات کر رہے ہیں۔ وہ. یہاں پھر ہم جاوا میں ویب سائٹس کے بارے میں بات کر رہے ہیں، یعنی سرولیٹ کے بارے میں تقریباً کوئی فرنٹ اینڈ فریم ورک کیا ہے، مثال کے طور پر، اپاچی سٹرٹس۔ یہ صرف کلاسوں کا ایک سیٹ ہے جو بیس کلاس کو بڑھاتا ہے Servlet۔ بس مزید کچھ نہیں. وہ. ایک ہی باقاعدہ سرولیٹ بنانے کا یہ صرف ایک مختلف طریقہ ہے۔ یہ صرف اتنا ہے کہ اس فریم ورک کے ڈویلپرز (یا دوسرے لفظوں میں، اس ٹیکنالوجی کے ڈویلپرز) نے غور کیا کہ Servletکچھ طریقوں کے ساتھ ان کی بیس کلاس کا اضافہ پروگرامر کے لیے اس معمولی فعالیت کے مقابلے زیادہ آسان ہوگا جو سن/اوریکل سے کلاسک سرولیٹ۔ ہے

JSP صفحات

تقریباً فوراً ہی، جاوا سرولیٹ تصور کے ڈویلپرز کے ذہن میں ایک اور خیال آیا۔ چونکہ ہم ایک سرولیٹ لکھ رہے ہیں، جس کا کام کلائنٹ کو ایک HTML صفحہ بھیجنا ہے، تو اس HTML صفحہ کو فوری طور پر لکھنا زیادہ درست ہو سکتا ہے، اور اگر آپ کو جاوا میں کسی قسم کی منطق کی ضرورت ہے، تو اسے براہ راست داخل کریں۔ html میں اگر یہ واضح نہیں ہوتا ہے، تو اس جملے سے مدد مل سکتی ہے: jsp صفحہ پی ایچ پی صفحہ کا ایک اینالاگ ہے۔ مشکل؟ پھر میں دوبارہ وضاحت کروں گا۔ پی ایچ پی میں صفحہ لکھتے وقت ہم کیا کرتے ہیں؟ ہمارے پاس static html ہے، اور جب ہمیں پی ایچ پی میں کوئی منطق داخل کرنے کی ضرورت ہوتی ہے جیسے لوپس اور حالات، ہم اسے ٹیگ کے باڈی میں داخل کرتے ہیں <?php … ?>۔ jsp کے ساتھ سب کچھ ایک جیسا ہے، صرف منطق خالص جاوا میں لکھی جاتی ہے، جس کا کوڈ ٹیگ کے باڈی میں داخل ہوتا ہے <% … %>۔ آئیے ایک بار پھر سرولیٹ کے تصور کی طرف لوٹتے ہیں۔ جوہر میں، ایک JSP صفحہ ایک سرولیٹ ہے، لیکن قدرے مختلف انداز میں لکھا گیا ہے۔ ایک باقاعدہ سرولیٹ میں، ہم ایک ایسا طریقہ لکھتے ہیں جو کچھ منطق انجام دیتا ہے اور اس کے نتائج کی بنیاد پر، کلائنٹ کے لیے ایک HTML صفحہ تیار کرتا ہے۔ یہ صرف اتنا ہے کہ کچھ عرصے کے بعد، سرولیٹ ڈویلپرز نے سوچنا شروع کیا: اگر اس طریقہ کار میں عملی طور پر کوئی منطق نہ ہو، اور تقریباً صرف ایک HTML صفحہ کی تشکیل ہوتی ہے، تو کیا فوری طور پر ایک html صفحہ لکھنا آسان نہیں ہو گا؟ کم سے کم جاوا داخل کرنے کے لیے کون سا کوڈ۔ ٹھیک ہے، jsp صفحات کے بارے میں ایک آخری چیز۔ پہلی بار جب اس طرح کے صفحے تک رسائی حاصل کی جاتی ہے، تو اسے ایک سرولیٹ میں مرتب کیا جاتا ہے اور پھر اس پر عمل درآمد کیا جاتا ہے۔ اس jsp صفحہ پر آنے والی درخواستیں تیز تر ہوں گی کیونکہ یہ پہلے سے ہی مرتب کیا جائے گا اور صرف اس پر عمل درآمد کرنے کی ضرورت ہوگی۔

سرولیٹ کنٹینر

تو ہم نے ایک سرولیٹ کلاس یا JSP صفحہ لکھا۔ اس کے بعد کیا ہے؟ اپاچی کا کہنا ہے کہ انہیں ویب سرور میں کیسے دھکیلنا ہے، تاکہ یہ انہیں صارف کے ویب براؤزر پر بھیج سکے۔ ویب سرور صرف ایچ ٹی ایم ایل بھیج سکتا ہے، اور اگر ہمارے صفحہ میں پی ایچ پی کوڈ ہے، تو ویب سرور پہلے صفحے کو ایک مترجم کے ذریعے منتقل کرتا ہے جو پی ایچ پی کو ایچ ٹی ایم ایل میں ترجمہ کرتا ہے، اور تب ہی نتیجہ کلائنٹ کو بھیجا جاتا ہے۔ servlets کے ساتھ بھی ایسا ہی ہوتا ہے - بھیجنے سے پہلے، HTML صفحہ تیار کرنے کے لیے انہیں عمل میں لانا ضروری ہے، اور servlet کنٹینر بالکل وہی چیز ہے جو servlets اور jsp صفحہ کوڈ کو چلانے کے لیے ذمہ دار ہے۔ وہ. جاوا کے لیے ایک سرولیٹ کنٹینر ویب سرور میں پی ایچ پی انٹرپریٹر ماڈیول کا اینالاگ ہے۔ اس طرح، جب صارف ویب براؤزر میں ایک ایڈریس داخل کرتا ہے، درخواست ویب سرور کو بھیجی جاتی ہے، ویب سرور سمجھتا ہے کہ ایک سرولیٹ کی درخواست کی جا رہی ہے اور وہ درخواست کو سرولیٹ کنٹینر کو بھیج دیتا ہے۔ اس کے بعد، servlet کنٹینر servlet کو انجام دیتا ہے، نتیجے میں HTML صفحہ کو ویب سرور کو بھیجتا ہے، جس کے نتیجے میں، اسے کلائنٹ کو واپس کر دیا جاتا ہے۔ کیا ایک سرولیٹ کنٹینر خود چل سکتا ہے، یعنی ویب سرور کے بغیر؟ Tomcat کی طرح کچھ یقینی طور پر کر سکتا ہے. اور اگر ہم ایک ایسی سائٹ بنانا چاہتے ہیں جس میں servlets پر مبنی صفحات کے علاوہ کوئی اور html پیجز نہ ہوں تو ہمارے لیے ایک سرولیٹ کنٹینر کافی ہے۔ لیکن اگر ہم servlets سے کسی سائٹ کو یکجا کرنا چاہتے ہیں اور، کہہ لیں، PHP صفحات، تو ہمیں ایک ویب سرور انسٹال کرنا پڑے گا۔ مزید یہ کہ، تمام ویب سرورز میں بطور ڈیفالٹ ایک سرولیٹ کنٹینر شامل نہیں ہوتا ہے، لیکن تقریباً سبھی آپ کو اسے بطور پلگ ان انسٹال کرنے کی اجازت دیتے ہیں۔ اس لیے، اگر ہم اپنی ویب سائٹ کو انٹرنیٹ پر کسی ایسی ہوسٹنگ پر شروع کرنا چاہتے ہیں، جہاں اپاچی غالباً چلتی ہے، تو ہمیں فراہم کنندہ سے پوچھنا پڑے گا کہ آیا سرولیٹ کنٹینر منسلک ہے۔

جاوا ای ای

نام نہاد JavaSE (جاوا سٹینڈرڈ ایڈیشن) ہے۔ اس تصور میں تمام کلاسز شامل ہیں java، جن کے استعمال کے لیے ہمیں صرف انہیں درآمد کرنے کی ضرورت ہے (مثال کے طور پر، java.util.Date) یا یہاں تک کہ ایسا کرنے کی ضرورت نہیں ہے (مثال کے طور پر، Stringچونکہ یہ پیکیج میں واقع ہے java.lang)۔ اور جاوا ای ای (جاوا انٹرپرائز ایڈیشن) ہے۔ یہ کلاسز بھی Sun/Oracle سے تعلق رکھتی ہیں، لیکن فرق صرف یہ ہے کہ ان کا کسی پروجیکٹ میں استعمال شروع کرنا زیادہ مشکل ہے۔ ایک سادہ سی لائن import…کافی نہیں ہوگی، کیونکہ... پروجیکٹ مرتب نہیں کرے گا۔ صورت حال کو درست کرنے کے لیے، آپ کو javaee.jar لائبریری فائل کو تلاش کرنا اور اسے پروجیکٹ میں شامل کرنا ہوگا۔ یہ ترقیاتی ماحول میں پروجیکٹ کی خصوصیات کے ذریعے کیا جاسکتا ہے۔ یہ اکثر کہا جاتا ہے کہ اس کنکشن کے عمل کو کہا جاتا ہے: پروجیکٹ کے بلڈ پاتھ یا کلاس پاتھ میں جار کا عرفی نام رجسٹر کریں۔

ایپلی کیشنز سرور

اب تصور کریں کہ ہم نے اپنا سرولیٹ پروجیکٹ مرتب کیا ہے جو جاوا EE استعمال کرتا ہے۔ سب کچھ بہت اچھا ہے، لیکن اب ہمیں اپنی مرتب شدہ کلاسز کو سرولیٹ کنٹینر میں رکھنے کی ضرورت ہے۔ آئیے کہتے ہیں کہ انہوں نے یہ کیا۔ کیا ہماری درخواست کام کرے گی؟ اس کا جواب نہیں ہے۔ سرولیٹ تک رسائی حاصل کرتے وقت، مستثنیات پھینک دی جائیں گی جو اس بات کی نشاندہی کرتی ہیں کہ کچھ کلاسیں نہیں ملی تھیں۔ کیوں؟ کیونکہ ہم نے کمپائلر کو پھسل کر "دھوکہ" دیا javaee.jar в classpath، یعنی کمپائلر نے دیکھا کہ جاوا EE کی کلاسیں اپنی جگہ پر تھیں اور پرسکون ہو گئیں، لیکن سرولیٹ کنٹینر ان کلاسوں کو نہیں دیکھتا، لیکن وہ ہمارے سرولیٹ سے ان کے لنکس دیکھتا ہے۔ کیا یہ صورت حال ایک سرولیٹ کنٹینر کے اندر قابل حل ہے؟ بالکل ہاں، آپ کو صرف javaee.jar لائبریری فائل کو سرورلیٹ کنٹینر میں ہمارے سرولیٹ کے ساتھ فولڈر میں شامل کرنے کی ضرورت ہے ۔ اب تصور کریں کہ ایسے بہت سے منصوبے ہوں گے اور وہ سب ایک ٹامکیٹ سرولیٹ کنٹینر میں چل رہے ہیں۔ اس کا مطلب یہ ہے کہ آپ کو اس جار فائل کو ہر سرولیٹ کے فولڈر میں کاپی کرنا پڑے گا۔ یہ تکلیف دہ اور غلط ہے۔ اس صورت حال کو ایک ایپلیکیشن سرور کا تصور متعارف کروا کر حل کیا گیا، جس میں یہ فائل طویل عرصے سے ایک کاپی میں ہے، اور تمام سرولیٹ اس تک رسائی حاصل کر سکتے ہیں، اور ان کی اپنی کاپی نہیں ہے۔ میری رائے میں، یہ بہت آسان اور منطقی ہے. قدرتی طور پر، تمام گڑبڑ ایک جار فائل کی وجہ سے نہیں ہے (میں نے اسے ایک مثال کے طور پر دیا) - ایسی بہت سی فائلیں ہیں۔ لیکن یہ سب کچھ نہیں ہے جو ایپلیکیشن سرورز ہمیں دیتے ہیں۔ ایپلیکیشن سرورز خود بہت سے وسائل سے کنکشن برقرار رکھ سکتے ہیں، مثال کے طور پر، ڈیٹا بیس۔ اس صورت میں، ہمارا سرولیٹ ایسا کنکشن خود نہیں کھول سکتا ہے، لیکن اسے صرف ایپلیکیشن سرور سے لے سکتا ہے۔ ایک سرولیٹ کنٹینر میں، یہ ناممکن ہے، کیونکہ... ایک کنٹینر، ایک خاص حد تک، ایک سٹرپڈ ڈاؤن ایپلی کیشن سرور ہے۔ ایک کنٹینر میں، ایک سرولیٹ کو ہمیشہ ڈیٹا بیس سے ہی کنکشن بنانا چاہیے۔ کچھ اس طرح... war-archive جنگی ذخیرہ کیا ہے؟ جنگ ویب آرکائیو ہے۔ درحقیقت، یہ کسی بھی جار کی طرح صرف ایک زپ فائل ہے۔ بنیادی طور پر، یہ ہماری ویب سائٹ کو ایک زپ فائل میں ڈھالنے کا صرف ایک طریقہ ہے، جس میں بہت سے ویب صفحات، jsp صفحات اور سرولیٹ کلاسز شامل ہیں۔ web.xml web.xml نام نہاد تعیناتی کی وضاحت کنندہ ہے۔ یہ ایک فائل ہے جو احمقانہ طور پر بیان کرتی ہے کہ کس ویب براؤزر لائن کی درخواست کو پروسیسنگ کے لیے کس سرولیٹ کلاس کو بھیجنا ہے، تاکہ سرولیٹ کنٹینر کو الجھن نہ ہو، کون سا سرولیٹ کس چیز کے لیے ذمہ دار ہے۔ عام طور پر، جاوا میں ہر طرح کی xML فائلوں میں سیٹنگز کو بیان کرنا بہت فیشن ہے، لیکن حال ہی میں اس روایت سے ہٹنے کا رجحان پیدا ہوا ہے۔ کیسے، آپ پوچھتے ہیں؟ اور تشریحات کے ذریعے۔ تشریح کی کلاسیں خود کچھ نہیں کرتی ہیں؛ وہ صرف ہر قسم کی ترتیبات (میٹا ڈیٹا) کو الگ XML فائل میں نہیں بلکہ براہ راست کوڈ میں بیان کرنے کے لیے بنائی گئی ہیں۔ بہت آرام سے۔ تاہم، اب ایک خاص انٹرمیڈیٹ مرحلہ ہے، جب کچھ سیٹنگز کو تشریحات کے ذریعے اور کچھ کو xml کے ذریعے بیان کیا جاتا ہے، اور یہ مبہم ہوسکتا ہے، کیونکہ آپ xml کو دیکھیں اور ایک ترتیب دیکھیں، لیکن تشریحات کے مطابق ایک اور ترتیب ہے۔ کس کو سب سے زیادہ ترجیح حاصل ہے؟ کسے پتا…

نتیجہ

یہ لکھنے کے بعد، میں نے سوچا کہ اس طرح کا فوری جائزہ کسی کے کام نہیں آئے گا، کیونکہ... نہ کوئی تصریح ہے اور نہ کوئی مثال، لیکن دوسری طرف جو لکھا ہے اسے مت مٹائیں، تو اسے رہنے دیں۔