First WCF6,

First WCF6,

Reference: http://blog.csdn.net/songyefei/article/details/7397296

Metadata Exchange

Through the first two articles, we learned some basic principles of WCF communication. We know that the WCF server and client share metadata (including service agreement and server endpoint information) establish a channel on two endpoints for communication. We write metadata information for the server by writing code (or configuration), without metadata exchange. However, in actual applications, there are often a lot of metadata, and it is not worthwhile to write the metadata repeatedly. Therefore, the metadata exchange method must be used for the client to obtain the metadata, in this article, we will take a closer look at metadata and metadata exchange.

1. How metadata is provided

We know that metadata includes all the information to communicate with the server, including the service agreement interface, server end point address, binding, and other information, it points out all the clues about where the client should find the service and how to call the service. But how does the server publish its metadata?
The answer is to use the WSDL file, which is the Web Service Description Language. It is an XML file that describes the Web Service according to certain standards, it complies with W3C standards, because WCF is designed as a service framework for different platforms to call, so the client may be non-Microsoft platform, such as Java. Therefore, WCF must use the description method of WSDL, an international standard, to describe the service to be accessed by many platforms.

 

2. What is the metadata exchange process?

When running on the WCF server, a group of class libraries are ready to output the service metadata as the WSDL description to the requester. As long as a client requests the metadata according to the methods agreed by the server, the server immediately writes the service running status as a WSDL file. The client actually obtains the WSDL file (and some framework description file XSD). The client obtains the file and then interprets the WSDL using its own method, translate it into available source code or configuration files on the client. Then the client gets the programming model of the service. Through some proxy classes, the client can even use the WCF Service like calling a local object.

 

Therefore, the entire process is as follows: the client requests metadata exchange from the server --> write the metadata into a wsdl file during the server running --> the client obtains the file --> the client translates the file --> the client generates local class code and configuration based on the Translation results --> the client obtains the local programming model of the service. This is the process of metadata exchange.

3. Get the WSDL

On the micro-soft platform, there are two types of metadata exchange, the first is to use service introduction, and the second is to use the metadata tool (svcutil.exe). Let's first learn this tool.

This tool can be found in the Windows SDK at C: \ Program Files \ Microsoft SDKs \ Windows \ v6.0 \ Bin. If you have VS2010, you can start the command line tool of VS2010, in this way, you can use this program in any directory.

Let's take a look at an example first, that is, the IIS service HelloWCFService we created in the previous articles. It is hosted in IIS by me.

The source code is as follows (HelloWCF. cs ):

using System;  using System.ServiceModel;    namespace LearnWCF  {      [ServiceContract]      public interface IHelloWCF      {          [OperationContract]          string HelloWCF();      }        public class HelloWCFService : IHelloWCF      {          public string HelloWCF()          {              return "Hello WCF!";          }      }  } 

The configuration file (web. config) is as follows:

    <configuration>        <system.serviceModel>          <services>            <service name="LearnWCF.HelloWCFService" behaviorConfiguration="metadataExchange">              <endpoint address="" binding="wsHttpBinding" contract="LearnWCF.IHelloWCF"/>              <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>            </service>          </services>          <behaviors>            <serviceBehaviors>              <behavior name="metadataExchange">                <serviceMetadata httpGetEnabled="true"/>              </behavior>            </serviceBehaviors>          </behaviors>        </system.serviceModel>      </configuration>  

Enter the service address in the browser, as shown in:

Did you see the command line prompted by the system? When the system is running, we use svcutil.exe to obtain metadata. Let's try it now. First open the VS2010 command line:

Start --> all programs --> Visual Studio 2010 --> Visual Studio Tools --> Visual Studio command line prompt

 

 

 

We navigate to a directory to prepare the metadata file.

We do not follow the method provided by the browser for the moment, because the method is used to combine the obtained WSDL and the translated WSDL into the client code. First, we obtain the WSDL metadata file, let's see what it looks like. Run the following command:

Svcutil.exe/t: metadata http: // localhost/iisservice/hellowcfservice. svc? Wsdl

We added a parameter/t: metadata to output only metadata without generating code. The command execution process is as follows:

Three files are generated, including two schema files and one WSDL file. These are the descriptions of the server metadata. All client requests are actually the files. WSDL has many specifications. We will look at its content in the future. However, we can see some aspects related to service agreements, bindings, and operations.

4. Translate the WSDL File

WSDL is an XML file, which is actually a text file. The client must use it to translate the cost code file according to its own platform features. Of course, svcutil provides this function. Use the following command in the directory where the wsdl file is located to translate the code file to the local cost:

Svcutil *. wsdl *. xsd

As the name implies, the client code file is generated based on all the WSDL files and XSD files in the current directory. The process will be like this

We can see that a cs file and a configuration file are generated, which are the client code files translated from the WSDL file. Let's take a look at it. It's no stranger to use ClientBase <> to generate a client proxy class and configure the endpoint information in the. config file. Include these two files in the client project and change output. config to app. config.

4. Better use of metadata exchange tools

Previously, we understood the process of using svcuitl.exe to obtain the WSDL and translate it into client code. In fact, these two steps can be combined into one. Directly execute the following command to directly obtain the client file:

Svcutil.exe http: // localhost/iisservice/hellowcfservice. svc? Wsdl

In this way, the client file is directly generated without generating the WSDL.

However, the file generated in this way may not meet our requirements. We can add some parameters to specify the output file name:

Svctuil.exe/out: ClientProxy. cs/config: app. config http: // localhost/iisservice/hellowcfservice. svc? Wsdl

In this way, the output file can be directly included in the client project.

5. Use Service reference

The volume is refreshing, but it is integrated with VS2010 and easy to use. When the service changes, you only need to right-click the service reference and select Update Service to download the WSDL again.

 

6. Expand a bit

 

As a server, you need to configure public metadata. Different configurations may lead to different methods for publishing metadata.

 

Remember that the open metadata of the WCF server must meet two conditions:

 

(1) Add ServiceMetadata behavior to the service.

 

(2) Enable the metadata exchange endpoint.

 

Both are indispensable.

 

There are two main methods to publish metadata in WCF:

 

First, use the http get method.

 

This is the method we have seen in the previous article. We can use the HTTP Get method to obtain the WSDL file that follows the service address. svc? The wsdl method directly requests to the WSDL file. We can directly enter the server address in the browser. svc? The browser directly obtains the wsdl file and displays it for us.

 

There are also corresponding framework Description files (XSD)

 

To use this metadata exposure method, you must configure ServiceMetadata behavior of the service and specify httpGetEnabled = "true". The metadata disclosure endpoint does not need to be configured, and the system will automatically configure one, the configuration file is written as follows:

    <configuration>        <system.serviceModel>          <services>            <service name="LearnWCF.HelloWCFService" behaviorConfiguration="metadataExchange">              <endpoint address="" binding="wsHttpBinding" contract="LearnWCF.IHelloWCF"/>            </service>          </services>          <behaviors>            <serviceBehaviors>              <behavior name="metadataExchange">                <serviceMetadata httpGetEnabled="true"/>              </behavior>            </serviceBehaviors>          </behaviors>        </system.serviceModel>      </configuration>  

In this configuration, the method for accessing metadata is to access the following address:

Http: // localhost/iisservice/hellowcfService. svc? Wsdl

Second: Exchange endpoints through MEX metadata.

In this way, we must first ensure that the service has ServiceMetadata behavior, but httpGetEnabled does not have to be true. In addition, we also need to explicitly add an endpoint for the service. The endpoint address, binding, and agreement are all specified and cannot be changed.

<Endpoint address = "mex" binding = "mexHttpBinding" contract = "IMetadataExchange"/>

The configuration file is written as follows:

    <configuration>        <system.serviceModel>          <services>            <service name="LearnWCF.HelloWCFService" behaviorConfiguration="metadataExchange">              <endpoint address="" binding="wsHttpBinding" contract="LearnWCF.IHelloWCF"/>              <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>            </service>          </services>          <behaviors>            <serviceBehaviors>              <behavior name="metadataExchange">                <serviceMetadata />              </behavior>            </serviceBehaviors>          </behaviors>        </system.serviceModel>      </configuration>  

If you follow this configuration, you must access the public metadata at the following address:

Http: // localhost/iisservice/hellowcfservice. svc/mex

Note: Because HTTP getis not enabled, we cannot directly input this address in the browser to get wsdl(it will prompt a error. We can access it through svcutil.exe or adding service references.

When svcutil.exe or service reference is used, you can ignore whether the metadata is exposed in http get or Mex mode. They will automatically find the appropriate method. You only need to enter the svc file address of the service, however, we should know that there is a difference between the two methods of metadata disclosure.

6. Summary

Today, we have learned more about the principles of metadata exchange and metadata exchange. Although we should use metadata exchange tools in actual projects to help improve efficiency, we should master all the steps behind this.

Related Resources

Msdndocumentation on svcutil.exe usage

Http://msdn.microsoft.com/zh-cn/library/aa347733.aspx