Web Services Architecture and Its Specifications [Electronic resources] : Essentials for Understanding WS-* نسخه متنی

Chapter 3. Metadata

Chapter 2, "Core Messaging." To provide for a robust development and operational environment, services are described using machine-readable metadata. Metadata provides system infrastructure that can be used in a variety of ways. Metadata supports automation and tooling, enables automated service discovery, promotes automation of communication between services, and increases interoperability between the services. By design, Web service metadata serves several purposes. The three most important purposes of metadata are outlined here. It is used to describe the message interchange formats the service can support and to describe the valid message exchange patterns of a service. Metadata is also used to describe the capabilities and requirements of a service. This last form of metadata is called the policy of a service. Message interchange formats and message exchange patterns are expressed in Web Service Description Language (WSDL). Policies are expressed using WS-Policy. Contracts are expressed using all three kinds of metadata just described. Contracts are abstractions that insulate applications from the internal implementation details of the services they rely upon.

Figure 3-1 depicts the XML-based languages used for metadata descriptions in Web services. Contracts use XML Schema for describing the message formats, WSDL describes the message exchange patterns, WS-Policy describes capabilities and requirements, and "other methods" are represented by the area outside the smaller ovals. The fact that WSDL is completely contained in Contract means that all its information is used in the contract of a service.

WSDL was the first widely adopted mechanism for describing the basic characteristics of a Web service. Messages described in WSDL are grouped into operations that define the basic message patterns. The operations are grouped into interfaces called ports that specify an abstract contract for a service. Finally, ports and bindings are used to associate portTypes with concrete transports and physical deployment information. A WSDL description is a first step for the automatic identification of all characteristics of the target service and for enabling software development tools.

WSDL specifies what a request message must contain and what the response message will look like in unambiguous notation. The notation that a WSDL file uses to describe message formats is based on XML Schema. This means it is both programming-language-neutral and standards-based, which makes it suitable for describing service interfaces that are accessible from a wide variety of platforms and programming languages. In addition to describing message contents, WSDL can define where the service is available and what communications protocol is used to talk to the service. This means that the WSDL file can specify the base elements required to write a program to interact with a Web service. Several tools are available to read a WSDL file and generate the code required to produce syntactically correct messages for a Web service.

While WSDL is a good starting point, it is not sufficient to describe all aspects of a Web service. WSDL allows only a rather small set of properties to be expressed. Examples of more detailed information that is necessary for Web services include the following:

Operational characteristics The service supports SOAP version 1.2.

Security characteristics Kerberos [KERBEROS] tickets are required for access to the service.

Deployment characteristics The service is available only between 9 am and 5 pm.

First-generation Web services must exchange metadata out of band using proprietary protocols. This issue is addressed with WS-Policy [WS-Policy]. WS-Policy provides a general-purpose model and syntax to describe and communicate the policies of a Web service. It specifies a base set of constructs that can be used and extended by other Web service specifications to describe a broad range of service requirements and capabilities. WS-Policy introduces a simple and extensible grammar for expressing policy assertions and a processing model to interpret them. Assertions can be combined into logical alternatives.

Policy assertions allow programmers to add appropriate metadata to service information either at development time or at run time. Examples of development-time policies include the maximum allowed message size, which header elements are required to be encrypted or signed, quality of service characteristics, or the exact version of a supported specification. Examples of run-time policies include mandatory service down time or the unavailability of a Web service during a given administrative procedure, such as regular hardware maintenance. Examples of policies that relate to security are presented in Chapter 4, "Security."

Individual policy assertions can be grouped to form policy alternatives. Policies are collections of policy alternatives. To facilitate interoperability, policies are defined in terms of their XML Infoset representation. A compact form for policies is defined to reduce the size of policy documents while preserving interoperability.

Policies are used to convey conditions for interaction between two Web service endpoints. Satisfying assertions in a policy usually results in behavior that reflects these conditions. Thus, policy assertion evaluation is central to identifying compatible behaviors. A policy assertion, the building block for policies, is supported by a requestor if and only if the requestor satisfies the requirement, or accommodates the capability, corresponding to the assertion. In general, this determination uses domain-specific knowledge. A policy alternative is supported by a requestor if and only if the requestor supports all the assertions in the alternative. This is determined mechanically using the results of the policy assertions. Also, a policy is supported by a requestor if and only if the requestor supports at least one of the alternatives in the policy. This determination is also mechanical once the policy alternatives have been evaluated. Note that although policy alternatives are meant to be mutually exclusive, it cannot be decided in general whether or not more than one alternative can be supported at the same time.

To convey policy in an interoperable form, a policy expression is an XML Infoset representation of a policy. The normal form policy expression is the most straightforward Infoset; equivalent, alternative Infosets allow compactly expressing a policy through a number of constructs. Policy expressions are the base building block for policies. Two operators are used to express their assertions: All and ExactlyOne. The All operator specifies that all the assertions present in a collection of policy alternatives have to hold for the policy assertion to be satisfied. The ExactlyOne operator specifies that exactly one of the assertions present in a collection of policy alternatives has to hold for the policy assertion to be satisfied.

Policies layer on top of, and augment, WSDL descriptions. Policies are associated with Web services metadata, such as WSDL definitions or UDDI [UDDI] entities through the use of WSPolicyAttachment [WS-PA]. Policies can be associated with resources either as an intrinsic part of their definition or separately. Mechanisms are defined for each of these purposes. In particular, policies can also be used with individual SOAP messages. When multiple policy attachments are made for an entity, they jointly determine the effective policy for the entity. Care must be taken when attaching policies at different levels of the WSDL hierarchy, because the net result for each level of a hierarchy is the effective policy. As a general rule for self-description and human-understandable clarity, it is preferable to be verbose and repeat a policy assertion at each level of a hierarchy that it applies, than to be terse and rely on the mechanism that computes the effective policy. In a WSDL document, a message exchange with a deployed endpoint could contain effective policies in all four subject types simultaneously.

The combination of WS-Policy and WS-PolicyAttachment provides an increased ability to programmatically discover and reason about the policies supported by other services. Flexibility to add policies is an important complement to the WSDL information that describes the message interactions.

WSDL and WS-Policy both define formats for metadata but do not specify mechanisms for acquiring or accessing metadata for a given service. In general, service metadata can be discovered using a variety of techniques. To enable services to be self-describing, the Web services architecture defines SOAP-based access protocols for metadata in WS-MetadataExchange [WSMEX]. The design adopted in this specification addresses long-lasting arguments of whether, given a URI that identifies an entity, the operation to retrieve metadata using such URI refers to the entity itself or to an XML document that relates to the entity. To differentiate between these two alternatives, separate operations are defined in the specification. The GetMetadata operation is used to retrieve metadata that is found at the endpoint reference of the request. The Get operation is similar, but it's designed to retrieve metadata that is referenced in some metadata section and that is to be retrieved at the endpoint reference where it is stored.

The metadata exchanged using WS-MEX can be described as a resource. A resource is defined as any entity addressable by an endpoint reference where the entity can provide an XML representation of itself. Resources form the basis needed to build state management in Web services.