Web services

Web Services refers to the technologies that allow for making connections. Services are what you connect together using Web Services. A service is the endpoint of a connection. Also, a service has some type of underlying computer system that supports the connection offered. The combination of services - internal and external to an organization - make up a service-oriented architecture.

Service-oriented architecture (SOA) definition

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification. 

Services

If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. 

Connections

The technology of Web services is the most likely connection technology of service-oriented architectures. Web services essentially use XML to create a robust connection.

The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. How those connections are defined is explained in Web Services explained. A service provider can also be a service consumer.

Web Services Description Language (WSDL) 

Web Services Description Language (WSDL) is a format for describing a Web Services interface. It is a way to describe services and how they should be bound to specific network addresses. WSDL has three parts: 

• Definitions 
• Operations 
• Service bindings 

Definitions are generally expressed in XML and include both data type definitions and message definitions that use the data type definitions. These definitions are usually based upon some agreed upon XML vocabulary. This agreement could be within an organization or between organizations. Vocabularies within an organization could be designed specifically for that organization. They may or may not be based on some industry-wide vocabulary. If data type and message definitions need to be used between organizations, then most likely an industry-wide vocabulary will be used. 

XML, however, is not necessary required for definitions. The OMG Interface Definition Language (IDL), for example, could be used instead of XML. If a different definitional format were used, senders and receivers would need to agree on the format as well as the vocabulary. Nevertheless, over time, XML-based vocabularies and messages are likely to dominate. XML Namespaces (new window) are used to ensure uniqueness of the XML element names in the definitions, operations, and service bindings. 

Operations describe actions for the messages supported by a Web service. There are four types of operations: 

§ One-way: Messages sent without a reply required 

§ Request/response: The sender sends a message and the received sends a reply. 

§ Solicit response: A request for a response. (The specific definition for this action is pending.) 

§ Notification: Messages sent to multiple receivers. (The specific definition for this action is pending.) 

Operations are grouped into port types. Port types define a set of operations supported by the Web service. 

Service bindings connect port types to a port. A port is defined by associating a network address with a port type. A collection of ports defines a service. This binding is commonly created using SOAP (new window), but other forms may be used. These other forms could include CORBA Internet Inter-ORB Protocol (IIOP), DCOM, .NET, Java Message Service (JMS), or WebSphere MQ to name a few. 

Web Services explained 

First, defining Web Services using Web Services Description Language (WSDL) will be reviewed. That will be followed by SOAP, which provides means of sending messages. 

Using the Web Services Description Language (WSDL)

The Web Services Description Language (WSDL) forms the basis for Web Services. The following figure illustrates the use of WSDL. At the left is a service provider. At the right is a service consumer. The steps involved in providing and consuming a service are: 

A service provider describes its service using WSDL. This definition is published to a directory of services. The directory could use Universal Description, Discovery, and Integration (UDDI). Other forms of directories can also be used. 

A service consumer issues one or more queries to the directory to locate a service and determine how to communicate with that service. 

Part of the WSDL provided by the service provider is passed to the service consumer. This tells the service consumer what the requests and responses are for the service provider. 

The service consumer uses the WSDL to send a request to the service provider. 

The service provider provides the expected response to the service consumer. 

Using Universal Description, Discovery, and Integration (UDDI) 

The directory shown in the above figure could be a UDDI registry. The UDDI registry is intended to eventually serve as a means of "discovering" Web Services described using WSDL . The idea is that the UDDI registry can be searched in various ways to obtain contact information and the Web Services available for various organizations. How much "discovery" will be used in the early days of Web Services is open to discussion. Nevertheless, even without the discovery portion, the UDDI registry is a way to keep up-to-date on the Web Services your organization currently uses. More on Universal Description, Discovery, and Integration (new window). An alternative to UDDI is the ebXML Registry (new window).

Using SOAP 

All the messages shown in the above figure are sent using SOAP. (SOAP at one time stood for Simple Object Access Protocol. Now, the letters in the acronym have no particular meaning .) SOAP essentially provides the envelope for sending the Web Services messages. SOAP generally uses HTTP , but other means of connection may be used. HTTP is the familiar connection we all use for the Internet. In fact, it is the pervasiveness of HTTP connections that will help drive the adoption of Web Services. More on SOAP and Messaging (new window). 

The next figure provides more detail on the messages sent using Web Services. At the left of the figure is a fragment of the WSDL sent to the directory. It shows a CustomerInfoRequest that requires the customer's account to object information. Also shown is the CustomerInfoResponse that provides a series of items on customer including name, phone, and address items. 

At the right of this figure is a fragment of the WSDL being sent to the service consumer. This is the same fragment sent to the directory by the service provider. The service consumer uses this WSDL to create the service request shown above the arrow connecting the service consumer to the service provider. Upon receiving the request, the service provider returns a message using the format described in the original WSDL. That message appears at the bottom of the figure.

Using XML with WSDL 

WSDL uses XML to define messages. XML has a tagged message format. This is shown in the above figure. The tag <city> has the value of Burnsville. And </city> is the ending tag indicating the end of the value of city. Both the service provider and service consumer use these tags. In fact, the service provider could send the data shown at the bottom of this figure in any order. The service consumer uses the tags and not the order of the data to get the data values. More on the use of XML tags and a comparison of XML to using fixed record formats can be found in chapter 3 of Web Services and Service-Oriented Architectures: The Savvy Manager's Guide. Also see XML processing (new window) for an overview of the XML processing in a service. 

Simplified Web Services notation 

For other figures on this site, a simplified notation will be used for Web Services. This is shown below. In the simplified notation, the directory is implicit in the wide rectangle labeled "Web Services" at the top of this figure. You could think of Web Services much like the bus in a PC in which you plug various circuit boards. Other middleware solutions appear similar and use the same "bus" concept. See Prior Service-Oriented Architecture specifications (new window). 

Another important concept in service-oriented architectures is that any service provider could also be a service consumer. This is why the figure below shows only services at the bottom of the figure under the Web Services bus rather than a "service provider" and a "service consumer". 

SOAP provides the envelope for sending Web Services messages over the Internet/Internet. It is part of the set of standards specified by the W3C. Those standards are an alternative to the principles of Representational State Transfer (REST) (new window).

The SOAP envelope contains two parts: 

1. An optional header providing information on authentication, encoding of data, or how a recipient of a SOAP message should process the message. 
2. The body that contains the message. These messages can be defined using the WSDL specification. 

SOAP commonly uses HTTP, but other protocols such as Simple Mail Transfer Protocol (SMTP) may byused. SOAP can be used to exchange complete documents or to call a remote procedure. 

NOTE: SOAP at one time stood for Simple Object Access Protocol. Starting with SOAP Version 1.2, the letters in the acronym have no particular meaning