Saturday, July 23, 2011

Windows DNA to .NET

What is windows DNA?
Short for Windows Distributed internet Applications Architecture, a marketing name (Architecture) for a collection of Microsoft technologies that enable the Windows platform and the Internet to work together. It was programming model that companies use when designing n-tier distributed component based applications for windows platform.

What are advantages of .NET over Windows DNA?
1) Application deployment:
To replace a dll in windows DNA was not straight. You have to stop entire web site, copy file across and restart web site, sometimes reboot the machine. This is because the way COM manages the Dlls, once they are loaded you can not over ride them until unloaded. In case of .NET these can be overridden any time because of feature called shadow copy, which is part of CLR. It is feature that prevents PE(portable executable) files (DLL, EXE) being locked.
2) Side by side execution:
in windows DNA it was not easy to run 2 different versions of same application component side by side, either on same machine of same process. But in .NET different version of same component can co exist.
3) Scripting limitation:
In ASP pages we can not access Win32API directly and have many COM related restrictions, because every thing we write is on script side, thus using any component is little tricky here. But in case of ASP .NET we can write code in page/component, using any component is not a problem here.
4) Versioning Hell (DLL Hell):
An application may be dependent upon several DLLs. If any dependency is broken application will stop working. Thus it was very easy to break any application by installing any other application or changing registry using tool regedit. In .NET this problem got sorted our by GAC. If any other application comes with other DLLs also, the old DLL will not get affected, thus application will work fine.
5) Performance:
Every time we hit any ASP page, the scripts get compiled, but in case of ASP .net it is compiled only once, thus improves the performance.

How CLR and COM are related?
Ans: There is always adoubt that where exactly COM fits into CLR. The simple answer is it doesn't. CLR is written from ground, it is not like CLR is built on COM. COM is only used for interoperability and hosting, i.e. it enables us to use CLR classes as COM component on non-CLR environments. Hosting the CLR inside application(such as IIS) is achieved using COM, as CLR provides set of COM components for loading and executing CLR code.

 What are advantages of ASP .NET over ASP?
1) Remove the dependency on script debugging:
ASP is built using Active script, a technology originally designed to enable developers to script and control applications in uniform way. It has many problems, like:
--Code is interpreted not compiled(results in average performance)
--Weak type system(Code harder to develop,read,debug)
--Only support late binding(many times slower than early bound)
--Each instance of active scrip engine consumes memory
In ASP .NET we use assembly(DLLs), which are compiled 1st time only.

2)Easy deployment:
ASP .NET hs feature of shadow copy which makes our life easier. The shadow copy feature of the CLR only works for ASP .NET component files located in BIN directory.(what about GAC?)
3) Easy debugging in ASP.NET.
4)ASP.NET was built on HTTP run time, which has its own advantages.
5) Rich authentication model

What are the advantages of HTTP run time over ISAPI?
In the past, changing/extending the functionality of IIS required the use of C/C++ and the Internet Information Server API (ISAPI) to develop this functionality. With the ASP.NET HTTP Runtime, advanced functionality can now be easily created using the .NET Framework and any .NET Language.
The ASP.NET HTTP Runtime exposes an object-oriented, event-drive architecture. This easily allows developers to create advanced ASP.NET Web Applications that can participate during different stages of the Request/Response cycle. This ASP.NET HTTP Runtime infrastructure can be considered as the logical replacement for ISAPI filters. Because of the event-driven architecture of the ASP.NET HTTP Runtime, developers are able to participate at various stages of the application lifecycle using the .NET Languages.
Another ISAPI-based advantage is that the programming model allowed responding to particular URLs and to particular file extensions. This model is referred to as an ISAPI Application (or extension). As a well-known example, the classic ASP.DLL is an ISAPI application mapped to process files with an extension of .asp.  Therefore, when IIS receives an HTTP request for a .asp file, the incoming request is dispatched (via internal mapping maintained by IIS) to ASP.DLL file. ASP.DLL in turn loads the file, interprets and executes its contents,  and then sends the response back to IIS which in turn forwards it on to the requesting browser. The ASP.NET Runtime can provide much of the same functionality by creating DLLs that implement the IHttpHandler interface. This kind of DLL is known as an HTTP Handler. An HTTP Handler can be developed using any .NET language. It can be developed either as a manually compiled and configured DLL, or it can developed by writing a special .ashx file. Both techniques accomplish the same functionality
Another commonly used interface in the ASP.NET Runtime is IHttpModule. ASP.NET comes with a number of pre-built classes that implement IHttpModule that are responsible for handling session state, authentication, authorization, logging, and output caching. The design of the ASP.NET HTTP Runtime allows for the removal of any un-needed IHttpModule from the application or the machine itself. This addresses the situation where you simple do not want to have a particular piece of default functionality in your application.

No comments:

Post a Comment