Section 9.1. Architectural Concepts


9.1. Architectural Concepts

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.

9.1.1. Extensibility of Metadata Dialects

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.

Dialects and Identifiers

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.

9.1.2. Use of Indirection: Metadata References and Locations

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.

9.1.3. Metadata Request Operations

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.

GetMetadata Requests

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 elementsone 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.

GetMetadata Responses

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> 

Get Request

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.

Metadata Exchange Example

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> 

9.1.4. Default Protocol Binding

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.



    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[.  .. ] More
    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More
    ISBN: N/A
    EAN: N/A
    Year: 2005
    Pages: 176

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net