WCF Technical Analysis 25: The metadata (Metadata) Architecture panorama Presentation [WS Standard Article]

Metadata is actually a description of the service endpoint, consisting of the address, binding (Binding), and contract (CONTRACT) classic ABC three elements. Readers who have read the WCF Technical Analysis (Volume 1) have a profound understanding of the nature of these three elements: the address determines the location of the service and implements the corresponding addressing mechanism; The contract describes the message Exchange Mode (Messages Exchange pattern: MEP) and the structure of the message (Schema), binding creates a channel stack to encode, transmit, and process messages based on certain special features such as transaction implementation, reliable transmission, and message based security.

The consumer of the service can secure the request by acquiring the metadata published by the server and rebuilding the endpoint on this basis: The message is sent to the exact destination address, the message Exchange Mode expected by the service side is used, and the message structure that the server can recognize is generated. Using a matching message encoding method to ensure that the server can decode the received message properly, use a consistent transport protocol to achieve the normal transmission of the message, and service-side consistency with the message to ensure the implementation of protocols such as transaction, reliable transmission, and message security.

WCF is a distributed communication platform based on SOA, and an important feature of SOA is the implementation of Cross-platform interoperability. Metadata is to ensure that service consumers normally invoke the target service (which may be deployed on heterogeneous platforms), so the metadata itself needs to be represented by an open standard. Currently, the metadata has three more typical representations:

XSD: An XML structure that describes the data types that compose a message, in the form of an XML schema;

WSDL: A comprehensive description of the service through a complete Web service Description language document, including abstract functionality, including specific details;

Ws-policy policy: Describes service capabilities and features through the Ws-policy specification in the form of assertions (assertion).

The implementation of Cross-platform interoperability requires that the metadata of the hosting service description information not only be represented by an open standard or specification, but even that metadata exchange (Metadata Exchange:mex) is also carried out in accordance with the specifications of the manufacturer. In the ws-* specification system, Ws-metadata Exchange (WS-MEX) is a standardized specification for the exchange of meta data. The Ws-metadataexchange (hereinafter referred to as Ws-mex) regulates how to represent a Ws-transfer resource with endpoints (here is a generalized Web service endpoint, unrelated to specific technology). and is embedded in the Ws-addressing endpoint reference (Endpoint Reference) and how the metadata is fetched by the corresponding Web service endpoint. In short, Ws-mex is a WS specification for how metadata is exchanged. Ws-mex, together with other ws-* specifications, such as WSDL, ws-addressing, Ws-transfer, and ws-policy, together form a complete normative system for describing Web service metadata and metadata exchange, before formally introducing Ws-mex First of all, I would like to know some other auxiliary ws-* specifications.

First, Ws-policy

A Web service (a broad, technical platform-independent web service) in addition to implementing the business functions defined through the service contract, in order to achieve some additional functionality (such as security, transaction, and reliable transport), You also need to have some business-independent behaviors (Behavior) and capabilities (Capability) that we can collectively refer to as Web Service policies (Policy). Ws-policy provides an xml-based framework model and syntax for describing the capabilities, requirements, and behavioral attributes of Web services.

Ws-policy belongs to a fundamental specification in the ws-* system, and the specification itself is not used alone, but rather serves other WS specifications (which we generally call domain specific specifications, such as Ws-transaction, ws-reliable Messaging and ws-security, etc.) provide a unified policy description.

In 2006 and 2007, the consortium launched two versions of the Ws-policy specification, namely Ws-policy 1.2 and Ws-policy 1.5. Here, we are simply looking at the latest Ws-policy version (1.5) to briefly describe how a complete WS policy is structured, and for readers who want to get to know ws-policy, you can download the official document from the following address: http:// www.w3.org/TR/ws-policy/.

Ws-policy uses an xml-based policy expression (Policy Expression) to represent a policy, and before putting into a description of a specific policy definition, let's take a look at the definition of a typical policy expression. The following XML fragment represents a policy expression derived from ws-security, a WS specification based on how message security is implemented. It embodies the meaning of whether the subject part of the message is signed or encrypted.

   1: (<wsp:policy)
   2:         xmlns:sp= "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
   3:         xmlns:wsp= "Http://www.w3.org/ns/ws-policy" >
   4: (<wsp:ExactlyOne>)   
   5: (<wsp:All>)     
   6: (<sp:SignedParts>)        
   7: (<sp:Body/>)           
   8: (</sp:SignedParts>)        
   9: (modified)     </wsp:All>
  (a)     <wsp:All>
  One: (a)        <sp:EncryptedParts>
  (a)           <sp:Body/>
  (one)        </sp:EncryptedParts>
  (a)     </wsp:All>
  (   </wsp:ExactlyOne>)
  (</wsp:Policy>)

The XML above is in a standard form (Ws-policy also defines a shorthand policy representation) to define a policy, and then we'll explain the structure of a complete policy expression on this basis.

In a web-based service based system, the strategy embodies representations of behavioral attributes such as Web service-related entity requirements (Requirements), capabilities (capabilities), and attributes (characteristics). The ws-policy represents these single behavioral attributes in the form of assertions (assertion), and then uses certain rules to combine the relevant policy assertions organically to achieve a complete description of the entire Web service target entity.

According to Ws-policy 1.5, all policy elements are defined under the Http://www.w3.org/ns/ws-policy namespace, and a full policy is described by an xml-based policy expression. 1,

1. Policy expression (Policy Expression)

A policy expression is an XML information set (XML Infoset) that describes a complete policy. A policy expression has two different representations: the standard form (normal forms) and the shorthand form (the Compact form). A policy expression is a collection of policy-selection items (Policy alternative). We require that a policy be met, meaning that we need to meet at least one policy selection for that collection.