WS-MetadataExchange language basics

Note

Only element descriptions are provided in this section. Concepts relating to WS-MetadataExchange are covered in Chapter 7.

WS-MetadataExchange provides a standardized means by which service description documents can be requested and supplied. This specification establishes a set of features that supports important SOA characteristics, such as interoperability and quality of service (Figure 17.4).

Figure 17.4. How WS-MetadataExchange relates to the other WS-* specifications discussed in this chapter.

The scope of the WS-MetadataExchange language is fairly small in comparison to other WS-* specifications. As we established in Chapter 7, the following two forms of metadata requests are standardized:

The descriptions that follow discuss the primary elements used to compose these two types of request messages.

17.4.1. The GetMetadata element

This element can be placed on its own in the Body area of a SOAP message, or it can be turned into a construct that hosts child Dialect and Identifier elements (explained next).

Case Study

In the scenario described as part of the case study example at the end of the Metadata exchange section in Chapter 7, RailCo designed its Invoice Processing Service to perform a periodic metadata check against TLS's Accounts Payable Service.

Here is a sample of RailCo's first cut of the GetMetadata request message.

Example 17.14. A SOAP request message containing the GetMetadata element in the Body construct. Note the use of the WS-Addressing message information header elements in the SOAP header.

http://schemas.xmlsoap.org/ws/2004/09/mex/ GetMetadata/Request http://www.xmltc.com/tls/ap1/ uuid:23492372938 http://www.xmltc.com/railco/inv1/

GetMetadata/> ...

 

17.4.2. The Dialect element

This element specifies the type and version of the metadata specification requested. The use of the Dialect element guarantees that the metadata returned to the service requesting it will be understood.

Dialect> http://www.w3.org/2001/XMLSchema Dialect>

 

Case Study

RailCo refines its original GetMetadata request message by adding a Dialect construct to specify that an XSD schema conforming to the 2001 specification is required, as shown here:

Example 17.15. The Dialect element being used to indicate that the XSD schema requested should comply to version 1.0 of the XML Schema Definition Language.

 

 

17.4.3. The Identifier element

While the Dialect element specifies the type of metadata being requested, this element further narrows the criteria by asking for a specific part of the metadata.

http://www.w3.org/2001/XMLSchema Identifier> http://www.www.xmltc.com/tls/schemas/ap1/schemas Identifier>

 

Case Study

Finally, RailCo adds the Identifier construct to pinpoint exactly which XSD schema it wants TLS to return.

Example 17.16. The Identifier element added to specify the XSD schema's target namespace.

 

 

17.4.4. The Metadata, MetadataSection, and MetadataReference elements

These three elements are used to organize the content of the message sent in response to a GetMetadata request. The parent Metadata construct resides in the SOAP message Body area and houses one or more child MetadataSection constructs that each represent a part of the returned metadata.

If the contents of the metadata document are returned, they are placed within the MetadataSection construct. However, if only a pointer to the document is returned, its location is found in the MetadataReference construct (further qualified by a regular WS-Addressing Address element).

Case Study

TLS responds to RailCo's GetMetadata request with the following message containing the entire WSDL definition of the Accounts Payable Service, along with a pointer to the associated XSD schema.

Example 17.17. A GetMetadata response message returning the contents of an entire WSDL definition, along with a pointer to the associated XSD schema.

http://schemas.xmlsoap.org/ws/2004/09/ mex/GetMetadata/Response 23492372938 http://www.xmltc.com/railco/inv1

Metadata> MetadataSection ...> ... the entire WSDL definition ... MetadataSection> MetadataSection ...> MetadataReference> http://www.www.xmltc.com/tls/ap1/schemas MetadataReference> MetadataSection> Metadata>

 

Note that the MetadataSection element can contain Dialect and Identifier attributes that correspond to the Dialect and Identifier elements explained previously.

17.4.5. The Get message

As previously mentioned, the response to a GetMetadata request message can include a MetadataReference construct that contains the location of metadata documents not returned in this initial message. To explicitly request one of these documents, a separate Get message is issued.

While this message does not contain a specific Get element, it does adhere to a standardized SOAP header format, as follows.

Case Study

RailCo wants to take no chances and therefore designs its Invoice Processing Service to always request full copies of supplementary service description documents. Below is the Get message issued by RailCo, requesting the XSD schema identified in TLS's previous GetMessage response message.

Example 17.18. A Get message SOAP header identified by the Action element value. The resource being requested is targeted in the To element.

 

http://schemas.xmlsoap.org/ws/2004/09/mex/Get/Request 23492372938 http://www.xmltc.com/railco/sub1 http://www.www.xmltc.com/tls/schemas/not1

 

SUMMARY OF KEY POINTS
  • WS-GetMetadata provides the GetMetadata construct that houses the contents of the message used to request metadata from a service provider.

  • The Dialect and Identifier elements can be applied to further narrow request criteria.

  • The response to a GetMetadata request message organizes the retrieved metadata information using the Metadata and MetadataSection constructs.

Related

Категории