|
|
The Web services stack (adapted from Kreger 2001), shown in Figure 1.10, categorizes the technology of Web services into a layered model. The stack starts at the bottom with the basic technologies that allow data to transfer from one machine to another. Each layer builds on the lower layers and adds higher-level abstractions. The upper layers of the stack do not necessarily depend on the lower layers and in some ways are orthogonal concerns. They are shown in this format simply to demonstrate a higher level of abstraction.
The main function of the service transport layer is to transfer data from one machine to another. This is the protocol for the transmission of data for Web services. Web services use multiple transports to transfer data from service to service-including, but not limited to, HTTP, SMTP, and FTP.
The most popular protocol by far for use in Web services is HTTP. The Internet and the World Wide Web use HTTP to transmit data. HTTP is not blocked by most firewalls and thus is the standard for interoperable systems. HTTP 1.0 is a connectionless and stateless protocol. This means that each request and response a client sends and receives from a server is independent and not in the overall context of a conversation.
The messaging layer of the technology stack describes the data formats used to transmit data from one service to another over the transport. XML is the base format used for Web services. XML is a text-based protocol whose data is represented as characters in a character set. The XML data is structured as a tree with elements, and the entire tree structure is called a document. XML has no data description separate from the data itself, unlike fixed or delimited data formats. The messages are self-describing. The data has specially formatted tags around it that give the data a name as well as a position in the document's tree structure.
Simple Object Access Protocol (SOAP) is a specification that tells a service consumer and a service provider how to format and read a specially formatted XML message for use in a service. A SOAP message has three sections: the envelope, the header, and the body.
The envelope is the top element of the XML message. It indicates that the message is a SOAP message, and it has instructions for processing the message.
The SOAP header contains application context information and directives. The header information is usually read and processed by the server, not the service. For instance, if an application needs entries for authentication or transaction management, the header will contain data for these features. SOAP messages can be passed along through multiple intermediaries between the service consumer and the service provider. Each intermediary reads the header information and uses it for routing, logging, and other system functions.
The SOAP body contains the application data. Web services support multiple message exchange patterns. A SOAP message may be sent in a document-oriented format or an RPC style format. In a document-oriented message exchange, the service consumer and provider exchange XML documents. In the RPC-style message exchange, data is passed as arguments. SOAP messages are by nature one-way transmissions from a sender to a receiver but are usually combined to implement a request/response model.
For an extensive look at the SOAP protocol, please refer to Chapter 4.
The service description specifies three aspects of the service:
Operations the service has made available
Messages the service will accept
The protocol to which the consumer must bind to access the service
Web services uses the Web Services Description Language (WSDL) to specify a service contract. The service contract is a description of a set of endpoints that operate on messages and the specification for how an XML document should be formatted when it is sent to the endpoints. An endpoint is a network address that accepts a message formatted to the specification defined in the WSDL. WSDL uses the term port to describe a service endpoint for a message. WSDL describes the contract for a service as a collection of ports the service has made available.
The service consumer uses the service description in one of two ways. At development time, the consumer can generate a service stub by using the service description. The service stub is a class that has an API that matches the service description. The service consumer binds to the stub at compile time. This is called "early binding." Web services also support the concept of "late binding," a runtime-only binding between the consumer and the producer. This is done by using a dynamic proxy configured dynamically at runtime by using the WSDL description of the service.
Chapter 5 discusses WSDL in depth.
Web services support the concept of dynamic discovery of services. A consumer of a service uses a service registry to find the services it is interested in using. Universal Description, Discovery and Integration (UDDI) is a Web service itself that supports a standard set of services that allow a Web service consumer to dynamically discover and locate the description for a Web service. UDDI registries are themselves Web services that expose an API as a set of well-defined SOAP messages. The Web service provider and Web service consumer use SOAP and HTTP to publish and retrieve information about services in the registry. Public UDDI registries contain a Web services contact, business owner, and technical information about the Web service. UDDI supports two types of conversations:
The service provider uses the UDDI directory to publish information about the Web services it supports.
The Web service consumer sends SOAP-formatted XML messages over HTTP to the UDDI directory, to retrieve a listing of Web services that match its criteria.
For more on UDDI, please refer to Chapter 6.
Service composition, an emerging topic in Web services, refers to the ability to combine Web services into a business process. This is also referred to as service orchestration or service choreography. Service composition is the ability to sequence and manage conversations between Web services into a larger transaction. For example, a transaction that adds a customer to a bank account service might also create several accounts along with adding the customer information to the customer service. All of these requests are managed in the context of a larger business process flow that either succeeds or fails as a whole.
There are a number of proposed languages for specifying business process flows; the two most popular are WSFL and XLANG. Recently, IBM, Microsoft, and BEA combined both specifications into a single specification called Business Process Execution Language for Web Services (BPEL4WS).
|
|
