About Web Services

The evolution of the internet and its exponential growth in recent years has resulted in gradual shift from desktop to distributed applications. This shift has led to the development of complex enterprise applications that are managed across different platforms and geographical boundaries.

These applications may consist of components that may have been developed using different programming languages and hosted in heterogeneous environments. For this reason, the development of distributed applications involves ensuring that such components are interoperable.

A Web Service exposes a number of methods to provide functions that can be used by one or more applications, regardless of the programming languages, operating systems, and hardware platforms used to develop them. The methods that provide such function are called Web Methods. The functions used by a Web Service can be accesses by applications using Internet standards, such as Simple Object Access Protocol (SOAP). SOAP is a protocol that uses eXtensible Markup Language (XML) to describe data and HyperText Transfer Protocol (HTTP) to transmit application data. An application that uses a Web service is called a Web service client.

Web Services bring required service into your application from the Internet in the similar way that browsers bring it to the end users. The .Net framework introduces Web Services as an integral part of the architecture, making it very easy to create and consume these services with minimal amounts of code written. In fact, if you read Microsoft's documentation, Web Services are featured as the new component architecture in the distributed age where not only Internet exposure is handled through them but also common reusable business and application services.

The .Net framework abstracts most of the internal logic that handles the remoting details of method calls over the wire and Visual Studio .Net builds support for Web Services directly into the development environment. It is as simple to call a remote method as it is to call a local method.

Web Service’s mission is to provide a Remote Procedure Call (RPC) interface for client applications to call class methods on the server side. Actually, the handling interface on the server need not be a class, but in the case of .Net and COM before it classes are typically used as the implementing entity. The idea is that in order to create a Web Service, you create class methods with standard input and output parameters and you then mark those classes and the specific methods as exposable over the Net.

Web Services are meant to expose functionality of a server to other applications. The "client" applications in this case may be a Fat Client Windows app, a Fat Server Web application that runs a standard Web backend such as ASP, Cold Fusion, Web Connection etc., a browser based client application using script code, or even Java applet running in a browser on a Unix machine. As long as a client application has support for the Simple Object Access Protocol (SOAP) it can call the remote Web Service and return data for it, assuming the user is authorized.

Web Services Features

1. Interoperability: Enables applications developed using different languages and running on heterogeneous platforms to communicate.

2. Dynamic Integration: Enables applications to dynamically locate and integrate with one another to provide enterprise solutions

3. Industry Standards: Enables applications to communicate with each other using widely accepted industry standards, such as XML, SOAP, WSDL and UDDI.

4. Security: Enables applications to communicate with each other in a secure environment by using XML signature and XML encryption. XML signature and encryption are security mechanisms to maintain the integrity of the data that is transferred over the internet.

There are various roles involved in implementing a Web Service. These roles are responsible for performing specific functionalities during the Web service are:

• Service Provider

• Service Broker

• Service Client

Service Provider

A service provider is responsible for providing the software components that are published as Web services. The software components can be simple classes or complex applications written in some programming language. These software components implement the Web Service functionality. A service provider describes information of the Web Service using an interface. The interface specifies information, such as:

• Service methods that are invoked by a Client

• URL that the client needs to use to access the service.

• Network protocol required to access the Web Service.

Service Broker

The interface defined by the service provider is published in a centralized service registry called a service broker. The service broker allows the Web Clients to search the registry for information about published Web Services. The client and the Web service locate each other using service broker.

Service Client

A service client is the potential client of the service provider's Web Service, whose information is made available by the service broker. A service client, after locating the Web Service in the service registry, invokes the services implemented by the Web Service. Locating a Web Service in the service registry and invoking its methods is known as the Web Service binding operation. A service client can be a simple Web application or another Web service accessing the published Web Services.

Benefits of Web Services

1. Easy Accessibility

Any computer that has access to the internet can easily access a Web Service. This enables a number of applications residing on different software and hardware platforms to exchange data between each other. For example, a news network such as CNN can create a Web Service, which uses a method that accepts the news categories a parameter and returns the news items belonging to the specifies category. If you want to use this web service in an application or a Web site, you can design a form to accept the news category from a user. This form can invoke the method exposed by the Web Service and display the news items returned by the method.

2. Flexibility in Structure

Depending on the requirements of a business, different types of Web Services can be created and used in an application. For example, you can create simple Web services that provide a fundamental functionality that can be used in multiple applications. You can also create Web Services to integrate the existing applications that might have been created using different software and hardware platforms. Web services also prove useful in business-to-business transactions. Business partners may have applications running on different platforms. These applications can exchange data by using Web Services.

3. Easy Integration

Using Web Services, you can easily integrate business applications developed on different software and hardware platforms resulting in low setup costs. In addition, you can integrate Web applications with applications such as spreadsheets or back-end databases to provide online information.

Elements of a Web Service

1. XML

XML is used to exchange data over the internet. To enable data interchange, you require a standard data representation format that can be understood by any platform. Because XML is a plain-text format that can be understood by any type of hardware device over the Web, it is able to fulfill this requirement.

2. SOAP

To be able to communicate with each other, a Web Service and a client application must agree upon a common protocol. SOAP is a standard communication protocol for interchanging information in a structured format in a distributed environment. The information exchanged between the client application and the Web Service ids called a message. Messages include the calls made by a client application to a Web Method and the data returned by the Web method to the client. When a client application makes a request for a web method, a SOAP packet is created. This packet contains the name of the Web method to be invoked and the parameters to be passed to the Web method in an XML format. This information is used to invoke the web method with the appropriate parameters. When the SOAP packet arrives at the Web server on which the Web Service resides, the web method name and its parameters are extracted from the SOAP packet and the appropriate Web method is invoked.

3. Web Service Description Language (WSDL)

To be able to use a Web Service, the developers of a client application need to know the methods exposed by the Web Service and the parameters to be passed to theses methods. For this reason, you need a standard method to describe the methods that are called by a Web Service. This information should be readily accessible to the Web Service clients during the design phase. WSDL is a markup language that describes a Web service.

4. Universal Description, Discovery and Integration (UDDI)

It provides a standard mechanism to register and discover a Web Service. When a web service provider wants to make a web service available to client applications, the provider describes the Web Service by using a WSDL document. Then, the provider registers the Web Service in the UDDI Directory, which contains pointers to the Web Service and the WSDL document for the Web Service.

.Net Web Services that run over HTTP can be called in 3 different ways:

HTTP GET Operation

You can pass parameters to a Web Service by calling the ASMX page with query string parameters for the method to call and the values of simple parameters to pass. Example: WebDemo.asmx/MethodName?Parm1=value

HTTP POST Operation

Works the same as GET Operation except that the parameters are passed as standard URL encoded form variables. If you use a client such as wwIPStuff you can use AddPostKey() to add each parameter in the proper parameter order. Example: WebDemo.asmx/MethodName

SOAP

This is the proper way to call a Web Service in .Net and it's also the way that .Net uses internally to call Web Services.

The GET and POST operations are useful if you need to call a Web Service quickly and no SOAP client is readily available. For example, in a browser based client application it may be easier to use GET and POST instead of constructing and parsing the more complex SOAP headers that are passed back and forth in a SOAP request. But with a proper SOAP client in place SOAP provides the full flexibility of the protocol, where GET and POST operations have to stick to simple inputs and outputs. Among other things that you can do with SOAP is pass complex objects and data over the wire and for these operations to work you need to use SOAP.

Web Services' Life cycle

A Web service life cycle consists of various stages in the development and deployment process of a web service. The various stages in the life cycle of a Web Service are:

• Developing a Web Service

• Publishing a Web Service

• Locating a Web Service

• Accessing a Web Service

Developing a Web Service

This stage of Web Service involves describing the Web Service interface and implementing the business functionality of the Web Service. The web service interface contains the service methods that can be invoked by the clients. The service provider is responsible for developing a Web Service.

Publishing a Web Service

In order to make a Web Service available to service clients on the web, the web service is published in a service registry. A published web service stores the complete information regarding how a service client can access the Web Service.

Locating a Web Service

The client searches for a specific Web Service in the service registry. When the client locates the Web Service, it obtains the information from the registry that is required to access the Web Service.

Accessing a Web Service

After locating the Web Service, the client connects to the Web Service directly to access its services. The client accesses the Web service through the URLs provided by the service provider in the registry the XML-based protocol, SOAP.

Creating and invoking a Web Service

Create a Web Service

It is easy to create a Web service using the Visual Studio .NET IDE. For example, you can create a Web service called Dollar Converter, which accepts currency in US Dollars and converts it into the Euro currency that can be utilized by different Web applications across the globe.

Perform the following steps for creating the Dollar Converter Web service:

1. Select the Visual C# Projects option from the Project Types pane ASP.NET Web Service option from the templates pane in the new project dialog box.

2. Type http://localhost/CurrentDollarConverter in the location textbox as in the following figure and click the OK button:

3. Right click CurrentDollarConverter.asmx in the solution explorer and from the dropdown menu, select the view code option to open.

4. Add the following code in the code window, inside the sevice1 class:

[WebMethod]
public double convertvalue(double value)
{//converting dollars to euro
      return value*0.81;
}

5. To build the application, select the Build->Build Solution command.

Test the Web Service

After creating the web service, you need to test this web service to ensure that it functions properly. Perform the following steps to test the web service:

1. Right click the .asmx file in solution explorer and select the preview option in the browser or press F5 key.

2. The Web Service page appears. It exposes one method called convertvalue that accepts value as parameter of double data type. Click the convertvalue link on the page, as displayed in the following figure:

3. In the test page, enter the amount to be converted in the textbox and click the invoke button. The following figure displays the test page

The result will appear as shown in the following figure:

After testing the application, build the Web service class to create a dynamic-link library (DLL), by selecting Build Solution from the build option on the main menu. The Web Service is now ready for use.

Using the Web service

1. Create a Web application.

2. Rename the WebForm1.aspx as test.aspx by using solution explorer.

3. In solution explorer, right click your application and select the Add Web Reference option. The following dialog box opens up.

4. To add the reference click the Add Web reference dialog box.

5. The list of existing services on the local machine will appear, as displayed in the following figure:

6. Click the currentdollarconverter service from the list of available web services on the local machine. The add reference button is activated as displayed in the following figure.

7. In the Service1 dialog box, click the Add Reference button. A new localhost is added under the References node in the solution explorer window as shown below:

8. Add a text box, a label and a button to your web form.

9. Double click your button control to open the code window.

10. Add the following code

void btnconvert_Click(object sender, System.EventArgs e)
{
      double temp;
      WebApplication1.localhost.Service1  obj=new WebApplication1.localhost.Service1  ();
      temp=obj.convertvalue(TextBox1.Text);
      Label1.Text="The values in rupees is : "+temp;
}

11. To save the application, select the file->save project.

12. Run the application. Debug->Start

The Client Application

Client applications can be Web backend accumulating data to display custom content to clients to a Fat Client application running Windows forms. The process of connecting a client application in Visual Studio.Net is always the same though: You set up a Web Reference, add the Web Reference namespace and then simply call the methods of the Web Service.

Internally, the method call calls a proxy object, which invokes the remote Web Service. The proxy base class contains functionality that performs the SOAP call over the wire and the proxy class simply calls work methods in the base class to do function. The proxy reads the WSDL file to verify that the method signature and type information is correct and up to date, it then creates the SOAP envelope to send to the Web Service for processing. The proxy makes the HTTP call and passes the SOAP packet off to the Web server.

A SOAP request packet is like:

<?xml version="1.0"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope">
  <soap:Body>
    <AddNumbers xmlns="http://tempuri.org/">
      <lnNumber1>6</lnNumber1>
      <lnNumber2>4</lnNumber2>
    </AddNumbers>
  </soap:Body>
</soap:Envelope>

On the server side the .Net framework handler through ASP.NET and the .ASMX Web Service extension picks up this SOAP request and passes it to your class for processing. The internals of .Net take care of instantiating your Web Service class, invoking the constructor and then invoking the requested method, in this case AddNumbers, passing in the two provided parameters, which are converted into the types specified by the WSDL file.

Now the method executes and all user processing occurs. You will write the method code to do your business logic required to service the functionality of the Web Service. Then you return a result value as a simple return from the method.

The .Net Web Service handlers then take your return value and package it up into a SOAP response packet as follows:

<?xml version="1.0"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope">
  <soap:Body>
    <AddNumbersResponse xmlns="http://tempuri.org/">
      <AddNumbersResult>10</AddNumbersResult>
    </AddNumbersResponse>
  </soap:Body>
</soap:Envelope>

It then sends this output back over the HTTP connection to the client application proxy. The proxy now picks up the SOAP response, and unpacks the SOAP response, performs the type conversion of the XML back into the proper return type specified in the WSDL document and returns the value back to the client side.

On the client side the following two lines seem to perform this function:

using WebDemoService;   // top of code
...
/// calling Web Service class WebDemo
WebDemo oService = new WebDemo();
decimal lnResult = oService.AddNumbers(6.4);

Tutorial toolbar:  Tell A Friend  |  Add to favorites  |  Feedback  |   Google