Working of HTTP Protocol – Evolution of Web Applications

Working of HTTP Protocol – Java आधारित Web Applications Develop करने के बारे में विस्तार से जानने से पहले इस बात को समझना कि तकनीकी रूप से Web किस तरह से काम करता है, एक Web Developer के रूप में हमारे लिए काफी जरूरी व महत्वपूर्ण होता है क्‍योंकि जब तक हम Web की Working यानी कार्यप्रणाली को ठीक से नहीं समझते, तब तक हम उपयोगी व Robust Web Applications Develop नहीं कर सकते। इसलिए इस Chapter में हम Web व उससे सम्बंधित विभिन्न Technologies की कार्यप्रणाली को ही बेहतर तरीके से समझने की कोशिश करेंगे।

Evolution of Web Applications

World Wide Web के सन्दर्भ में एक सबसे महत्वपूर्ण बात ये रही है कि इसे कभी भी Application Environment की तरह विकसित करने के बारे में सोंचा ही नहीं गया था। यानी Web को विकसित करते समय कभी इस बात की कल्पना भी नहीं की गई थी कि कभी इस पर आधारित Applications भी Develop किए जाऐंगे। लेकिन वर्तमान समय में इसे मूलत: E-Commerce Use हेतु ही सर्वाधिक Use किया जाता है जो कि एक प्रकार का Web आधारित Application ही होता है और पुस्तक के इस Section में हम Web के विकास व उसकी कार्यप्रणाली के बारे में ही कुछ Basic ज्ञान प्राप्त करेंगे, ताकि हम Web Applications व उसके Development की प्रक्रिया को ज्यादा बेहतर तरीके से समझ सकें।

World Wide Web जिसे वर्तमान समय में सामान्यत: केवल Web के नाम से ही Refer किया जाता है तथा HTTP (HyperText Transfer Protocol), इन दोनों को 1990 के दौरान CERN नाम की European Laboratory में Tim Berners-Lee नाम के Physicist द्वारा विकसित किया गया था और इस System को मूल रूप से CERN के अन्दर ही विभिन्न वैज्ञानिकों द्वारा एक-दूसरे के Research Work Documents की Sharing करने के लिए Use किया जाता था।

लेकिन 1993 के दौरान जब Internet को Public Use के लिए पूरी तरह से Available करवा दिया गया, तो Mosaic नाम के Web Browser के विकास के साथ ही Web का Commercial Use होना सम्भव हो गया, जिसकी वजह से Web आम लोगों के लिए उपयोगी साबित हो सका और आम लोगों की जरूरतों को पूरा करने के लिए Different प्रकार के Web Applications बनाए जाने की जरूरत पैदा हुई ताकि जो Business पहले पूरी तरह से Offline हुआ करते थे, उन्हें Online किया जा सके और Internet व Web के माध्‍यम से ज्यादा से ज्यादा लोगों तक पहुंचाया जा सके।

Web को Application Environment की तरह Develop करने का विचार समय के साथ लोगों की विभिन्न प्रकार की जरूरतों को पूरा करने की जरूरत के कारण विकसित हुआ क्‍योंकि Internet व Web तक जैसे-जैसे लोगों की पहुंच बढ़ने लगी, लोगों की Internet व Web से सम्बंधित मांग भी बढ़ने लगी। इस मांग को पूरा करने के लिए विभिन्न प्रकार की तकनीकों को विकसित किया जाना जरूरी होता गया और इस मांग की पूर्ति के रूप में Web Server के रूप में सबसे पहली तकनीक विकसित हुई।

इस तकनीक के अन्तर्गत एक ऐसा Environment विकसित किया गया था, जिसकी वजह से User Web Browser जैसे किसी Client Application के माध्‍यम से किसी Static Document के लिए Request Perform करता था और Web Server उस Static Document को Response के रूप में Client Web Browser को Serve कर देता था। इस तरह से Serve किए जाने वाले Document का Content तब तक Change नहीं होता था, जब तक कि कोई Human Author उस Document के Content को Manually Modify करके उसका एक नया Version Create नहीं कर देता था।

Client Web Browser व Web Server के बीच के Static Documents के Transaction से सम्बंधित इस Environment या Architecture को Client-Server Architecture के नाम से जाना जाता है और इस Model को हम निम्नानुसार भी Describe कर सकते हैं-

Working of HTTP Protocol – Evolution of Web Applications – Core JSP in Hindi

इस Client/Server Architecture में HTTP ही वह Protocol होता था जो Client व Server के बीच Request/Response Cycle को Maintain करते हुए Webpages व विभिन्न प्रकार के अन्‍य Resources जैसे कि Image, Sound, Audio, Video आदि को Client व Server के बीच Transfer करता था और इसीलिए इस HTTP Protocol को सामान्यत:Request/Response Protocol भी कहा जाता था।

Request/Response Cycle के दौरान Web Browser के माध्‍यम से User किसी Document के लिए Web Server से (GET या POST Method के माध्‍यम से) Request करता था और Web Server उस Requested Document को अपने Server Computer पर Search करता था। यदि वह Requested Document, Server Computer पर Physically Exist होता था, तो उस Request के Response के रूप में उस Physical Document को एक Success Status Code के साथ Send करते हुए Client Web Browser की Request को Fulfill कर दिया जाता था।

लेकिन यदि Client Web Browser द्वारा Requested Document, Web Server को Server Computer पर Physically प्राप्‍त नहीं होता था, तो उस स्थिति में भी Web Server, Client Web Browser को Response के रूप में एकFailure Status Code के साथ Error Message Return कर देता था।

चूंकि, HTTP Protocol के माध्‍यम से Response के रूप में Web Server, Client Web Browser को जो Response Send करता था, वह Response सामान्यत: एक HTML Document ही होता था, इसलिए Web Browser की Request को Fulfill करने के लिए Web Server उसे Response के रूप में Server Computer पर पहले से Physically Exist Static Document Send कर रहा था अथवा उस Document के HTML Markups को Dynamically Generate करके Send कर रहा था, इस बात का न तो Web Browser को पता चलता था न ही उसे इस बात की जानकारी रखने की जरूरत होती थी, बल्कि Web Browser को तो केवल इस बात से मतलब होता था कि जिस HTML Document के लिए उसने Web Server पर Request Send किया था, उसके बदले में उसे प्राप्त होने वाला Response Success Status Code के साथ आ रहा था या Failure Status Code के साथ और इस Status Code के आधार पर ही Web Browser, Response के रूप में Web Server से आने वाले HTML Markup Stream को Treat करता था।

हालांकि HTTP Protocol के माध्‍यम से Client/Server Architecture के काम करने का तरीका आज भी यही है। लेकिन HTTP Protocol के Request/Response Cycle की इस प्रकार की Working से उस समय के Developers के दिमाग में ये विचार आया कि जब इस बात से कोई फर्क ही नहीं पडता कि User ने Client Web Browser के माध्‍यम से जिस Document के लिए Request Perform किया है, वह Document, Server Computer पर Physically Exist है या नहीं, तो Requested Document का Static Document की तरह Server Computer पर Physically Exist होना भी जरूरी नहीं है, बल्कि उस Document के HTML Markups को Server Computer द्वारा Programmatically भी Generate किया जा सकता है तथा इस Programmatically Generated HTML Markups को Success Status Code के साथ Client Web Browser को Response के रूप में Send किया जा सकता है।

यही विचार आगे चलकर Server Side Programming Languages के Development का आधार बना क्‍योंकि इन Server Side Programming Languages के माध्‍यम से Client Web Browser की Request को पूरा करने के लिए HTML Markups को Dynamically Generate किया जाना सम्भव हो सकता था। परिणामस्वरूप सबसे पहली Server Side Scripting Languages Perl का विकास किया गया जो कि मूलत: Text-Processing से सम्बंधित Scripting Language था और इसका विकास इसी बात को ध्‍यान में रखते हुए किया गया था कि Client Web Browser को Send किया जाने वाला HTML Markup किस तरह से Server Side द्वारा Dynamically Generate किया जा सके।

HTTP Protocol की उपरोक्तानुसार Discussed Server Side विशेषता के अलावा एक Client-Side विशेषता भी थी, जिसके अन्तर्गत एक User के रूप में हम Client Web Browser के माध्‍यम से Perform की जाने वाली Request के साथ Web Server को URL में Exist Query String द्वारा अथवा Data Stream के रूप में Extra Parameters भी Pass कर सकते थे और Web Server इन Extra Parameters के आधार पर Dynamic तरीके से Different Response Generate कर सकता था।

क्‍योंकि इन Extra Parameters को Server Side Scripting Language द्वारा Server Computer पर Installed किसी Database Server पर एक SQL Query Parameters के रूप में Pass किया जा सकता था, जिसे Execute करके वह Database Server Different Parameters के आधार पर Different Resultsets Generate कर सकता था और इस Generated Resultset को फिर से Server Side Scripting Languages द्वारा Use करते हुए, Web Browser को Response के रूप में Send किए जाने वाले HTML Markups को Dynamically Generate किया जा सकता था।

Read also: Web Browser War

HTTP Protocol के Client-Side से Parameters Send कर सकने की विशेषता के कारण ही HTTPd Web Server का विकास किया गया, जो कि Client Side से आने वाले Parameters के आधार पर Server Side में Installed Database Servers पर Fire की जा सकने वाली SQL Queries Create कर सकता था और इन SQL Queries के आधार पर Generate होने वाले Resultsets को Use करते हुए Response के रूप में Send किए जाने वाले HTML Markupsको Generate कर सकता था।

HTTP Protocol, Server Side Scripting Language (Perl) व Server Side Database से Interaction करते हुए Database आधारित Dynamic Webpages Generate कर सकें, इस हेतु CGI (Common Gateway Interface) Specification को Design करने की जरूरत पड़ी, क्योंकि HTTP, Perl व HTTPd Web Server के Combined रूप को ही CGI के नाम से जाना गया था, जो कि Database आधारित Dynamic Web Applications के Development की शुरूआत बना था।

CGI Programs (Perl व HTTPd Web Server के Combined Form पर आधारित Programs) को किसी Specific प्रकार की Request को Fulfill करते हुए Response करने के लिए Web Server द्वारा Invoke किया जाता था। सामान्यत: ये उन Files या Directories को Access करने से सम्बंधित Requests होते थे, जिनका Extension .cgi होता था।

साथ ही इन Request के साथ Pass होने वाले Parameters Key/value Pair के रूप में तथा Request Headers, Environment Variables के रूप में Web Server पर पहुंचते थे, जहां Web Server का CGI Program इन Parameters व Headers को Application से सम्बंधित Processing Perform करने के लिए उपयोग में ले लेता था।

यानी इन Parameters व Headers के रूप में Web Server पर आने वाले Data को Underlying Database पर SQL Queries में Use कर लिया जाता था, ताकि Request के साथ आने वाले Parameters के आधार पर Underlying Database से Appropriate Resultset Generate किए जा सकें।

फिर Underlying Database से Return होने वाले Resultset को Use करते हुए Response के रूप में Return किए जाने वाले HTML Markups को Generate किया जाता था और अन्त में इस Dynamically Generated HTML Document को Response के रूप में फिर से Client Web Browser को Send कर दिया जाता था। इस पूरी प्रक्रिया को हम निम्न चित्र के रूप में भी Represent कर सकते हैं-

Working of HTTP Protocol - Evolution of Web Applications - Core JSP in Hindi

Working of HTTP Protocol – Evolution of Web Applications – Core JSP in Hindi

हालांकि HTML Markups के रूप में Dynamically HTTP Response Generate करने हेतु CGI काफी सुविधाजनक तकनीक थी लेकिन इस तकनीक की अपनी एक महत्वपूर्ण कमी भी थी, जिसके अन्तर्गत प्रत्येक HTTP Request को Fulfill करने के लिए Web Server एक नया Process Create करता था।

हालांकि जब तक CGI आधारित Website का Traffic कम होता था, तब तक कोई बहुत बड़ी समस्या पैदा नहीं होती थी लेकिन जब Website का Traffic काफी ज्यादा होने लगता था, तब प्रत्येक Request को Fulfill करने के लिए Web Server पर एक नया Process Create होना अपने आप में एक जटिल समस्या के रूप में सामने आने लगता था।

यानी CGI तकनीक पर आधारित Website या Web Application को Large-Scale Application की तरह Develop नहीं किया जा सकता था, क्‍योंकि एक Large-Scale Application को समान समय पर समानान्तर रूप से हजारों लोग एक साथ Use कर रहे हो सकते थे और इस स्थिति में किसी भी समय पर समानान्तर रूप से हजारों Requests को Response करने के लिए Web Server पर हजारों Separate Processes Create हो सकते थे, जिससे Web Server पर काफी ज्यादा Load पडता था तथा इतनी ज्यादा मात्रा की Requests को Handle करने के लिए Web Server के Resources की मात्रा को भी काफी ज्यादा बढ़ाना पडता था, जो कि Economically काफी महंगा होता था।

Read also: What is TCP/IP Protocol

इसलिए CGI तकनीक की इस समस्या के समाधान के रूप में 1997 में Sun Microsystems द्वारा Java Servlet API को Release किया गया और जल्दी ही इस API के आधार पर JSP (Java Server Pages) API को Release किया गया, जिससे Java आधारित Dynamic Web Application Development की तकनीक काफी आसान हो गई।

इन दोनों Related Technologies की वजह से Java Programming Language को उसकी पूर्ण क्षमता के साथ Dynamic Web Applications Develop करने के लिए Use किया जाना सम्भव हो गया था, क्‍योंकि Java अपने आप में एक पूर्ण Programming Language थी जिसके माध्‍यम से सम्पूर्ण Desktop Applications Develop करने हेतु विभिन्न प्रकार की जरूरतों को आसानी से पूरा करने के लिए विभिन्न प्रकार के APIs (Application Programming Interfaces) जैसे कि Database Connectivity, Network Access, Multithreaded Operations आदि को Develop किया गया था और Java Servlet API तथा JSP API के माध्‍यम से इन APIs को बिना कोई Change किए हुए ज्‍यों का त्यों Web Applications Develop करने हेतु भी उपयोग में लिया जा सकता था।

यानी यदि आप Java जानते थे, तो इन दोनों APIs के माध्‍यम से आप बड़ी ही आसानी से अपने Java आधारित Desktop Application Development के ज्ञान को Dynamic Web Applications Develop करने के लिए भी Use कर सकते थे। साथ ही Java Multithreading तकनीक का प्रयोग करते हुए एक Single Process द्वारा Multiple Requests को समानान्तर रूप से Handle करने की क्षमता भी प्राप्त कर सकते थे।

इसीलिए जैसे ही Java Servlet व JSP API को Release किया गया, CGI के स्थान पर Developers, Java को Dynamic Web Applications Develop करने हेतु प्राथमिकता के साथ Use करने लगे और हमें एक Perfect Web Development Model प्राप्त हो सका।

Java आधारित Web Development Architecture को यदि हम एक Simple चित्र के रूप में Represent करें, तो हमारा Representation कुछ निम्नानुसार हो सकता है-

Read also: Configuring IIS for ASP.NET Applications

Working of HTTP Protocol – Evolution of Web Applications – Core JSP in Hindi

JSP Pages Memory में Exist एक Single Instance के रूप में Operate होते हैं, जबकि Multiple Requests को समानान्तर रूप से Handle करने के लिए एक Single Process में Multiple Java Threads Run हो रहे होते हैं और जैसाकि उपरोक्त चित्र द्वारा हम समझ सकते हैं कि Java Servlet व JSP Pages, दोनों ही तकनीकें Java आधारित Large-Scale Powerful Web Applications Develop करने के लिए J2EE(Java 2 Enterprise Edition) Environment को सम्पूर्णता के साथ Use कर सकते हैं।

हालांकि जब Java Servlet व JSP API को Release किया गया था, तब CGI प्रत्येक Request को Handle करने के लिए Web Server पर एक Separate Process Create करता था, लेकिन वर्तमान समय में FastCGI तकनीक द्वारा Java की तरह ही Multiple Requests को एक ही Process के Multiple Threads द्वारा Handle किया जा सकता है।

इसीलिए वर्तमान समय में भी Perl आधारित CGI तकनीक को Use करते हुए भी Dynamic Web Development किया जाता है। हालांकि इस प्रकार के CGI आधारित Web Development की मात्रा काफी कम है।

Approach knowledge

Tuesday, December 11, 2018