ASP.NET and IIS – The Microsoft’s Web Server Environment

जब Microsoft में ASP.NET को Develop किए जाने हेतु Planning चल रही थी, तब IIS व ASP.NET Frameworks को Tightly Integrated Environment के रूप में Develop किया जाना था ताकि आने वाली Requests को Process करने के लिए समान Logic को Share किया जा सके। इस वजह से ASP.NET को इस तरह से Design किया जाना था कि वह Port 80 के माध्‍यम से Page Requests को Handle करने में पूरी तरह से सक्षम हो।

जबकि IIS को एक Generate Purpose Web Server की तरह Develop किया जाना था, जो कि विभिन्न प्रकार की अन्‍य Predefined Ports पर आने वाली Requests को Handle करने की Capability रखता हो और वर्तमान समय में हम जो IIS 7.5  तथा  Microsoft Windows Server 2008 R2 को देख रहे हैं, वे कुछ हद तक इसी Concept का परिणाम हैं। ASP.NET व IIS को बेहतर तरीके से समझने के लिए जरूरी है कि हम इनके विकास के क्रम को थोडा Historical तरीके से देखें।

तो चलिए, जानने की कोशिश करते हैं कि ASP.NET व IIS का विकास किस प्रकार से हुआ।

ASP.NET and IIS – The History

2002 के अन्तर्गत ASP.NET 1.0 एक Self-Contained, Brand New Runtime Environment था, जिसे IIS 5.0 को आधार में रखते हुए विकसित किया गया था। जबकि ASP.NET 1.1 व IIS 6.0 को एक साथ समानान्तर रूप से Release किया गया था, जिससे Web Development व Server Platform आपस में काफी Close हो गए थे  तथा Process Recycling व Output Caching जैसे कुछ Services को Share करने लगे थे।

फिर ASP.NET 2.0 Release किया गया, जिसमें IIS में किसी प्रकार का कोई Change नहीं किया गया था, लेकिन जब Windows Server 2008 के साथ IIS 7.0 को Release किया गया, तो ASP.NET व IIS Programming Model आपस में काफी हद तक Unified हो गए थे।

चलिए, समझने की कोशिश करते हैं कि IIS Architecture व इस Architecture के ASP.NET Applications के साथ Interaction में किस प्रकार के Changes किए गए थे।

Standalone ASP.NET Worker Process

वास्तव में तो ASP.NET व IIS Teams ने एक साथ ही शुरूआत की थी, लेकिन Development के दौरान दोनों के विभिन्न प्रकार के Features के Develop होने में समय का अन्तर आ गया। इसलिए ASP.NET 1.0 को Planning के अनुसार IIS पर निर्भर करते हुए Release नहीं किया जा सका, बल्कि इसे इसके स्वयं के एक Standalone Worker Process पर Depend करते हुए Release किया गया।

इस Release को हम निम्न चित्रानुसार Represent कर सकते हैं, जहां ASP.NET 1.0 को Windows 2000 व IIS 5.0 को आधार में रखते हुए उस पर एक Worker Process को Place किया गया और इस Worker Process पर ASP.NET Framework को Run करते हुए Release किया गया, जबकि वास्तव में इसे सीधे IIS Server पर Run करते हुए ही Release किया जाना था:

इस Model में User द्वारा Web Browser के माध्‍यम से Perform की गई HTTP Request को IIS Executable द्वारा Port 80 को Listen करते हुए Capture किया जाता था, फिर उस HTTP Request को aspnet_isapi.dll नाम के IIS Extension के साथ Map किया जाता था और अन्त में उस Mapped HTTP Request को ASP.NET Worker Process पर एक Named Pipe के माध्‍यम से Forward किया जाता था। परिणामस्वरूप आने वाली Incoming Request को Double Stage Pipeline से गुजरना पडता था:

• IIS Pipeline से व
• ASP.NET Runtime Pipeline से।

चूंकि IIS Pipeline पर ASP.NET Developer का काफी कम Control होता था, जिसके अन्तर्गत ही Authentication जैसे Steps Follow होते थे, जबकि अपने Web Application पर पूरा Control उसे तब प्राप्त होता था, जब HTTP Request, Processing के लिए ASP.NET Worker Process पर पहुंचता था।

ASP.NET Worker Process ही CLR Instance को Process में Load करने  तथा  Request Life Cycle, Application Startup, Forms Authentication, State Management, Output Caching, Page Compilationlfgr विभिन्न Processes को Trigger करने के लिए Responsible होता था।

IIS Native Worker Process

Windows Server 2003 व IIS 6.0 के Release के साथ ही Microsoft ने विभिन्न Applications के बीच के Isolation को Achieve करने के लिए Web Server के Architecture को फिर से Redesign किया, ताकि एक ही IIS Server पर Installed एक ही Web Application के एक से ज्यादा Versions आपसे में एक दूसरे के साथ Conflict न करें।

IIS 6.0 कुछ Predefined Executable के साथ आता था जो कि बहुत सारे Additional Programs के लिए Worker Process की तरह Serve होते थे और समान Application Pool को Share करते थे, जहां Application Pool एक ऐसा Abstraction होता है, जिसका प्रयोग w3wp.exe नाम के समान IIS Native Worker Process के Instance में Multiple Web Applications को Group करने के लिए किया जाता है जबकि इस Group के अन्तर्गत जितने भी Web Applications होते हैं, वे आपस में एक दूसरे के साथ Conflict नहीं करते।

IIS 6.0 में http.sys नाम का एक ना HTTP Protocol Stack होता है जो कि Kernel Mode में Run होता है। यही Protocol Stack, Web Browser से आने वाली Incoming HTTP Requests को Capture करता है व उन्हें Worker Process पर Forward करता है। यानी Worker Process, Protocol Stack का प्रयोग करते हुए HTTP Requests को Receive करता है  तथा  Responses को फिर से Web Browser पर Send करता है। इस Working को हम निम्न चित्रानुसार भी Represent कर सकते हैं:

ASP.NET के इस Model में एक WWW Publishing Service Client Request को IIS पर Hosted Site व Application से Connect करता था। WWW Service, ASP व ASP.NET Request के साथ ही इस बात को अच्छी तरह से समझता था कि किसी Static Resource (HTML Pages, Audio, Video, Image Files etc…) से कैसे Deal करना है।

ASP.NET Request के लिए WWW Service Request को Processing के लिए Worker Process पर Forward कर देता था जो कि Application Pool को Handle करता था, जहां Target Application Hosted होता था। IIS Worker Process aspnet_isapi.dll को Load करता था, जो कि एक Classic IIS Extension Module होता है और फिर ये Module CLR  तथा  ASP.NET Default Request File Cycle के साथ Deal करता था।

Shared Pipeline of Components

IIS 7 से पहले के सभी IIS Versions तक हमारे पास वास्‍तव ASP.NET Web Applications Development से सम्बंधित दो Distinct Runtime Environments थे, जहां पहला Runtime Environment, IIS Process में था जबकि दूसरा Runtime Environment, Hosted ASP.NET Application के Application Pool में था।

इन दोनों ही Runtime Environments की  Capabilities व Programming Models एक-दूसरे से पूरी तरह से भिन्न थे। केवल वे Resources जो कि ASP.NET ISAPI Extension के साथ Mapped थे, उन्हें ही ASP.NET Runtime Environment का हिस्सा माना जा सकता था, जबकि अन्‍य सभी को IIS Machinery के अन्तर्गत ही Process किया जाता था।

लेकिन IIS 7 के साथ ही हमें एक ऐसा नया IIS Runtime Environment प्राप्त हुआए जो कि ASP.NET के Runtime Environment के लगभग समान था। फलस्वरूप जब ये Runtime Environment Enabled होता है, तो ASP.NET Requests, IIS Level पर Authenticate व Preprocess होते हैं और Classical Managed ASP.NET Runtime Environment को Use करते हुए ही Web Browser में Render होने वाला Response Produce करते हैं, जो कि Managed HttpRuntime Object पर आधारित Environment होता है। इस Model को हम निम्न चित्रानुसार Represent कर सकते हैं:

जबकि Authentication, Output Caching, State Management व Logging जैसी Application Level Services एक तरह से IIS 7 में Centralized तरीके से Exist रहती हैं, न कि ASP.NET के Request के साथ Mapped होती हैं, जैसाकि IIS 7 से पहले होता था।

IIS 7 के साथ ASP.NET के इस व्‍यवस्थित तरीके से काम करने की वजह से हम HTML Pages या JPEG Images को Authentication करने के लिए Setup कर सकते हैं, जबकि अब हमें ऐसा करने के लिए किसी ASP.NET Specific Extensionके साथ इन्हें पहले से Map करने की जरूरत नहीं होती है, जैसी कि IIS 7 से पहले हुआ करती थी।

ध्‍यान देने वाली बात ये है कि IIS 7 में Unified Architecture एक प्रकार से Optional Architecture है और इसे IIS Manager Tool द्वारा Disable किया जा सकता है। इस Tool को Activate करने के लिए START => Programs => Internet Information Service (IIS) Manager को Click किया जा सकता है, जो कि अगले चित्रानुसार दिखाई देता है:

इस IIS Manager में दिखाई देने वाले Application Pool को Double Click करने पर दिखाई देने वाले Dialog Box में हम Managed Pipeline Mode के अन्तर्गत “Integrated” Option को Set देख सकते हैं जो कि किसी भी एक Application Pool का Default Working Mode होता है।