You are on page 1of 12

A Technical Paper on

Web Services - The Future of the Internet

Presented by
Sagar Patil

Tousif Peerzade

IT Department, KITs College of Engineering, Kolhapur, Maharashtra, India.

Index Contents

1. Abstract An overview of Web Services

2. Web Services Basics a. Introduction b. Characteristics of Web Services c. Use of Web Services

3. Web Service Architecture

4. XML The Backbone of Web Services a. Introduction b. Whats a document? c. Why XML?

5. The Web Service Protocols a. Communication: SOAP b. Description: WSDL c. Discovery: UDDI

6. The Future of Web Services

7. Conclusion

8. References

Much of the Web's success can be attributed to its simplicity. It offers a straightforward means by which static information could be published and interconnected on a global basis. The Web Services initiative effectively adds computational objects to the static information of yesterday's Web and as such offers a distributed services capability over a network. Web Services have the potential to create new paradigms for both the delivery of software capabilities and the models by which networked enterprises will trade.

A 'Web service' is defined by the W3C as "a software system designed to support interoperable machine-to-machine interaction over a network". Web services are frequently just Web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. The idea of a Web service developed from the evolution of the Internet. The intent behind a Web service is to drive the Internet as a transactional tool rather than simply a visual tool. These application-to-application interactions are driven by, and built on, existing standards mentioned below. Web Services consist of Communication Protocols, Service Descriptions, and Service discovery. SOAP (Simple Object Access Protocol) enables communication among Web Services. WSDL (Web Services Description Language) provides a formal, computer readable description of Web Services and UDDI (Universal Description, Discovery, and Integration Directory) is a registry of Web Service descriptions. This paper examines technologies that lay out the foundation of Web Services. First, the web service basics and architecture shall be described. Later, the Extensible Markup Language (XML) and web service protocols - SOAP, WSDL and UDDI shall be examined in more detail. Finally, an overview of the future of Web Services shall be given, followed by a conclusion.

Web Services basics

Web Services is a phrase used to describe the way in which services can be exposed and used on a network, built around the use of technologies such as extensible mark-up language (XML). Web Services concern the way in which software communicates. Software can come in many forms from a simple script on a personal computer to an application on a networked server, through to a large operational support system running on a mainframe computer. We can view this scripts and applications as software components. Consider the following characteristics of such a software component: It can describe itself so that other components can understand the functionality it offers and how to access that functionality. It can allow other components to locate it so it can be used when required. It can be readily invoked whenever another component wishes to use its functions. If such a software component were installed in a network, its services could be used by other software components. Within the last three years, a number of technologies have matured and become world-wide standards to allow the software components to be deployed in this way. These components are said to be providing a Web Service. An example is a web service that returns a credit rating when provided with a users ID, or an order handling system that provides user and usage data to a billing web service which then returns the users bill. Web Services can also be integrated together to provide greater value-add. For example, a travel management Web Service may make use of capabilities of Web Services providing car hire, hotel bookings and car reservations. Or a video on demand Web Service may make use of a communication service that delivers the video stream. So, why are such services called Web Services? The reason is that when exposing the capabilities of software components, we are essentially exposing software services. The goal is for these services to be widely available over the World Wide Web hence the term Web Service.

Web Service Architecture

We identify the core operation of Web Services as the interaction between software agents utilizing particular technologies that encompass exchanging messages, describing Web Services as well as publishing and discovering Web Service descriptions. The figure below illustrates the Web Services Architecture. As shown here, software agents engaged in the web service operations can act in three so called roles: as service providers, service requestors and the service registries.

Figure 1: Web Services Architecture Service providers manage two basic components of a Web Service: the service itself and the service description. A service is a software module implemented in a particular technology (.NET, Java etc.) and accessible over the network. It is invoked by a service requestor and may also function as a requestor itself. The service description is a set of XML documents that contain the details of the interface and implementation, including data types, operations, interaction details, network location and optional metadata. Depending on the roles exercised by the software agents, one of three behaviors (operations) occurs during interaction with other roles: publication of service descriptions, finding and retrieval of service descriptions, and invoking of services based on those descriptions.

XML The Backbone of Web Services

XML is a markup language for documents containing structured information. Structured information contains both content (words, pictures, etc.) and some indication of what role that content plays (for example, content in a section heading has a different meaning from content in a footnote, which means something different than content in a figure caption or content in a database table, etc.). Almost all documents have some structure. A markup language is a mechanism to identify structures in a document. The XML specification defines a standard way to add markup to documents. What's a Document? The number of applications currently being developed that are based on, or make use of, XML documents is truly amazing. The word "document" refers not only to traditional documents, like this one, but also to the myriad of other XML "data formats". These include vector graphics, e-commerce transactions, mathematical equations, object meta-data, server APIs, and a thousand other kinds of structured information.

Fig. 2 two sample physical documents. A note and a receipt. In the figure 2, these documents include no or little demarcation, mostly using visual means, so the overall structure is readable when printed. However, a computer application might have trouble in correctly parsing such a document. Imagine that the order receipt includes an article named Total; it is likely that an application confuses the price of that article with the overall total, or reports an error. From a Computers Point of View, the presented documents are poorly structured.

Fig. 3 the note as XML Document Figures 3 provide an example of very simple document representing the note depicted on figure 2. An XML document contains one or more elements, each of which is demarcated using tags. By assigning tags to portions of document, the semantic structure of the document becomes visible. With such structure, different portions of the data can be easily processed by computer application according to their purpose.

Why XML? In order to appreciate XML, it is important to understand why it was created. XML was created so that richly structured documents could be used over the web. The only viable alternatives, HTML and SGML, are not practical for this purpose. HTML, as we've already discussed, comes bound with a set of semantics and does not provide arbitrary structure. SGML provides arbitrary structure, but is too difficult to implement just for a web browser. Full SGML systems solve large, complex problems that justify their expense. Viewing structured documents sent over the web rarely carries such justification. This is not to say that XML can be expected to completely replace SGML. While XML is being designed to deliver structured content over the web, some of the very features it lacks to make this practical, make SGML a more satisfactory solution for the creation and longtime storage of complex documents. In many organizations, filtering SGML to XML will be the standard procedure for web delivery.

The Web services framework is divided into three areas: Communication Protocols - SOAP, Service Descriptions - WSDL, and Service Discovery - UDDI and specifications are being developed for each. We look at the specifications that are currently the most salient and stable in each area

The Web Service Protocols

Communication: SOAP
Given the Web's intrinsically distributed and heterogeneous nature, communication mechanisms must be platform-independent, international, secure, and as lightweight as possible. XML is now firmly established as the lingua franca for information and data encoding for platform independence and internationalization. Building a communication protocol using XML is thus a natural answer for Web services. SOAP was initially created by Microsoft and later developed in collaboration with Developmentor, IBM, Lotus, and UserLand. SOAP is an XML-based protocol for messaging and remote procedure calls (RPCs). Rather than define a new transport protocol, SOAP works on existing transports, such as HTTP, SMTP, and MQSeries. At its core, a SOAP message has a very simple structure: an XML element with two child elements, one of which contains the header and the other the body. The header contents and body elements are themselves arbitrary XML. Figure 2 shows a SOAP envelope's structure. In addition to the basic message structure, the SOAP specification defines a model that dictates how recipients should process SOAP messages. The message model also includes actors, which indicate who should process the message. A message can identify actors that indicate a series of intermediaries that process the message parts meant for them and pass on the rest.

Fig.4 Structure of SOAP.

Description: WSDL
Speaking a universal language is not very useful unless you can maintain the basic conversations that let you achieve your goals. For Web services, SOAP offers basic communication, but it does not tell us what messages must be exchanged to successfully interact with a service. That role is filled by WSDL, an XML format developed by IBM and Microsoft to describe Web services as collections of communication end points that can exchange certain messages. In other words, a WSDL document describes a Web service's interface and provides users with a point of contact. Our examples are fragments of a WSDL document that describes a Web service that can process the two types of interactions in our SOAP examples.

Figure 5 A Schematic view of WSDL Document Syntax A complete WSDL service description provides two pieces of information: an applicationlevel service description, or abstract interface, and the specific protocol-dependent details that users must follow to access the service at concrete service end points. This separation accounts for the fact that similar application-level service functionality is often deployed at different end points with slightly different access protocol details. Separating the description of these two aspects helps WDSL represent common functionality between seemingly different end points.

Discovery: UDDI
The Universal Description, Discovery, and Integration specifications offer users a unified and systematic way to find service providers through a centralized registry of services that is roughly equivalent to an automated online "phone directory" of Web services. The browseraccessible UDDI Business Registry (UBR) became available shortly after the specification went public. Several individual companies and industry groups are also starting to use "private" UDDI directories to integrate and streamline access to their internal services UDDI provides two basic specifications that define a service registry's structure and operation: A definition of the information to provide about each service, and how to encode it; and A query and update API for the registry that describes how this information can be accessed and updated. Registry access is accomplished using a standard SOAP API for both querying and updating. Here we focus on the first aspect, which provides a good idea of how the registry operates. Organizing Structure UDDI encodes three types of information about Web services: "white pages" information includes name and contact details; "yellow pages" information provides a categorization based on business and service types; and "green pages" information includes technical data about the services. The UDDI registry is organized around two fundamental entities that describe businesses and the services they provide. The businessEntity element provides standard white-pages information, including identifiers (tax IDs, social security numbers, and so on), contact information, and a simple description. Each business entity might include one or more businessService elements that represent the services it provides. Both business and service entities can specify a categoryBag to categorize the business or service

The Future of Web Services

Today's Web Services technology, useful though it is, will be enhanced over the next 2-5 years by the harnessing of Semantic Web technology to deliver a step change in capability.

Web Services provide an easy way to make existing components available to applications via the Internet. However, currently, Web Services are essentially described using semi structured natural language mechanisms, which means that considerable human intervention is needed to find and combine Web Services into an end application.

The Semantic Web will enable the accessing of Web resources by semantic content rather than just by keywords. Resources are defined in such a way that they can be automatically understood and processed by machine. This will enable the realization of Semantic Web Services, involving the automation of service discovery, acquisition, composition and monitoring. Software agents will be able automatically to create new services from already published services, with potentially huge implications for models of eBusiness.

From our studies we conclude that, Web Services Technologies are still relatively new and emerging. While SOAP, WSDL, UDDI define a rough framework for Web Services to function, there are aspects that are not solved. None of these technologies define standards for exchanging particular types of messages. Technologically, these services will be compatible, but semantically, they will not. Also, authentication, access rights, credentials etc. are the issues that are not touched by the technologies mentioned. Fortunately, rather than developing proprietary solutions, major vendors are lining up together W3C to create open standards that are achieving broader acceptance. In addition, Web Services support in recent applications such as Visual Studio .Net makes rapid development of such solutions possible. All this takes us to the conclusion that Web Services are likely to become the major standard for Web Applications.


1. The document Web Services Conceptual Architecture is located at 2. For more information on HTTP from the World Wide Web Consortium, see 3. For more information on SOAP from the World Wide Web Consortium, see 4. For more information on WSDL from the World Wide Web Consortium, see 5. The UDDI project is a cross-industry initiative to create an open framework for describing, discovering, and integrating Web services across the Internet. For more information on UDDI, see 6. For more information on WSFL, see the document titled Web Services Flow Language Guide at 7. See, for example, the standardization work being done by OASIS and (at