ASP.NET Web Services - I

The C# Column - Yashawant Kanetkar

A Web service is an application stored on a machine that can be accessible through another machine over the Internet or LAN. Even before the introduction of Web services we were able to access applications, or business logic, across the Net. Therefore, before starting with Web services we must be aware of the need that gave rise to Web services.

To begin with we will discuss the four ‘P’s that are important in doing business using computers.

• Partners: Every business needs partners, and that is how they make an enormous amount of profit.
• Profit: No business can run without making profits. Profit must increase every year to make the business successful.
• Productivity: Computers can be used to improve the productivity of a business and hence the profit.
• Programming should be cheap: If computers are to improve productivity of the business then programming and maintenance cost should decrease.

Let us now understand the current business scenario. We will take an example of an airline company. The customers of the airline company may get access to the company through personal computers, PDAs or simple phones. The airline company may communicate with partners, such as a food company or the bank. Partners and clients would still be there but the way they would interact would be different.

The airline company would have a Web server to which clients would send requests for ASP or HTML pages. The request would be in form of HTTP request. The Web server would communicate with the business logic in the application server and use the databases to store the data. The Web server would respond by sending HTML back to the clients. The food company and bank would also have application servers running business logic in the form of components. They would also have database servers for secured and efficient data storage. If the airline company is to access the business logic exposed by application servers of the food company and bank it would do so through Remote Procedure Calls. Also, the food company and bank may be interacting with each other.

Different client organisations would use various software and programming models. Even the operating systems installed on the client devices would be different. The client would like to interact with the Web server using these devices. The Web server of the airline company may either have IIS, JWS or Apache server running appropriate server-side scripts. The food company may have the COM+ model on their application servers with business logic implemented as COM components with MS-SQL databases. The bank organisation may have J2EE model with business logic implemented as EJB components running on their application servers, and databases in Oracle.

In a distributed computing architecture the clients form the Presentation layer and the DCOM, EJB, CORBA and DSOM components form the Business layer. The clients has to cross the firewalls to access components. Firewalls ensure that communication is done through a specified port and data format. The external applications, databases and legacy systems form the Data layer.

In our airline example, the main reason for conflict is that all the three interacting companies (airline company, food company and bank) have different standards. The airline company has CORBA components installed. The food company has DCOM components and the bank has EJB components. The problems faced in developing these components are as follows:

Language: DCOM components could be written only in VC++ or VB, whereas, EJB components could be written only in Java.

Infrastructure: CORBA components need ORB libraries and services. DCOM components need COM libraries and services, and EJB components need J2EE services.

Layout of Objects: Layout of CORBA components differ from DCOM components, which in turn differs from EJB components.

Description: CORBA components are defined using CORBA Interface Description Language, DCOM components are defined using Microsoft Interface definition languages and EJB components are exposed as interfaces.

Discovery Standards: CORBA components are discovered using the CORBA registry, DCOM using the Registry, and EJB using the Java Native Directory Interface.

The conflict between these models occurs mainly due to the Wire Protocol and Data Standard. This was different for each of the infrastructure. CORBA uses IIOP (Inter Internet Object Protocol), DCOM uses RPC (Remote Procedure Calls) and EJB uses RMI (Remote Method Invocation)/IIOP. All these protocols are non-standard protocols and hence are not followed by all companies.

These existing Distributed Computing solutions suffer from various problems. For example, DCOM is a proprietary protocol. It does not support interoperability and it has firewall problems because DCOM transfers data in binary format and it uses many ports to call remote functions. CORBA uses the IIOP protocol, which is non-Internet friendly. EJB requires very costly infrastructure. Moreover all these object models require their clients to use the same libraries as that used on the server. This makes for a very tight coupling between client and the component. If component is changed and written using new object models, the client will also have to change.

To address these needs, XML Web services came into existence and were introduced as part of ASP.NET, which is part of the .NET Framework. Web services are based on open industry standards, such as HTTP, XML, and SOAP. Using these open standards, Web services deliver application functionality across the Web to any type of client, on any platform.

XML Web services are based on open Web standards that are broadly supported and are used for communication and data formats. XML Web services provide the ability to expose application logic as URI-addressable resources, available to any client in a platform-independent way. Web services are self-describing. Any clients incorporating open Web standards for communication and data formatting (HTTP and XML) can dynamically query for Web service information and retrieve an XML document describing the location and interfaces supported by a particular XML Web service.

These open standards make Web services indifferent to the operating system, object model, and programming language used. Web services are accessible to disparate systems, supporting application interoperability to an unprecedented level thanks to the ubiquity of HTTP and XML.

Instead of communicating in binary formats between applications, Web services use XML-encoded messages. Because XML-based messaging is used for data interchange, a high level of abstraction exists between a Web service implementation and the client. This frees the client from needing to know anything about a Web service, except for its location, method signatures, and return values. Additionally, most Web services are exposed and accessed via HTTP, virtually eliminating firewall issues.

We will see more about Web services, the protocols they use and the way they are discovered in the next article.

Yashavant Kanetkar, one of the first Express Computer columnists, is an established software expert, speaker and author with several best-sellers to his credit, including titles like “Let Us C” and the “Fundas” series. Contact him at kanet@nagpur.dot.net.in