XML Web services are program components that build scalable and platform-independent applications. XML Web services allow different applications to exchange messages using standard protocols such as HTTP, XML, SOAP, XSD, and Web Services Description Language (WSDL). In XML Web services, XML-based messaging is used to send and receive data, enabling various applications to interoperate with one another. The infrastructure of the XML Web services provides a number of components that allow client applications to locate and consume XML Web services. The components provided by the XML Web services are described below:
XML Web services directories: These directories store published information about XML Web services, and search for information about other XML Web services programmatically by using the Universal Description, Discovery, and Integration (UDDI) specifications. The XML schemas in association with UDDI define four types of information that includes business information, binding information, service information, and service specifications to make the XML Web service accessible.
XML Web services discovery: XML Web services describe their interfaces provided in an XML document called a Web Services Description Language (WSDL) document that allows a user to build a client application. The discovery process describes the location of a particular XML Web service.
XML Web services description: The XML Web services description component is an XML document that specifies the SOAP message schemas. These schemas are used when methods are invoked on an XML Web service.
XML Web service wire formats: XML Web services use open wire formats to communicate between different systems. Open wire formats are the protocols that support common Web standards, such as HTTP and SOAP. The HTTP-GET and HTTP-POST protocols are the standard Web protocols that send parameters as name-value pairs to an XML Web service. The SOAP protocol exchanges structured and typed information between the applications on the Internet.
The communication between a client and an XML Web service can be associated to a remote procedure call (RPC). The interaction between a client and an XML Web service consists of four main phases. The following image shows the communication between a client and an XML Web service.There are several tasks that are to be performed during the four phases of the process of communication between a client and an XML Web service. They are as follows:
The client creates a proxy object of the XML Web service on the client-side computer and calls a method on it.
The XML Web service infrastructure serializes the method call and sends a SOAP message to the XML Web service over the network.
The XML Web service infrastructure on the server-side deserializes the SOAP message and creates an object of the XML Web service. The infrastructure then calls the method to be executed, and its value is returned to the infrastructure.
The infrastructure then serializes the return value and sends a SOAP message to the client over the network.
The infrastructure on the client-side then deserializes the SOAP message that contains the return value and sends it to the proxy object. In turn, the proxy object sends the return value to the client.
The standard protocols used by the XML Web services in order to communicate between the client and the Web service server have been described as follows:
SOAP (Simple Object Access Protocol): The Simple Object Access Protocol is the communication protocol for XML Web services. It defines the XML format for messages. The SOAP protocol is intended for exchanging structured and typed information between different applications that support the XML Web services. The SOAP protocol comprises four parts. The first part defines the envelope that contains the message and is the basic unit of exchange between the processors of SOAP messages. The second part defines the data encoding rules that are used to encode application-specific data types. The third part defines the message request or response that is exchanged between XML Web services, and the fourth part defines the bindings between the SOAP and HTTP protocols.
Disco and UDDI (Universal Description, Discovery, and Integration): Disco is a standard document for creating discovery documents and is kept at a standard location on a Web services server. A Disco document also contains paths and retrieves other useful information such as a WSDL file that describes a service. UDDI is a directory entry file that describes a business and the services that it offers. The UDDI directory includes several ways to search for the services that are needed to build Web applications. Therefore, the UDDI directory is the yellow pages of Web services.
WSDL (Web Services Description Language): A Web Services Description Language file is an XML document that describes a set of SOAP messages and how the messages are exchanged. A WSDL file is used to describe message formats based on the XML Schema standard. A WSDL file generates the code required to communicate with an XML Web service and contains several tools to read the XML file.
Creating and Consuming an XML Web Service An XML Web service is created to provide the specific functionality to client applications. For creating an XML Web service, a programming language is chosen and a class inherited from the System.Web.Services.WebService namespace is created. Then an infrastructure is required to make the XML Web service available for client applications to use over the Internet. After an XML Web service is created, the client application can access the services provided by it. This is called as consuming a Web service. The application that consumes a Web service is the Web service client that can be a component, service, or desktop application. The following are the tasks that a user must perform to access an XML Web service from a client application:
- To add a Web reference to the XML Web service by discovering the XML Web service.
- To generate a proxy class for the XML Web service and to create an object in the client application.
- To access the XML Web service by using the proxy object.
There can be several advantages of using XML Web services. From the examination point of view, you can create a question that describes the various advantages of using XML Web services in the following manner:
Publishing an XML Web Service An XML Web service can be deployed on a Web server either by creating a Web setup project or by copying the XML Web service files to the Web server. When an XML Web service is deployed on a Web server, the service is published on the Web and is available to client applications. After the deployment of an XML Web service, the applications use a discovery mechanism to locate the XML Web services. While deploying an XML Web service, the following are the various components of the Web service that are published on the Web:
The Web application directory: This component is the root directory where all the XML Web service files are stored. It needs to be configured as an IIS Web application.
The
The
The Web.config file: This is an optional file that overrides the default configuration settings of an XML Web service.
The Bin directory: This directory consists of binary files for an XML Web service. If an XML Web service class is not defined in the same file as the .asmx file, the assembly that contains the class should be placed in the Bin directory.
Controlling the characteristics of Web methods When an XML Web service is created, the properties of the WebMethod attribute can be used to define the behavior of the methods exposed by the Web service. The following properties of the WebMethod attribute customize and control the behavior of the Web service methods:
BufferResponse property: The BufferResponse property of the WebMethod attribute is used to buffer the responses for a Web method that returns a Boolean value. Buffering the responses for a Web Method can improve the performance of an application by minimizing communication between the worker process and the IIS process. When the BufferResponse property is set to true (default), ASP.NET buffers all the responses before communicating them to the client. When the BufferResponse property is set to false, ASP.NET buffers the responses in chunks of 16 KB while communicating to the client. The following code snippet shows how to use the BufferResponse property by using Visual Basic .NET:
Public Class MyServiceInherits System.Web.Services.WebService
MultiplyNumbers = MulNum1 * MulNum2
End Function
End Class
The following code snippet shows how to use the BufferResponse property by using Visual C# .NET:
public class MyService: System.Web.Services.WebService{ [WebMethod(BufferResponse = false)]
public int MultiplyNumbers(int MulNum1, int MulNum2)
{ return (MulNum1 * MulNum2); }}
CacheDuration property: The CacheDuration property of the WebMethod attribute is used to cache the results for a Web method, and it specifies the duration that the value of the property should set for each unique parameter. By default, the value of the CacheDuration property is set to zero. The following code snippet written in Visual Basic .NET sets the CacheDuration property to 30 seconds:Public Class MyServiceInherits System.Web.Services.WebService
Public Function MultiplyNumbers(ByVal MulNum1 _ As Integer, ByVal MulNum2 As Integer) As Integer
MultiplyNumbers = MulNum1 * MulNum2
End Function
End Class
The following code snippet written in Visual C# .NET sets the CacheDuration property to 30 seconds:public class MyService:
System.Web.Services.WebService{ [WebMethod(CacheDuration = 30)] public int MultiplyNumbers(int MulNum1, int MulNum2)
{ return (MulNum1 * MulNum2); }}
Description property: The Description property of the WebMethod attribute is used to describe a Web method and sets a string value as input. The following code snippet written in Visual Basic .NET displays how to use the Description property:Public Class MyServiceInherits System.Web.Services.WebService
< webmethod(description:="takes >
