WCF programming series (5) Metadata

In example 1, The scvutil command is used to automatically generate the client proxy class of the Service:

Svcutil http: /localhost: 8000 /? WSDL/O: firstserviceclient. CS

Http: // localhost: 8000 /? The WSDL connection returns an XML, Which is metadata used to describe how to interact with the service endpoint. Because metadata exists, the svcutil command can automatically generate the client proxy class.

Metadata complies with the Web Service Description Language (WSDL) standards, so it can be supported by multiple languages. In addition to the svcutil of WCF, Java programmers can also use tools such as wsdl2java to generate Java client proxy classes.

The WCF Service exposes its own metadata in two ways: one is to provide metadata based on the HTTP-GET protocol, and the other is to use a dedicated endpoint approach.

 

The following describes how to publish service metadata through configuration files.

Publish metadata as a HTTP-GET:

We have used this method in the preceding example.

1. In the host project configuration file, set the value of behaviorconfiguration to behaviorconfiguration in the <service> Configuration node.

2. Add a <behavior> node with the name attribute behaviorconfiguration under <behaviors> <servicebehaviors>.

3. Add the subnode <servicemetadata> under <behavior> to set the httpgetenabled property to true, enabling HTTP-GET metadata with this property

4. Metadata exposed in HTTP-GET mode can be obtained through the service address plus the WSDL parameter form: such as http: // localhost: 8000 /? WSDL

Hide row number copy code? App. config

1. <?xml version="1.0" encoding="utf-8" ?>

2. <configuration>

3.   <system.serviceModel>

4.     <services>

5.       <service name="Xfrog.Study.WCF.FirstService" behaviorConfiguration="behaviorConfiguration">

6.         ......

7.       </service>

8.     </services>

9.     <behaviors>

10.       <serviceBehaviors>

11.         <behavior name="behaviorConfiguration">

12.           <serviceMetadata httpGetEnabled="true"/>

13.         </behavior>

14.       </serviceBehaviors>

15.     </behaviors>

16.   </system.serviceModel>

17. </configuration>

Publish service metadata by endpoint

In this solution, the Service metadata is also a service endpoint. Its form is exactly the same as that of the service endpoint, except that the binding and contract in the endpoint are specific to metadata ,.

There are four methods to bind metadata, which correspond to different access protocols:

Mexhttpbinding corresponding to HTTP

Mexhttpsbinding corresponding to the HTTPS protocol

Namedpipebinding corresponding to the named pipe Protocol

Mextcpbinding corresponding to the TCP protocol

In the configuration file, the endpoint definition method of meta data is exactly the same as that of our service endpoint, which is defined by the <endpoint> node. The address attribute specifies the metadata address, you can also use the absolute address and relative address. The binding attribute specifies the binding type of metadata, that is, one of the preceding four binding types. The contract attribute specifies the contract type, and the metadata contract type is fixed to imetadataexchange.

The following configuration file adds a metadata address for the example. The metadata uses the HTTP protocol and the access path is http: // localhost: 8000/MEX.

Hide row number copy code? App. config

1. <?xml version="1.0" encoding="utf-8" ?>

2. <configuration>

3.   <system.serviceModel>

4.     <services>

5.       <service name="Xfrog.Study.WCF.FirstService" behaviorConfiguration="behaviorConfiguration">

6.         ......

7.         <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"></endpoint>

8.       </service>

9.     </services>

10.     <behaviors>

11.       <serviceBehaviors>

12.         <behavior name="behaviorConfiguration">

13.           <serviceMetadata httpGetEnabled="true"/>

14.         </behavior>

15.       </serviceBehaviors>

16.     </behaviors>

17.   </system.serviceModel>

18. </configuration>

Note: Metadata published as an endpoint cannot be viewed in a browser.

Use svcutil to download service metadata

Use the metadata URL to download metadata:

In WCF, metadata does not need to be directly operated. However, the svctuil tool provides a metadata download tool that allows you to download service metadata by specifying the/T: Metadata parameter and metadata URL, to download the metadata specified by the endpoint, run the following command:

Svcutil/T: Metadata http: // localhost: 8000/MEX

Of course, before running this command, you need to start our service first. After the command is run, three files are generated in the current directory:

Tempuri.org. WSDL service WSDL Description document

Tempuri.org. XML schema definition document for the XSD Service

Schemas.microsoft.com. 2003.10.serialization.xsd contains a set of XML Schema definitions of. Net basic types.

The last two XSD documents are referenced in the WSDL (XSD: Import). Using these two XML schema definition files, the metadata import tool can verify that the WSDL metadata complies with the WSDL standard.

Use a service assembly to download metadata:

If the service class is compiled using WCF, svcutil can directly use the service assembly (Note: it is not the host Assembly) to generate the metadata document, and the service does not need to publish its own metadata. The command is as follows:

SvcutilXfrogwcfservice. dll-- Note: during the test, switch the current path to the directory where xfrogwcfservice. dll is located.

As with the metadata URL method, three documents are generated in the same way.

 

Generate a client proxy class using the downloaded metadata

Using the metadata document downloaded by svcutil, we can use the svcutil command to generate the client proxy class of the service without using the metadata URL of the service. Assume that the preceding three metadata files exist in the current directory, the command is as follows:

Svcutil tempuri.org. */O: firstserviceclient. CS/config: App. config

After the command is successfully executed, the client's proxy code file and configuration file are generated in the current directory.

 

Security

After exposing the metadata of a service, our server may be attacked. Of course, you can use the endpoint bound to the HTTPS secure connection to protect your metadata endpoint, however, if your client is also implemented using WCF, the server does not need to disclose metadata, and the client uses offline metadata documents to generate proxy classes.