Professional Documents
Culture Documents
Presented by
Sagar Patil
(contactme@sagarpatil.com)
Tousif Peerzade
(somesleep@gmail.com)
Index Contents
2. Web Services Basics a. Introduction b. Characteristics of Web Services c. Use of Web Services
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
7. Conclusion
8. References
Abstract
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.
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.
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
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
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.
Conclusion
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.
References
1. The document Web Services Conceptual Architecture is located at http://www.ibm.com/software/solutions/webservices/documentation.html. 2. For more information on HTTP from the World Wide Web Consortium, see http://www.w3.org/Protocols/. 3. For more information on SOAP from the World Wide Web Consortium, see http://www.w3.org/TR/SOAP/. 4. For more information on WSDL from the World Wide Web Consortium, see http://www.w3.org/TR/wsdl/. 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 http://www.uddi.org/. 6. For more information on WSFL, see the document titled Web Services Flow Language Guide at http://www.ibm.com/software/solutions/webservices/documentation.html. 7. See, for example, the standardization work being done by OASIS and XML.org (at http://www.oasis-open.org/)