[Honestly learn WCF] Sixth chapter metadata Exchange

Original: [Honestly learn WCF] The sixth chapter metadata Exchange

Learn WCF Honestly

The sixth chapter of meta-data exchange

With the first two studies, we learned about some of the fundamentals of WCF communication, and we know that WCF servers and clients communicate by establishing channels on two endpoints through shared metadata, including service contracts, server endpoint information. We write metadata information for the service side through handwritten code (or configuration), which communicates without the help of meta-data exchange. However, in practical applications, metadata is often a lot of, and the duplication of the work of writing metadata is not worth it, so it is bound to use the way metadata exchange for the client to obtain metadata, this article we will learn more about meta-data and metadata exchange.

1. How meta data is provided

We know that the metadata includes all the information to communicate with the server, including the service contract interface, the server endpoint address, the binding, and so on, which indicates where the client should go to find the service and how to invoke the service. But how does the server publish its metadata?

The answer is to use a WSDL file, the WSDL is the Web service Description language,web Service Description Language, it is an XML file, in this file according to a certain standard to describe the Web Service, he is a standard, Because WCF is a service framework that is designed to be invoked on different platforms, the client may be a non-Microsoft platform, such as Java or something. Therefore, WCF must use a descriptive method of the international standard WSDL to describe the service to be accessed by a multitude of platforms.

2. What is the process of meta-data exchange?

At runtime of the WCF server, there is a set of class libraries ready to export the service's metadata to the requestor, as long as a client requests metadata in accordance with the service-side contract, and the server immediately writes the service run-time state as a WSDL file. The client gets the WSDL file (and some framework description file XSD), the client gets the file and then uses its own method to interpret the WSDL, translates it into the client's available source code or configuration file, then the client gets the service programming model, through some proxy classes, Clients can even use WCF services just like local objects.

So the whole process is this: the client requests metadata Exchange to the server--the server runs the metadata as a WSDL file--The client obtains the file--the client translates the file--and 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

In the Microsoft platform, there are two ways to do metadata exchange, the first is to use the service reference, the second is to use the metadata utility (svcutil.exe) to do, we first learn the tool.

This tool can be found in the Windows SDK, the specific location is C:\Program Files\Microsoft Sdks\windows\v6.0\bin, if you have VS2010, you can start the VS2010 command line tool, This allows you to use this program in any directory.

Let's start with an example of the IIS service Hellowcfservice we built in the previous few, which I hosted in IIS.

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 line of command that prompted the system? The system is telling us how to use the svcutil.exe to get the meta data. 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

The window for the command-line tool is this:

We navigate to a directory where we are ready to get the meta-data file.

For the time being, we do not follow the method that the browser provides us, because by doing that, we get the WSDL and translation WSDL together for the client code, we first get the WSDL metadata file and see what it looks like. We do the following instructions:

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

We have added a parameter/t:metadata means that only the metadata is output and no code is generated. The execution of the command is as follows:

You can see that 3 files are generated, including two schema files and a WSDL file, which is the description of the service-side metadata, and all of the clients are actually requesting this file. WSDL specification is more, about its content, we will start again in the future, but simply open a look to see some of the service contract, binding, manipulating these things related to the place.

4. Translating WSDL Files

WSDL is an XML file, which is actually a text file that the client must translate into a local code file to use according to its own platform features. Svcutil will certainly provide this functionality. The WSDL file can be translated into a local code file using the following command in the same directory as the WSDL file:

svcutil *.wsdl *.xsd

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

As you can see, a CS file and a configuration file are generated, and these are the client-side code files that are translated according to the WSDL file. Open to see, must not be unfamiliar, is to use clientbase<> to generate a client proxy class and the endpoint information is configured in the. config file. Include these two files in the client's project and change the output.config to App. Config.

4. Better use of meta-data exchange tools

Previously we learned about the process of using Svcuitl.exe to get the WSDL and translate it into client-side code. In fact, these two steps can be merged. Directly execute the following command to get the client file directly:

SvcUtil.exe http://localhost/iisservice/hellowcfservice.svc?wsdl

This way it does not generate WSDL and directly generates the client file.

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

Svctuil.exe/out:clientproxy.cs/config:app.config http://localhost/iisservice/hellowcfservice.svc?wsdl

So the output of the file we can directly include in the client project to use.

5. Using Service references

In fact, using a service reference is the same as the client model generated using svcutil.exe, but the service reference retains the WSDL file (and some related 7788 files). No svcutil.exe comes so refreshing, but it integrates with VS2010, it's simple to use, and when the service changes, you just need to right-click the service reference to select Update Service to re-download the WSDL.

6. Expand a Little

As a server, exposing metadata is required to be configured, and different configurations can cause metadata to be exposed in different ways.

We have to remember that the WCF server must have two conditions for the public Kaiyuan data:

(1) Add servicemetadata behavior for the service.

(2) Open the metadata Exchange endpoint.

Both are indispensable.

There are two main ways in which WCF exposes metadata:

The first: By means of the HTTP GET method.

This is the method we see in the previous article, where we can use the HTTP GET method to get the WSDL file as the service address. The SVC follows the WSDL method directly to the WSDL file. We can enter the server address directly in the browser. SVC?WSDL, the browser directly obtains the WSDL file and shows it to us.

There is also a corresponding framework description file (XSD)

If you want to use this metadata disclosure method, you must configure the service's servicemetadata behavior and specify httpgetenabled = "true", while the metadata disclosure endpoint does not have to be configured, the system automatically configures one, and 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 way to access the metadata is to access the following address:

http://localhost/iisservice/hellowcfService.svc?wsdl

The second type: The endpoint is exchanged through the Mex meta data.

In this way, we first want to ensure that the service has servicemetadata behavior, but httpgetenabled can not be true. In addition, we need to explicitly add an endpoint for the service, where the address, bindings, and contracts are specified and we cannot change

<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 press this configuration, we must access the exposed metadata by the following address

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

Note that because HTTP GET is not turned on, we cannot enter this address directly in the browser to get the WSDL (it will prompt for a 400 error) and we must access it by svcutil.exe or adding a service reference.

When using svcutil.exe or service references, you can not care whether the metadata is exposed in HTTP GET or MEX, they will automatically find the right way, only need to input the Svc file address of the service can be, but we should know that the two kinds of metadata disclosure is a different way.

6. Summary

Through today's study, we have learned more about the principles of WCF metadata exchange and meta-data interchange. While we will and should use metadata exchange tools to help improve efficiency in real projects, all that is happening behind this is something that we should be able to grasp.

Related Resources

MSDN documentation for Svcutil.exe usage

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

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

[Honestly learn WCF] Sixth chapter metadata Exchange