WS-MetadataExchange language basics


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:

  • GetMetadata
  • Get

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. GetMetadata/Request uuid:23492372938

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> 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. Identifier> 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. mex/GetMetadata/Response 23492372938

Metadata> MetadataSection ...> ... the entire WSDL definition ... MetadataSection> MetadataSection ...> MetadataReference> 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. 23492372938



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


Case Studies

Part I: SOA and Web Services Fundamentals

Introducing SOA

The Evolution of SOA

Web Services and Primitive SOA

Part II: SOA and WS-* Extensions

Web Services and Contemporary SOA (Part I: Activity Management and Composition)

Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)

Part III: SOA and Service-Orientation

Principles of Service-Orientation

Service Layers

Part IV: Building SOA (Planning and Analysis)

SOA Delivery Strategies

Service-Oriented Analysis (Part I: Introduction)

Service-Oriented Analysis (Part II: Service Modeling)

Part V: Building SOA (Technology and Design)

Service-Oriented Design (Part I: Introduction)

Service-Oriented Design (Part II: SOA Composition Guidelines)

Service-Oriented Design (Part III: Service Design)

Service-Oriented Design (Part IV: Business Process Design)

Fundamental WS-* Extensions

SOA Platforms

Appendix A. Case Studies: Conclusion

Service-Oriented Architecture. Concepts, Technology, and Design
Service-Oriented Architecture (SOA): Concepts, Technology, and Design
ISBN: 0131858580
EAN: 2147483647
Year: 2004
Pages: 150
Authors: Thomas Erl © 2008-2020.
If you may any questions please contact us: