WCF distributed development step for Win (3) WCF service Metadata Exchange, configuration, and programming development

Today we continue the WCF distributed development step for Win (3) WCF service Metadata Exchange, configuration, and programming development learning. Through the previous two sections of learning, we understand the basic concepts of WCF distributed development and the complete development and configuration process of custom hosted hosting services. Today we will learn more about the WCF service metadata Exchange. What exactly is WCF service metadata? Why are WCF services exposing metadata exchange nodes? What does this have to do with previous Web service? What are the ways WCF service metadata is exchanged? How we implement the WCF service metadata Exchange is explained in detail in this section. The full-text structure is as follows: The basic concept of "1" WCF Service metadata, "2" WCF Service Metadata Exchange describes the "3" WCF Service Metadata Exchange configuration implementation process detailed "4" WCF Service metadata Exchange programming implementation process detailed "5" summary.

Basic concepts of the "1" WCF Service metadata:

What exactly is WCF service metadata? What is the role of it? Why are WCF services exposing metadata exchange nodes? What does this have to do with previous Web service? These are often problems that we often obsess about when we learn about the development of WCF services distributed systems.

What is the "1.1" WCF Service metadata:

WCF service metadata is the raw description information for the core part of the WCF Service (address), binding (communication protocol binding), contract (service, operation, data Contract). The metadata exposed by the service includes XSD (elements that appear in the document, attributes that appear in the document, child elements, number of child elements, order of child elements, whether elements are empty, data types of elements and attributes, default and fixed values for elements or attributes), and WSDL documents (methods, parameters, number of parameters, order for describing services) , return value, the type of return value, and so on). Disco document (describes the service's protocol, address, namespace, and so on).

These key WCF service metadata are all based on XML language descriptions and support the core industry standard protocols. XSD benefits are obvious, XML-based, there is no specific syntax, XML Schema supports a series of data types (int, float, Boolean, date, etc.), an extensible data model, support for comprehensive namespaces, support for attribute groups, and so on. And these formal WCF distributed services pursue a key part of the cross-language, cross-platform.

Why do "1.2" expose service metadata:

Knowing the concept of WCF service metadata, we can understand why the metadata of the service is exposed. The metadata for a WCF service describes the core information of the service, which the client needs to understand to communicate with the service. To achieve communication between heterogeneous platforms or systems, the previous technique was to use web Service. Because of its self-description, extensible, platform-independent and other advantages. The client simply needs to be able to obtain information about the service based on the Web service address, the code that deserializes the session local, and the invocation of the service through the service proxy.

One of the main features of WCF services is cross-platform service interactions. The important reason of exposing service metadata is to solve the key problem of heterogeneous client service interaction. Metadata is based on XML, self-describing. The client can generate local code, either C#,VB or Java, based on the service's meta-data deserialization.

Service and Web service comparison for "1.3" WCF:

One of the key features of WCF is the core protocol that supports Web service. Both the service application and the code that references the client service in the actual project can see a lot of similarities. Here's a line to see the code structure of the service program (for example, IIS hosting).

Both include their own extension files and their corresponding service code files.

Then take a look at the local code structure after the client reference service. The first is the local file that the Web service client references:

Next is the file structure referenced by the WCF Client service:

Both include local code files for the service (deserialization generated local service-related code), WSDL service description file, XSD service structure file. The WCF framework model has somewhat referenced the previous ASP. NET Web Service and extended it.

Description of the "2" WCF Service Metadata exchange:

There are two scenarios for WCF services that can publish their own metadata. One is to provide metadata based on the Http-get protocol, and the other is the MEX endpoint metadata Exchange, which, like the WCF service, uses a specialized endpoint called the MEX metadata Exchange endpoint.

Defined in the Metadataexchangeclientmode enumeration type in the System.ServiceModel.Description namespace. The code is as follows:

Using System;

Namespace System.ServiceModel.Description
{
Summary:
Specifies the Exchange mode used to obtain metadata.
public enum Metadataexchangeclientmode
{
Summary:
A Ws-transfer Get request is used.
MetadataExchange = 0,
//
Summary:
An HTTP GET request is used.
HttpGet = 1,
}
}

The metadata exchange endpoint is similar to other endpoints, contains its own address, binding (communication protocol binding), contract (service, operation, data Contract), but the service contract used is the interface IMetadataExchange provided by WCF. Two different kinds of standard network transport protocols are used for publishing metadata, the former is the http/get request, and the latter is Ws-metadataexchange (MEX:WCF supported binding protocols such as HTTP, HTTPS, TCP, IPC, and so on).

After you enable the Metadata Exchange service, you must explicitly configure the metadata exchange behavior. Let's take a detailed description of the implementation process of WCF service metadata Exchange configuration and programming, respectively.

The "3" WCF Service Metadata Exchange configuration implementation process is explained in detail:

"3.1" Configuration Http-get Metadata Exchange Mode:

The service's behavior and base address need to be configured, and the client can view the metadata of the service based on the base site. The code is as follows:

<service name= "Wcfserviceapp.wcfservice" behaviorconfiguration= "Wcfserviceapp.wcfservicebehavior" >
<baseAddresses>
<add baseaddress= "http://localhost:8001/"/>
</baseAddresses>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name= "Wcfserviceapp.wcfservicebehavior" >
<!--to avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above BEFO Re Deployment--
<servicemetadata httpgetenabled= "true"/>
<!--to receive exception details on faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information-
<servicedebug includeexceptiondetailinfaults= "false"/>
</behavior>
</serviceBehaviors>
</behaviors>

After the configuration is complete, we can use the base site to view the service information in the browser, such as:

"3.2" Configures the endpoint metadata Exchange method:

Here we have configured 3 ways of the metadata Exchange endpoint, namely HTTP, TCP, IPC mode. The specific code is as follows:

<endpoint address= "Mex" binding= "mexHttpBinding" contract= "IMetadataExchange"/>
<endpoint address= "Mex" binding= "mextcpbinding" contract= "IMetadataExchange"/>
<endpoint address= "Mex" binding= "mexnamedpipebinding" contract= "IMetadataExchange"/>
<baseAddresses>
<add baseaddress= "http://localhost:8001/"/>
<add baseaddress= "net.tcp://localhost:8002/"/>
<add baseaddress= "net.pipe://localhost/"/>
</baseAddresses>
Service behavior:
<serviceBehaviors>
<behavior name= "Wcfservice.wcfservicebehavior" >
<servicemetadata httpgetenabled= "true"/>
<servicedebug includeexceptiondetailinfaults= "false"/>
</behavior>
</serviceBehaviors>
</behaviors>

The "4" WCF Service metadata Exchange programming implementation process is explained in detail:

The above configuration file implements the metadata exchange of the WCF service, which we can also implement programmatically. The former is simple and fast, the latter is relatively complex. However, programming allows the code to run while controlling or setting information for metadata exchange. thus more flexible. Let's take a look at how the code implements the configuration of the original data exchange of the service.

"4.1" WCF Service Metadata Exchange Http-get programming implementation:

You must add a reference to the namespace, using System.ServiceModel.Description; We define the class and interface information for the service metadata operation in this namespace, and the specific implementation Http-get code is as follows:

ServiceMetadataBehavior metadatabehavior;//defines the service behavior variable,
Metadatabehavior = host. Description.behaviors.find<servicemetadatabehavior> ();
Gets the list of behaviors for the host
if (Metadatabehavior = = null)//If there is no behavior to service the original data exchange, instantiate add service original data exchange behavior
{
Metadatabehavior = new ServiceMetadataBehavior ();
Uri httpaddress = new Uri ("http://localhost:8001/");
Metadatabehavior.httpgeturl =httpaddress;
metadatabehavior.httpgetenabled = true;//Set HTTP mode
Host. DESCRIPTION.BEHAVIORS.ADD (Metadatabehavior);
}

The first is to obtain a list of service behavior, if not set, we will instantiate the service original data exchange behavior, and set the HTTP method is available. Host. DESCRIPTION.BEHAVIORS.ADD (Metadatabehavior); Adds the behavior of the hosting service.

"4.2" WCF Service Metadata Exchange WS-* Programming Implementation:

Here respectively, the HTTP, TCP, IPC Three ways of the metadata Exchange code. Slightly different from the http-get approach, we need to instantiate our own binding elements and bindings, and finally pass them as parameters to the host host instance. The specific implementation code is as follows:

2 ws* original data exchange by means of programming
Life Three binding node classes
BindingElement tcpbindingelement = new Tcptransportbindingelement ();
BindingElement httpbindingelement = new Httpstransportbindingelement ();
BindingElement pipebindingelement = new Namedpipetransportbindingelement ();
Instantiate an instance of a generic binding class
Binding tcpbinding = new CustomBinding (tcpbindingelement);
Binding httpbinding = new CustomBinding (httpbindingelement);
Binding pipebinding = new CustomBinding (pipebindingelement);
//
Uri tcpbaseaddress = new Uri ("net.tcp://localhost:9001/");
Uri httpbaseaddress = new Uri ("http://localhost:9002/");
Uri pipebaseaddress = new Uri ("net.pipe://localhost/");
Host. AddServiceEndpoint (typeof (Wcfservice.iwcfservice), New NetTcpBinding (), tcpbaseaddress);
Host. AddServiceEndpoint (typeof (Wcfservice.iwcfservice), New Wshttpbinding (), httpbaseaddress);
Host. AddServiceEndpoint (typeof (Wcfservice.iwcfservice), New NetNamedPipeBinding (), pipebaseaddress);

ServiceMetadataBehavior metadatabehavior;//defines the service behavior variable,
Metadatabehavior = host. Description.behaviors.find<servicemetadatabehavior> ();
Gets the list of behaviors for the host
if (Metadatabehavior = = null)//If there is no behavior to service the original data exchange, instantiate add service original data exchange behavior
{
Metadatabehavior = new ServiceMetadataBehavior ();

Host. DESCRIPTION.BEHAVIORS.ADD (Metadatabehavior);
}
If you do not have a MEX node available, you can use the code to determine that the MEX node is added

Host. AddServiceEndpoint (typeof (IMetadataExchange), tcpbinding, "Mex");
Host. AddServiceEndpoint (typeof (IMetadataExchange), httpbinding, "Mex");
Host. AddServiceEndpoint (typeof (IMetadataExchange), pipebinding, "Mex");

"5" Summary:

Run the host program, the client adds a service reference, using different metadata addresses, we can query to different service information. The results are as follows:

"5.1" Http-get Way:

"5.1" Endpoint HTTP mode:

"5.1" Endpoint TCP mode:

"5.1" End point IPC mode:

"5.5" Conclusion

The above is all the details of the WCF service metadata Exchange related concepts, configuration and programming implementations of Http-get and WS-* protocols for metadata exchange. In addition to the information about the contract of service, data and operation, there are other information about the metadata, such as things, reliability, error handling and so on.

With these implementations in view, in the actual WCF service project, we can configure the metadata exchange in a different way. WCF metadata Exchange is in fact similar to the Web service original data exchange, all based on XML language description, the original data exchange is so important.

First of all, XML-based metadata can achieve cross-language, cross-platform service interaction, truly independent of the platform.

Secondly, the local proxy class is generated by the original data deserialization, because it realizes the decoupling of the real client and server, and reduces the coupling degree between the system. The traditional method of assembly reference can not reduce the coupling degree of the system, which is the goal of our system design.

These are the entire contents of the WCF service metadata interaction, and the following upload the instance code for this section:

/files/frank_xl/wcfservicemexfrankxulei.rar. For your reference, also welcome message discussion ~

WCF distributed development step for Win (3) WCF service Metadata Exchange, configuration, and programming development