Metadata plays a fundamental role in Service-Oriented Architectures. The term metadata refers to explicit information about a service that is encoded in a machine-readable format. Explicit metadata encodes in an unambiguous way details about the interaction contract between service requesters and providers. Technical capabilities and requirements of service endpoints are encoded using XML Schema, Web Services Description Language (WSDL), and WS-Policy definitions. Service requesters are developed and configured to comply with these metadata specifications; service providers are selected according to the metadata that a requester expects. Explicit metadata is the key feature of SOAs that enables loose coupling between requesters and providers. As such, metadata is required in multiple steps of the application lifecycle (development, deployment, runtime) and in different scenarios. The central registry model, which is exemplified by the UDDI standard, covers one important set of scenarios. These scenarios and use cases were already discussed in Chapter 8, “UDDI.”
Another set of scenarios is not completely addressed by the central repository model. These are dynamic scenarios in which requesters discover service endpoints at runtime, and the properties of the interaction are customized to fit a particular requester. These scenarios are served by the process of bootstrapping the interaction. In bootstrapping, the interacting endpoints exchange their service definition and configuration metadata prior to the actual interaction. Then they use the retrieved metadata to dynamically configure the endpoints’ capabilities.
The bootstrapping approach allows much more flexible configuration of the interacting endpoints. You can customize the interaction to its specific conditions: the identity of the requester endpoint, the date and time, and any relevant business or technical conditions. You obtain the corresponding endpoint metadata just in time to refresh possibly stale cached copies and to update the endpoint’s configuration.
The bootstrap works best when you can assume a direct, nonmediated interaction between requesters and providers. The service requester directly queries the service endpoint for its metadata and the requester gets a fresh, customized copy of it. However, to support this model, you have to assume that every endpoint supports a metadata retrieval interface in addition to its business interface. How this function is actually provided is essentially irrelevant. An endpoint might redirect requests for metadata to another endpoint or a URL providing the metadata on its behalf. Whether the endpoint supports the metadata exchange or the runtime environment transparently provides it is an implementation detail. The key point is the ability of the service requester to directly request from its target endpoint updated, customized metadata.
The Web Services Metadata Exchange specification (WS-MetadataExchange) defines a simple yet flexible interface to allow service endpoints to provide metadata information to requesters and support the bootstrapping of Web service interactions. The WS-MetadataExchange interface is flexible and could be used to retrieve general information from the endpoint, not necessarily constrained to metadata. However, the specification clearly states that the operations should be used only to retrieve metadata (that is, endpoint description) information, and that this information applies exclusively to the service endpoint or its associated resources. This limitation is important to maintain clear and distinct semantics of the bootstrap process.
WS-Metadata Exchange builds around the notion of querying endpoints directly for their relevant metadata. To do so, it defines a simple WSDL interface that enables service requesters to query the services they intend to use for specific metadata properties. The WS-MetadataExchange interface follows two important design principles: extensibility of the set of metadata languages and definitions (“dialects”), and the ability to redirect metadata queries to dedicated endpoints.
You can associate different types of metadata with an endpoint. Policies, service descriptions (in the form of WSDL documents), and associated XML Schemas are examples of metadata that you can associate with a service endpoint. However, you can define other forms of metadata to describe aspects of an endpoint as new industry standards are developed or higher forms of interaction are built on top of the basic Web services framework (such as semantically rich interactions, with the associated semantic description of services). The design of the WS-MetadataExchange interface takes this fact into account by assuming that the set of possible metadata dialects is naturally extensible. The WS-MetadataExchange specification recognizes certain metadata dialects (discussed in the next section) but also supports arbitrary metadata dialects. Service requesters and service providers can specify the type of metadata they intend on retrieving or providing, respectively.
Metadata dialects are specific XML languages that represent properties of a service endpoint. Each metadata dialect is in turn represented by a unique URI. Typically, dialect identifiers correspond to the namespace URI that identifies the XML Schema definition of the language (the target namespace of its defining XML Schema). Following are the dialects that the WS-Metadata Exchange specification explicitly recognizes:
The XML Schema dialect corresponds to the schema definition files for the messages that are exchanged by the endpoint.
The WSDL dialect provides the WSDL description of the endpoint.
The WS-Policy dialect encodes the set of policies that apply to the endpoint using a WS-Policy expression.
The WS-PolicyAttachment dialect encodes PolicyAttachment elements that associate a policy with a particular resource that relates to the endpoint.
The WS-MetadataExchange dialect indicates an additional source of metadata for the endpoint, by using the “Metadata” element defined in the WS-MetadataExchange identification.
If the dialect URI determines the type of metadata exchanged, the metadata identifier indicates a specific metadata definition, such as a WSDL target namespace, an XML Schema target namespace, or a policy identifier. Identifiers allow requesters to ask for specific descriptions, as opposed to types of definitions (which are indicated by the dialect). Certain metadata dialects, such as the WS-PolicyAttachment dialect, might not support identifiers. It is important to observe that, when identifiers are supported, they are scoped to a specific dialect. For example, a WSDL and an XML Schema document might have the same target namespace. Therefore, the interpretation of the identifier is relative to the dialect within which it is used.
The amount of metadata that is associated with an endpoint can be large. In addition, even though the metadata exchange model has the service endpoint provide its own metadata to requesters, it is important that endpoints can offload this function to dedicated endpoints when required. WS-MetadataExchange allows service endpoints to provide their responses to metadata queries in the form of a dedicated endpoint (a “metadata reference”) or a URL (a “metadata location”) from which the actual metadata is to be retrieved, through a Web services or traditional Web request. The goal of this design is to allow endpoints and infrastructure deployers to deal flexibly with the load that is associated with the metadata exchange function.
WS-MetadataExchange introduces two metadata request operations: one for general-purpose metadata queries, and a second one for retrieval of metadata from metadata reference endpoints. Endpoints that support the WS-MetadataExchange specifications are required to support only the first one. Referenced endpoints that are given as metadata references are required to support the second.
The GetMetadata operation is the only required operation for WS-MetadataExchange-compliant endpoints. Requesters use it to solicit metadata from the service endpoint. GetMetadata allows several types of requests, enabling generic, dialect-specific, and definition-specific metadata requests.
A service requester uses a generic metadata request to ask for all metadata that is relevant to the interaction with the target endpoint, without imposing a restriction on the metadata to be returned. The service endpoint returns metadata that includes as many dialects as it considers relevant for the interaction with this requester. No additional parameters need to be specified in the request message.
A dialect-specific request retrieves applicable metadata of a single dialect, such as all policies or WSDL definitions that apply to the service. The requester only needs to specify the desired dialect with the request; it is up to the service endpoint to return as much information as is available and deemed relevant for the interaction.
A definition-specific request retrieves specific metadata definitions of a particular dialect as identified by a single metadata identifier. Recall that identifiers are scoped to a particular dialect. If the requested definition is available and relevant to the service endpoint, it will be returned with the response. Note that more than one definition might be returned corresponding to a given identifier.
The generic format of the GetMetadata request message is shown next. Observe that the generic request encodes an empty GetMetadata element, the dialect-specific request adds a nested element including the dialect URI, and the definition-specific one includes two elements—one with the dialect and a second one with the identifier.
<wsx:GetMetadata> [<wsx:Dialect>xs:anyURI</wsx:Dialect> [<wxs:Identifier>xs:anyURI</wsx:Identifier>]? ]? </wsx:GetMetadata>
WS-MetadataExchange assigns a particular Action URI to this request, following the WS-Addressing model, in which the individual messages of an operation are assigned specific Action URIs.
The response that the service endpoint sends in response to a GetMetadataRequest can also take several forms to allow efficient communication of metadata and support scalability.
The information that is returned in a GetMetadata response is included within a “Metadata” element. The children of this element are a variable number of “metadata sections” as “MetadataSection” elements, each of them containing information about one metadata definition or set of related definitions (or “unit”) of the same dialect and describing a particular aspect of the endpoint behavior. Each metadata section includes a “Dialect” attribute to indicate the type of metadata it contains. Multiple metadata sections of the same dialect are possible. An optional “Identifier” attribute on the MetadataSection element can identify the definition or set of definitions returned. This is typically the case when the original request contains a metadata identifier, and a matching metadata definition is returned. The identifier can be used in any GetMetadata response, however. Just as many metadata sections can contain the same Dialect attribute, multiple sections can be returned with the same identifier, such as when multiple XML Schema definitions within the same target namespace are returned. (The specification explicitly encourages multiple metadata sections in this case.)
Three kinds of metadata sections are possible: embedded metadata, metadata references, and metadata locations.
With embedded metadata, the actual metadata appears embedded directly inside the metadata section. The contents of the metadata section belong in this case to the specific XML dialect that the corresponding attribute identifies.
With metadata reference, a “MetadataReference” element of endpoint reference type encodes the endpoint reference where the actual metadata can be retrieved using a WS-MetadataExhange “Get” call.
Finally, with metadata location, a single “Location” element appears inside the metadata section. It contains a URL from which to retrieve the corresponding metadata using the common retrieval mechanism for the corresponding URL scheme. For example, the retrieval mechanism for an HTTP URL is an HTTP GET request.
Metadata references and locations allow service endpoints to control the amount of data returned with a GetMetadata response message. This is particularly important when an unqualified (or generic) GetMetadata request is received, potentially resulting in a large amount of actual metadata. Instead of sending back all that information, the responding endpoint can provide specific endpoints or URLs so that the original requester can retrieve individual units of metadata as it becomes necessary. Therefore, WS-MetadataExchange provides two mechanisms for controlling the amount of information returned with a GetMetadata request. First, requesters can limit the scope of the request using the dialect and identifier parameters. Second, service endpoints can use the indirection mechanisms of metadata references and location URLs to achieve a similar result.
Indirection serves a second purpose: It allows service endpoints to offload the metadata retrieval function to specialized service endpoints or applications, while maintaining the principle of making the endpoint the primary contact point for requesters who are looking for service metadata.
The structure of a GetMetadata response is summarized in the pseudo-grammar that follows.
<wsx:Metadata ...>
[<wsx:MetadataSection Dialect='xs:anyURI'
[Identifier='xs:anyURI']? >
[<dialectSpecificElementName>
...
</dialectSpecificElementName>+
|
<wsx:MetadataReference ...>
endpoint-reference
</wsx:MetadataReference>
|
<wsx:Location>xs:anyURI</wsx:Location>
]
</wsx:MetadataSection>]*
</wsx:Metadata>
Metadata reference endpoints are required to support a single operation with the only purpose of returning a specific set of metadata definitions. The WS-MetadataExchange “Get” operation takes no parameter data and returns the actual metadata indicated by the metadata section that contained the reference. The metadata reference is a dedicated endpoint whose function (from the point of view of the service requester) is limited to returning one unit of metadata when it receives a Get request.
Now you can put together the message exchanges that were just described in a set of related exchanges. The exchange begins with a “GetMetadata” request from a requester application, soliciting WS-Policy metadata; the request message contains the following data:
<wsx:GetMetadata>
<wsx:Dialect>
http://schemas.xmlsoap.org/ws/2002/12/policy
</wsx:Dialect>
</wsx:GetMetadata>
The response contains a list of metadata sections with metadata references of where to retrieve the actual policies:
<wsx:Metadata>
<wsx:MetadataSection Dialect=
"http://schemas.xmlsoap.org/ws/2002/12/policy"
Identifier=
"http://example.com/endpoint-policies/p-sec">
<wsa:Address>
http://example.com/endpoint-policies-eprs-get/p-sec
<wsa:Address>
</wsx:MetadataSection>
<wsx:MetadataSection>
<wsx:MetadataSection>
...
</wsx:Metadata>
A Get request that is directed to the endpoint contained in the first metadata section contains an empty Get message (together with the appropriate Action header):
<wsx:Get/>
The returned message from this operation contains the actual policy being sought, for example:
<wsp:Policy>
<wsp:ExactlyOne>
<wsse:SecurityToken>
<wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType>
</wsse:SecurityToken>
<wsse:SecurityToken>
<wsse:TokenType>wsse:X509v3</wsse:TokenType>
</wsse:SecurityToken>
</wsp:ExactlyOne>
</wsp:Policy>
The idea behind the dynamic retrieval of metadata from a service endpoint assumes that little or no information is known about the service endpoint prior to the metadata exchange interaction. This, of course, is not necessarily the common case, but it is certainly an important one to support. In particular, the specific protocol binding to access the endpoint might be unknown at the time the bootstrapping process is to begin. It is recommended that endpoints complying with WS-MetadataExchange support a default SOAP over HTTP protocol binding; other protocols can be supported as long as that fact is explicitly represented in the endpoint description metadata. In the absence of a statement indicating an alternative protocol, the default protocol is assumed to apply.
Note, however, that WS-MetadataExchange does not solve the problem of how to communicate to a requester an alternative binding in the bootstrap process. The solution to this problem will likely involve other specifications.
WS-MetadataExchange is a public specification offered under royalty-free terms. It likely will be submitted to a standards organization to undergo formal standardization. It’s difficult to predict the outcome of that process, but some of the limitations of the current specification should be eliminated. Following are three of the changes that you might expect as this process proceeds forward.
Support for multidialect and multi-identifier requests—. The current specification allows you to request all the metadata for an endpoint or to restrict it to a single dialect or identifier. This seems like an unnecessary limitation. Allowing you to request metadata from multiple dialects would provide additional control for requesters over the returned metadata.
Multiprotocol access—. Currently, there is no mechanism to bootstrap metadata exchange interactions in the most generic case unless the default protocol binding is assumed to apply. In many situations, other protocols need to be used, however. Dealing with this limitation would likely require WS-Addressing support.
Mechanisms for identifying support for WS-MetadataExchange in WSDL service descriptions—. It’s assumed that service endpoints support WS-MetadataExchange in addition to their business interfaces. This fact needs to be clearly specified in the WSDL description of the service; a mechanism to do so will need to be defined. (Although adding a port to the service definition is straightforward, it’s probably not the most convenient approach from the usability perspective.)
Explicit service description information (metadata) is a central aspect of SOAs and the Web services framework. Explicit metadata is the key to effective decoupling between service applications. Several mechanisms allow communicating metadata between service providers and requesters. Centralized registries such as UDDI rely on a third party to aggregate information about services and enable both discovery of services and retrieval of service descriptions. WS-MetadataExchange defines a WSDL interface so that service requesters can retrieve metadata directly from the service provider. This model does not support service discovery, but it’s advantageous because a third-party infrastructure is not required for requesters to retrieve full information about a service provider. WS-MetadataExchange enables dynamic configuration at the requester side and allows providers to dynamically customize their policies based on the identity of the requester or specific conditions under which the interaction takes place. For this reason, WS-Metadata is a key piece for bootstrapping service interactions. Finally, the WS-MetadataExchange interface can accommodate additional metadata types beyond the ones commonly considered today (XML Schema, WSDL, and WS-Policy), such as semantic service descriptions.