16-11-2010

Web Services

WEB SERVICES

Abstract
The concept of web services has acquired a strong presence lately, and it has been even said that it would change the programming of those applications oriented to the Internet towards a service oriented architecture. This idea becomes more powerful after Microsoft announcement of its new .NET strategy, based on the web services model. This document describes the web services and the general structure of the model. Besides, there is an introduction to the standards on which this model is based such as SOAP, WSDL y UDDI.

What is a web service?

A web service is an application that can be described, published, located and called through a network, usually the Internet. It combines the best aspects of development based on components and the Web. Like components, web services are features located within a black box, and can be reused without worrying about how were they implemented. Unlike the present components technology, they are not accessed through specific protocols of the object model such as RMI, DCOM or IIOP; they are accessed using web protocols such as HTTP and XML. The web services interface is defined in terms of the messages that they accept and return; thus, web services consumers can be implemented in any platform and in any programming language; they must just be able to create and consume the messages defined by the web services interface.

The web services model.

The basic architecture of the web services model describes a consumer, a supplier and, occasionally a broker. The publishing, finding and binding operations are related to these agents. The basic idea is that a supplier publishes his services in a broker and then a consumer connects to the broker to find the services he wants and, once he does, a binding is made between the consumer and the broker. Each entity can play some of the roles or all of them.

In view of all the above, there are certain requirements at the time of developing or consuming web services: A standard manner of representing data. gxtechnical.com//Web_Services.htm 1/8

16-11-2010

p gWeb Services XML is the obvious option for this requirement. A common and extensible messages format. SOAP is the one chosen in this case; SOAP is a light protocol for information exchange. We will see it in more detail further on in this document A common and extensible language to describe services. In this case, the option is WSDL. This is an XML based language, jointly developed by IBM and Microsoft. We will see it in more detail further on in this document. A way to discover services in the Internet. UDDI is used in this case; it specifies a mechanism allowing suppliers and consumers publishing and locating the services, respectively. We will see it in more detail, further on in this document.

Advantages and challenges.

Web services are targeted to be the foundation stone of the distributed systems new generation. These are some of the points grounding this statement. Interoperability: Any web service can interact with another web service. Since web services can be implemented anywhere, developers do not need to change their development environments to produce or consume web services. Ubiquity: Web services communicate using HTTP and XML. Thus, any device supporting these technologies can implement or access web services. Very soon, they will be present in telephones, cars, and even selling machines that will warn the central office whenever the stock is less than expected. Encapsulating reduces complexity. All components in a web service model are web services. The important issue is the interface offered by the service and not how is it implemented; thus, complexity is reduced. Easy to use: The concept behind web services is easy to understand. Besides, some vendors such as IBM or Microsoft offer toolkits allowing developers to create web services swiftly and easily. Industry support: All important software companies support SOAP and are fostering web services development. E.g., the new Microsoft .NET platform is based on web services, simplifying significantly the development of web services that could then be consumed by a web service using IBMs VisualAge and vice versa. Besides, there are certain technical challenges to be faced by web services to succeed. Many of these challenges are related to the open environment where they have to survive. These are some of these points: Discovery: How does a web service announce itself to be discovered by another service? What does it happen if the service changes or it moves after its announcement? WSDL and UDDI are the two new standards managing this point. Reliability: Some web services are more reliable than other. How can this reliability be measured and communicated? What does it happen when a web service is temporally offline? Should we localize and use an alternative service offered by another company or should be wait until the service is on-line again? Security: Many web services are published to be used without any restriction whatsoever, but many of them will need authentication to be used only by authorized users. How does a web service authenticate users? Does it authenticate users at the level of the method implementing it or does it use another web service to carry out the authentication? Responsibility
gxtechnical.com//Web_Services.htm 2/8

16-11-2010

Web Services If the web service is not freely accessed, how can I define the number of times a consumer can access a web service once hired? How do we charge their use? How do we indicate that a product is no longer on-line?

Associated Technologies
The web services model is based on certain emerging technologies resulting from the work of several companies and organizations such as IBM and Microsoft. These technologies are SOAP, WSDL and UUDI.

SOAP (Simple Object Access Protocol)

SOAP is a protocol for information exchange in a decentralized and distributed environment. It is the most used protocol to develop information exchange in the web services model. It is based on XML and it can be potentially used in combination with a variety of communication protocols; the most used of these protocols is HTTP. Thus, HTTP is used to transport information and XML to represent this information. The complete protocol can be found at http://www.w3.org/TR/soap

SOAP COMMUNICATION MODEL

SOAP communication model is very similar to HTTP. A client makes a request, then, the server, that is hearing these requirements, responds to it providing the required information or sending an error message in case the requirement is not valid. The SOAP message is made up with a compulsory SOAP envelope element, an optional SOAP header, and a compulsory SOAP body as XML document. The SOAP header is used to define the information regarding the requirement while the SOAP body contains the called method and the parameters to call the method.

All the above is a request/response messages model with a manner to describe a group of methods and transfer parameters to them. This seems to be the basis of the RPC protocol and, in fact, is the most common way of using SOAP. The potential issue is to deliver this on the Internet using HTTP to develop communications between organizations, allowing communications
gxtechnical.com//Web_Services.htm 3/8

16-11-2010

Web Services between applications with different platforms, operative systems and programming languages.

There follows a SOAP message embedded in an HTTP request:

This example calls the StockQuote service by calling the GetLastTradePrice method with the DIS symbol as parameter. This is the response to the previous requirement, and returns the price of the required action:

If you are surprised by the apparent complexity of the SOAP protocol, and are thinking how difficult would it be to assemble requirement messages and parse response messages, do not worry; most programming languages provide, or will provide support to carry out these procedures. The fundamental idea is using some object, providing it with a WSDL and indicating it what method will be called and what parameters will be used to call it. This allows assembling the SOAP message in runtime, sending it and parsing the result assigning it to some variable in a transparent manner for the user, as it he would have made a common call.

WSDL: Web Services Description Language

WSDL is an XML based language used for Web Services. It has been provided by the W3C for standardization. A file with WSDL format provides information on the different methods (operations) provided by the Web Service, it shows how to access them and what formats should have those messages to be send an received. It is like a contract between the service supplier and the client, where the supplier assumes the compromise to provide certain services only if the client sends a
gxtechnical.com//Web_Services.htm 4/8

16-11-2010

Web Services requirement with a specific format. This is the principal document at the time of documenting a Web Service, but it may not be the only one. In most cases it is advisable to accompany this document with a document written in a natural language, providing information on what does each method provided by the Web Service do, as well as examples such as the SOAP messages the service accepts and responds.

To

sum up, we can say that a WSDL file describes the following: Messages that the service accepts and messages that the service responds. Protocols that the service supports. Where to send the messages.

WSDL FILE FORMAT:

There follows the description of the basic format of a WSDL file. The complete specification of this language can be found at http://www.w3.org/TR/wsdl.html A file with WSDL format contains basically the following elements: Type: Describes the non-standard types used by the messages (Message). Message: Defines the data contained in the messages transferred from one point to the other. PortType: Defines a collection of operations provided by the service. Each operation has an input message and an output message corresponding to some previously defined Message. Binding: Describes the protocols used to carry out the communication in a specific PortType; at present, the protocols supported are: SOAP, HTTP GET, HTTP POST and MIME, from which SOAP is the most used one. Port: Defines an address (URL) for a specific Binding Service: Defines a collection of Ports. The following is an example of WSDL file: It defines two messages (Simple.foo and Simple.fooResponse), then, it defines a method called foo that receives the message Simple.foo and returns the message Simple.fooResponse. Then, a binding is defined for the foo method associating it to the SOAP protocol. Lastly, a physical URL is given that implements what was previously described.

gxtechnical.com//Web_Services.htm

5/8

16-11-2010

Web Services

INTERFACE AND IMPLEMENTATION

The basic structure of a file with WSDL format could be divided in two logical parts: the service interface and the file implementation. This logical division divides the elements as follows: Service Interface: Type, Message, PortType, Binding. It has an abstract and reusable definition of the service that can be instantiated and referred by different suppliers of the service. Service implementation: Port, Service. It contains the implementation of a specific service Interface. As from this logical division a standard can be defined, by means of a service Interface, to gxtechnical.com//Web_Services.htm 6/8

16-11-2010

Web Services make, for instances, purchase orders that can be reused and implemented by all the companies, without the need to redefine each of them in the interface.

If, like in the case of SOAP, you feel worried about the complexity of the WSDL files, again, do not worry; most language programs provide tools to generate the WSDL file automatically, with a specific method or function.

UDDI (Universal Description, Discovery and Integration).

UDDI (www.uddi.org) is a project that was initially proposed by Ariba, Microsoft and IBM; it is a standard to register and discover web services. The idea is that the different companies register their information regarding the web services they provide for them to be discovered and used by potential users. The information is entered to the UDDI companies register, a service logically centralized and physically distributed through multiple nodes that replicate its information regularly. Once a company is registered at a specific node of the UDDI companies register, the information is replicated to the other nodes and remains available to be discovered by other companies.

UDDI SCHEME
The basic information model used by the UDDI registers is defined in an XML scheme. This scheme defines four basic types of information, each of which provides the class of information a user needs to know, to use a web service of another company. The four types of information are: Information on the business. This type of information is defined as the businessEntity element. It contains information about the company, such as its name, contacts, type of company, etc. Information on the service: The businessServices elements are within the businnessEntity element. These elements contain information about the web services usually grouped by business processes or services categories. Information on the binding. The bindingTemplate elements are within each businessServices element. Each of them provides a physical address to make contact with the services described above. Information on the service specifications. Each bindingTemplate has an associated tModel that provides information on the service specifications; e.g: how should the messages the service accepts and responds look, etc. A tModel can be associated to bindingTemplate elements of different companies providing the same service specification. Thus, using the tModels, it is possible to find all the companies providing such service.

For further information on the UDDI scheme please refer to:

gxtechnical.com//Web_Services.htm 7/8

16-11-2010

Web Services http://www.uddi.org/pubs/DataStructure-V2.00-Open-20010608.pdf

API UDDI
The access to the UDDI register, both to make searches or to enter or modify a register, can be made through a web page implementing the access or using certain interfaces (web services) providing the UDDI specification. These interfaces are described in an API that can be divided in two logical parts, the queries API and the publication API. For further information on the UDDI API, please refer to: http://www.uddi.org/pubs/ProgrammersAPI-V2.00-Open-20010608.pdf

An example
The manners to do business using the web services are quite different. The consumer could pay to use the services provided by a supplier, or the supplier could pay so that the services offered by him appear in a specific consumer and, there are even cases where none of them pay to consume or provide the services, respectively. This is the case presented below. The example has been taken from real life and is about an airline: Southwest. In its portal http://www.southwest.com/, this airline allows making tickets reservations and also, as added value for its clients, it offers hotel bookings and car rental. The data to make these reservations are taken from web services provided by the different hotels and car rentals. This is an example about web services usage where neither the consumer nor the supplier pays; this exchange is useful for both of them, since the airline provides more added value to its clients and the hotels and car rentals have good exposure to potential clients. Furthermore, these companies did not publish their services for them to be used exclusively by the airline, its services can be discovered and used by any airline requiring them. This example shows clearly the great power of web services and the advantage companies that know how to use them may have regarding other companies. Imagine that you have to book air tickets and have the chance to choose between an airline that, besides booking your tickets, allows you making hotel bookings, and another airline that does not offer you this chance; what airline would you choose? Besides, imagine you are the owner of a car rental and you know that your competitor is providing services at an airline portal and you are not, what would you do?

gxtechnical.com//Web_Services.htm

8/8