All About Web Services

Introduction

Microsoft .NET marketing has created a huge hype about its Web Services. Here we will create a .NET Web Service using C#.

Why do we need Web Services?

After buying something over the Internet, you may have wondered about the delivery status. Calling the delivery company consumes your time, and it's also not a value-added activity for the delivery company. To eliminate this scenario the delivery company needs to expose the delivery information without compromising its security. Enterprise security architecture can be very sophisticated. What if we can just use port 80 (the Web server port) and expose the information through the Web server? Still, we have to build a whole new Web application to extract data from the core business applications. This will cost the delivery company money. All the company wants is to expose the delivery status and concentrate on its core business. This is where Web Services come in.

What is a Web Service?

Web Services are a very general model for building applications and can be implemented for any operation system that supports communication over the Internet. Web Services use the best of component-based development and the Web. Component-base object models like Distributed Component Object Model (DCOM), Remote Method Invocation (RMI), and Internet Inter-Orb Protocol (IIOP) have been around for some time. Unfortunately all these models depend on an object-model-specific protocol. Web Services extend these models a bit further to communicate with the Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML) to eradicate the object-model-specific protocol barrier (see Figure 1).

Web Services basically uses Hypertext Transfer Protocol (HTTP) and SOAP to make business data available on the Web. It exposes the business objects (COM objects, Java Beans, etc.) to SOAP calls over HTTP and executes remote function calls. The Web Service consumers are able to invoke method calls on remote objects by using SOAP and HTTP over the Web.

Figure 1. SOAP calls are remote function calls that invoke method executions on Web Service components at Location B. The output is rendered as XML and passed back to the user at Location A.

How is the user at Location A aware of the semantics of the Web Service at Location B? This question is answered by conforming to a common standard. Service Description Language (SDL), SOAP Contract Language (SCL) and Network Accessible Specification Language (NASSL) are some XML-like languages built for this purpose. However, IBM and Microsoft recently agreed on the Web Service Description Language (WSDL) as the Web Service standard.

The structure of the Web Service components is exposed using this Web Service Description Language. WSDL 1.1 is a XML document describing the attributes and interfaces of the Web Service. The new specification is available at msdn.microsoft.com/xml/general/wsdl.asp.

The task ahead

The best way to learn about Web Services is to create one. We all are familiar with stock quote services. The NASDAQ, Dow Jones, and Australian Stock Exchange are famous examples. All of them provide an interface to enter a company code and receive the latest stock price. We will try to replicate the same functionality.

The input parameters for our securities Web service will be a company code. The Web service will extract the price feed by executing middle-tier business logic functions. The business logic functions are kept to a bare minimum to concentrate on the Web service features.

you define a class that encapsulates the functionality of your service. This class should be public, and can optionally inherit from the WebService base class. Each method that will be exposed from the service is flagged with a [WebMethod] attribute in front of it. Without this attribute, the method will not be exposed from the service. This is sometimes useful for hiding implementation details called by public Web Service methods, or in the case where the WebService class is also used in local applications (a local application can use any public class, but only WebMethod classes are remotely accessible as XML Web services).
To create a new web service, fire up Visual Studio .NET and either select the New Project button on the default Start Page or click File New Project on the main Visual Studio .NET menu bar -> choose ASP.NET web service-> Give it any name like “HelloWorldService”
Open the “Service1.asmx” file & write the function

[WebMethod]

         public string getIPforHostname(string strHostname)

         {

                 IPHostEntry hostInfo = Dns.GetHostByName(strHostname);

                 return hostInfo.AddressList[0].ToString();

         }

Build ur program & test it.
Creating the Proxy Class in Visual Studio .NET
Creating a Proxy class for a Web Service is a breeze in Visual Studio .NET. In your ASP.NET Web Project, simply right click on the References icon and choose to "Add a Web Reference." A dialog box will appear asking you for a URL - simply enter the URL of the Web Service, such as: http://aspnet.4guysfromrolla.com/ws/ASPFAQs.asmx. You will then see the description of the Web Service (just as if you had visited the URL directly through your Web browser). To complete this task, click the "Add Reference" button, which will automatically create the Proxy class for you and compile it.
When added to your project the Proxy class's namespace will likely be the URL of your site, for example: com.4guysfromrolla.aspnet. (You can rename this if you so choose.) To call the Web Service from a Web page you use the Proxy class like you would any other local component. Imagine that we wanted to display a list of the FAQs from the ASP.NET category (which has category ID 22). We could do this by making a call to the GetFAQsInCategory method of the Web Service, passing in the parameter 22, and binding the resulting DataSet to a DataGrid, like so:

'HTML content in .aspx page... <asp:datagrid id="dgCategoryFAQs" runat="server" />   '*** ------------------------------------------------ ***'   'code content in the code-behind page Private Sub Page_Load(sender as Object, e as EventArgs)   'Create an instance of the Proxy class   Dim consumeWebService as com._4guysfromrolla.aspnet.ASPFAQs   Set consumeWebService = New com._4guysfromrolla.aspnet.ASPFAQs     'Bind the results of GetFAQsInCategory to dgCategoryFAQs   dgCategoryFAQs.DataSource = consumeWebService.GetFAQsInCategory(22)   dgCategoryFAQs.DataBind() End Sub

From simply examining the code you could not determine that the call to the com._4guysfromrolla.aspnet.ASPFAQs Proxy class is, in actuality, a remote Web service call. When the Proxy class's GetFAQsInCategory method is called, the complex communications discussed previously occur (the remote HTTP request/response dialogue).

The future of the Web Services

The future looks bright for the Web Service technology. Microsoft is not alone in the race for Web Service technology. Sun and IBM are very interested. There are SOAP toolkits available for Apache and Java Web servers. I believe Web Services needs a bit of work, especially the Web Service discovery process. It is still very primitive.

On a positive note, Web Services have the potential to introduce new concepts to the Web. One I refer to as "pay per view" architecture. Similar to pay-TV, we can build Web sites that can generate revenue for each request a user sends (as opposed to a flat, monthly subscription). In order to get some data, we can sometimes pay a small fee. Commercially this could be handy for a lot of people.

Examples

• Online newspaper sites can publish a 10-year-old article with a $2 "pay per view" structure.
• Stock market portals can itemize every user portfolio for every single stock quote and build pricing and discount structures.

And the list goes on ...

On a very optimistic note, Web Services can be described as the "plug and play" building blocks of enterprise Business to Business (B2B) Web solutions.