Description

Figure 1 - Web Services Description Stack

The service description layer is actually a stack of description documents defined using XML Schema.

It is through the service description that the service provider communicates all the specifications for invoking the web service to the service requestor. The service description is key to making the web services architecture loosely coupled and reducing the amount of required shared understanding and custom programming and integration between the service provider and the service requestor. For example, neither the requestor nor the provider must be aware of the other's underlying platform, programming language, or distributed object model (if any). The service description combined with the underlying XML Message infrastructure defined in the Wire stack sufficiently encapsulates this detail away from the service requestor's application and the service provider’s web service.

We describe the constituent parts of the service description used in the web services architecture in two groups, those used to fully describe one web service and those used to describe interactions or relationships between sets of web services.

Descriptions Applying to a Particular Web Service

The first two layers of the description stack describe the mechanics of invoking a Web service. The interface, or messages the service expects and returns, and the implementation, how to encode the messages and where to send them to. These two layers are satisfied by Web Services Description Language (WSDL) [WSDL] is the de facto standard for XML based service description. The interface and implementation are the minimum standard service description necessary to support interoperable web services.

The web services architecture uses WSDL (Web Services Definition Language)[WSDL 01] for base-level service description. WSDL has been submitted to the W3C for standardization. WSDL is an XML document for describing web services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented (RPC) messages. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints or services. WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only currently described bindings are for SOAP 1.1, HTTP POST, and MIME.

The policy description layer is where the additional description necessary to specify the business context, qualities of service, security requirements and offerings, and management requirements. The WSDL document can be complimented by other service description documents to describe these higher-level aspects of the web service. For example, business context is described using Universal Data Description Interface (UDDI) [UDDI] data structures in addition to the WSDL document.

The presentation layer describes how to render the input and output messages on a screen for a user to interact with. This is particularly useful for rendering Web services to users on many different types of devices.

Figure 2 - Basic Service Description using WSDL

Interface

A service interface definition is an abstract or reusable service definition that may be instantiated and referenced by multiple service implementation definitions. Think of a service interface definition like an IDL (Interface Definition Language), Java interface, or web service type. This allows common industry standard service types to be defined and implemented by multiple service implementers. This is analogous to defining an abstract interface in a programming language and having multiple concrete implementations. Service interfaces may be defined by industry standards organizations, such as RosettaNet or HL7 for the health industry.

In WSDL, the service interface contains elements that comprise the reusable portion of the service description: WSDL:binding, WSDL:portType, WSDL:message and WSDL:type elements as depicted in Figure 2 - Basic Service Description above. In the WSDL:portType element, the operations of the web service are defined. The operations define what XML messages can appear in the input and/or output data flows. Think of an operation like a method signature in a programming language. The WSDL:message element specifies which XML data types constitute various parts of a message. WSDL:message element is used to define the input and output parameters of an operation. The use of complex data types within the message is described in the WSDL:types element. The WSDL:binding element describes the protocol, data format, security and other attributes for a particular service interface (WSDL:portType).

Implementation

The service implementation definition describes how a particular service interface is implemented by a given service provider. It also describes its location so that a requester can interact with it. In WSDL, a web service is modeled as a WSDL:service element. A service element contains a collection (usually one) of WSDL:port elements. A port associates an endpoint (e.g. a network address location (URL)) with a WSDL:binding element from a service interface definition.

To illustrate the allocation of responsibility, the Open Applications Group[OAG] may define a service interface definition for the OAGIS purchase order standard. This service interface definition would define WSDL type(s), message(s), portType(s) and binding(s). This specification would be published at some well-known site (e.g. http://www.openapplications.org/serviceInterfaces/).

A service provider may choose to develop a web service that implements the OAGIS purchase order service interface. The service provider would develop a service implementation definition document that describes the WSDL service, port, and address location elements that describe the network address of the provider’s web service and other implementation specific details.

The service interface definition together with the service implementation definition makes up a complete WSDL definition of the service. This pair contains sufficient information to describe to the service requestor how to invoke and interact with the web service. The service requestor may require other information about the service provider’s end-point. This information is provided by the complete web service description of the service.

Policy

Policy for web services consists of facts, or assertions, and rules that apply to a particular Web service. The policy may be associated with an interface (portType), a binding of that interface to a protocol, or a service instance. Policy would be used to describe or point to documents describing the owning business, associated products, keywords, taxonomies for the service, security policies, quality of service attributes, etc. Policy may be used by the over-arching concerns: security, quality of service, and management; as well as higher layers of the description stack.

Presentation

A web service description may be accompanied by another description document which defines how to display a service to a user and what the interactions between the service and the user should be. This description could be used to render the service on a variety of devices including phones, pdas, and systems.

Description for Relationships between Web Services

There are two types of relationships between services: programmatic and agreements. Programatic relationships are captured by the composition and orchestration description layers. Agreements are more contractual indicating an agreement, possibly legally binding. Agreements are captured by the service level agreement and business agreement description layers.

Since a web service’s implementation is a software module or ‘component’, it is natural to produce web services by composing web services. A composition of web services could play one of several roles. Intra-enterprise web services might collaborate to present a single web service interface to the public, or the web services from different enterprises may collaborate to perform machine-to-machine business-to-business transactions. Alternatively, a workflow manager may call each web service as they participate in a business process. The composition and orchestration layers describe how service-to-service communications, collaborations, and flows are performed. Description languages like BPEL4WS can be used to describe these interactions.

Composition

Orchestration

An orchestration description reflects a simple choreography of web service invocations between two business partners to complete a multi-step business interaction. For example an agreement definition defines roles such as buyer and seller within a purchasing protocol. The agreement definition outlines the requirements that each role must fulfill. For example, the seller must have web services that receive request for quote (RFQ) messages, purchase order (PO) messages and payment messages. The buyer role must have web services that receive quotes (RFQ response messages), invoice messages and account summary messages. This simple choreography of web services into business roles is critical for establishing multi-step service-oriented interactions between business parties. A given service requestor or service provider might be able to play the buyer or seller role in a number of different business process flow standards. By explicitly modeling business agreements and each node’s ability to play roles in the business agreement, the requestor can choose which business agreement to engage in with various provider business partners.

The final layers in the service description stack are for the agreement description Services are intended to be used between two business partners. Anytime businesses exchange information on a fee basis or use services to drive sales and supply, contracts will need to be created to describe the relationship between the business in a legally binding manner. These contracts can be expressed in XML documents as well.

These layers are still under development in the industry.

Service Level Agreements

Business Level Agreements

The stack depicted in the figure above provides for interoperability and enables web services to leverage the existing Internet infrastructure. This creates a low cost of entry to a ubiquitous environment. Flexibility is not compromised by the interoperability requirement, as additional support can be provided for alternative and value-add technologies. For example, SOAP over HTTP must be supported, but SOAP over MQ may be supported as well.