.Net and the Web

Ever thought about using a functionality of another website in your own website, or even your own application? For instance, how about using Google’s search capability and displaying the results in your Windows-based application? Currently, if you were to do that, you would have to invoke a server-side script and pass the search text to it. You would be returned with HTML. And this is an issue. After all, what is the best you can do out of HTML? Render and display it. 

What if your application wanted to get the search results, maybe as an array of link objects, each of which would be containing required information about the link, the site its linking to, etc? You could then programmatically work upon these objects like any other programming construct. Until now, this wasn’t possible, but with introduction of SOAP (Simple Object Access Protocol), this has become possible.

Entities, known as WebServices, use the SOAP protocol to make the functionalities of a Web application available to any kind of SOAP client, a website, another Web application, or a traditional application. The .Net framework has complete support to build highly scalable, both stateless and stateful, WebServices to make a particular functionality accessible in a distributed environment. Thus, WebServices can be loosely thought of as light-weight distributed components, which can be accessed over the HTTP protocol, and invoked using the SOAP protocol. For the developer of the client invoking the functionality of a particular WebService, writing code would be similar to writing code invoking any other traditional class instance.

Remoting: A better way to DCOM



Each of us who has written components, must have worked with DCOM (Distributed COM) environment at one time or another. DCOM was good, since one could utilize the functionality of their COMponents across machine boundaries. However, because of the very nature of the way it was designed, DCOM suffered from a serious limitation: components couldn’t be accessed across firewalls/routers.

This limitation stems from the fact that DCOM is based on a proprietary implementation of the RPC (Remote Procedure Call) protocol. This protocol is non-routable in nature and works great when the components using it are in the same LAN. However, if the component and client invoking the component lie in different networks, especially across firewalls, they couldn’t talk. This is primarily because the firewalls don’t let the RPC traffic through. Only standard ports, like that of HTTP, are open. 

To handle this scenario, CIS (COM Internet Services) was introduced. These services, simply put, carried the RPC packets over HTTP to communicate across firewalls. Though this worked, this wasn’t a scalable solution since in the end it was based upon

RPC.

The .Net framework has done away with DCOM. A better, more scalable and open technology called .Net Remoting (or Remoting for short) has taken its place. Because of the fact that Remoting has its roots in open standard protocols, like TCP, HTTP, it doesn’t suffer from the limitation that DCOM faced. In addition, Remoting gives  

• better control over object lifetime, ie, you can control as to when the object will die. In DCOM, this was determined by sending a series of PINGs, which wasn’t a very scalable and reliable solution
• Different channels of communication 
• Ability to serialize, ie, persist object state to later deserialize as and when needed
• Different ways of instantiating an object, depending upon the object type, and whether they can hold state or not

Effectively, Remoting gives a more complete, reliable, flexible and scalable means of working with objects across process and machine boundaries. 

ADO.Net: A better way to work with data 



Apart from the term ADO, ADO and ADO.Net share nothing. While ADO was completely based on the concept of connection oriented database access, ADO.Net takes a reverse, focusing on disconnected database access.

One of the most evident differences between ADO and ADO.Net is the amount and the way you work with data. Essentially, in ADO, one would be working with a set of rows from a given table in a given database. Thus, if you were to work with another table, you would have to open a new recordset object to do so. In addition, ADO had no support for comprehensive database structural information like Relations, constraints, working with views, to name a few.

While working with the disconnected nature of ADO.Net will make you take a bit of time, especially if you love working with connected databases, you will appreciate the flexibility of ADO.Net, where you can have an entire database, complete with all the tables, any relations between them, constraints, and related views, read into a single object, known as the Dataset, work with it at your own leisure, make changes to it, add new structures like tables, while remaining disconnected from the database, and then update the database with your changes at a later point in time. This disconnected nature is of particular importance in designing n-tier applications, and was one of the design goals of

ADO.Net.

In addition, ADO.Net has native and consistent support for working with data sources using both OLEDB and XML. In fact, you can persist data to XML format, or read an XML file and create a Dataset out of it, containing tables, etc.

Finally, ADO.Net has separate, and optimized, providers for accessing databases using OLEDB and ODBC. A highly optimized set of classes are part of ADO.Net, exclusively for working with SQL Server.

Working with legacy code



The .Net framework has complete support for interacting, and using the functionality of legacy code, namely, the Win32 DLLs and COM components.

PInvoke (Platform Invocation Services) is the mechanism using which any .Net code can invoke functions exported from Win32 DLLs. And the best part is that the invocation mechanism is consistent across languages, and with just couple of extra instructions, unmanaged functionality can be utilized in your managed applications. All the required marshalling takes place automatically, and is transparent to the developer, making it very convenient.

Likewise, there’s even stronger support for interoperating with COM components. Using utilities like TLBIMP.EXE and TLBEXP.EXE, proxy DLLs and proxy type libraries can be created respectively, which can be used to let a COM client invoke the functionality of the .Net component, or a .Net client invoke the functionality of a COM component. Thus, both the sides get to reap the benefits of each other. Similar to PInvoke, marshalling takes place automatically using the proxies DLL/type-library that is created, by intermediate wrapper components: Runtime Callable Wrapper (RCW), which is used by the .Net client when using the functionality of a COM component, and the COM Callable Wrapper (CCW), which is used by the COM client when utilizing the functionality of a .Net component.

Finally, for all your components which are deployed in COM+, the concept of .Net Serviced Components lets you write .Net components that can be hosted in the COM+ environment, and reap benefits of:

• COM+ transactions
• Queued components
• Object pooling
• Role base security
• Just-In-Time Activation
• Object Construction

and lots more.

Thus, with complete interoperability support in the .Net framework, you can rest easy when migrating your applications, or interoperating with them, during your transition to .Net.

ASP.Net: for Web applications



ASP.Net packs a lot more punch than ASP did. Not only is supports all that ASP did, but extends that support to allow the developer incorporate the functionality from anywhere in the .Net framework, or any other custom library. This means just one thing: you make richer web applications than ever.

With its compiled nature, as opposed to ASP’s interpreter based approach, once the ASP.Net page is compiled, it will be executed much faster than ASP pages ever did. Not only that, the concept of server side controls bring to you a rich set of tools that, when incorporated on an ASP.Net page, bring more richness with an ease. For instance, in traditional ASP based environment, to display a calendar, you would either write a complicated DHTML script, or use an applet. In ASP.Net, simply drag the Calendar control, and you are done! When rendered, cross-browser HTML/script will be produced to display the Calendar. All this done by just dragging the control on the WebForm, ASP.Net’s equivalent of the traditional Windows Forms, and .Net’s

WinForm.

Keeping the analogy going, ASP.Net also brings the concept of server side events. Suppose, the user changed the date in the Calendar control, and you wish to be notified about it. In a traditional Windows application, this notification is raised as an event. Very similarly, ASP.Net-based server side controls raise server side events to let you take appropriate action in your response to the event notification.

Another very powerful concept is that of validation controls, which when bound to a particular server side control, implement complete client side validation checks, without you writing even a single line of code. You write only when you wish to have custom validation in place, which can be set up using the CustomValidation control. 

ASP.Net also bundles complete support for implementing ISAPI handlers, enhanced Web application authentication mechanisms, including:

• Windows-based authentication
• Microsoft Passport based authentication
• Custom forms-based authentication

Kumar Gaurav Khanna