[WCF] endpoints and service addressing (5)

Source: Internet
Author: User

This is the fifth article in the series of endpoints and service addressing.Article.

5. Separate the physical and logical addresses deployed at the endpoints

In experiment 1, I have mentioned the concept of physical addresses and logical addresses. In fact, physical addresses are a listening address established by the service host to receive service call request information, the channel listener is the WCF component responsible for this work. When a message arrives at the listening address, the channel dispatcher selects an appropriate one from several endpoints associated with the message, the tool used to determine whether an endpoint is suitable is the two filters used by the endpoint dispatcher of each end point, namely, the address filter) and the service contract filter (contractfilter ). They are all messagefilter types. You can customize the message filtering method by setting the filter used by the end point dispatcher. How to Set Up and verify the experiment. Return to the topic of this article.

First, I will provide the service hostProgramOfCodeThe code is modified to display more information:

Code

Private Static Void Displayallendpointlogicalandphysicaluri (servicehost host)
{
Foreach (Channeldispatcher CD In Host. channeldispatchers)
{
Console. writeline ( " ------------------ Current channel distributor information -------------------- \ n " );

Console. writeline ("Physical address of the listener: {0} \ n", CD. listener. Uri. tostring ());

Console. writeline ("Endpoint list: \ n");

Foreach(Endpointdispatcher edInCD. endpoints)
{
Console. writeline ("Logical endpoint address: {0}", Ed. endpointaddress. Uri. tostring ());
}

Console. writeline ();
}

Console. writeline ();
}

In the displayallendpointlogicalandphysicaluri method in the code, I used the endpoints attribute in the channeldispatcher object. This attribute is the set of endpoint dispatcher objects, and can be used to obtain all the end point splitters associated with the channel dispatcher. Next, let's take a look at the server configuration file:

Code

< Services >
< Service Name = "Wcf_study1.servicecontracts.systeminfoservice"
Behaviorconfiguration = "Metabehavior" >
< Endpoint Address = "Systeminfoservice"
Listenuri = "Http: // localhost: 8888/systeminfoservice"
Binding = "Wshttpbinding"
Contract = "Wcf_study1.servicecontracts.isysteminfoservicecontract" />

<EndpointAddress= "Systeminfoservicev3"
Listenuri= "Http: // localhost: 8888/systeminfoservice"
Binding= "Wshttpbinding"
Contract= "Wcf_study1.servicecontracts.isysteminfoservicecontract" />

<! --

<Endpoint address = "systeminfoservicev5"
Listenuri = "net. TCP: // localhost: 8111/systeminfoservice"
Binding = "wshttpbinding"
Contract = "wcf_study1.servicecontracts.isysteminfoservicecontract"/>

When the logical address is inconsistent with the physical address protocol, an exception is thrown immediately when the service host Program is started.
-->

< Host >
< Baseaddresses >
< Add Baseaddress = "Http: // localhost: 8000" />
</ Baseaddresses >
</ Host >
</ Service >
</ Services >

In the configuration code above, each <endpoint/> node sets a new attribute-listeneruri, which sets the physical address used by each server endpoint, that is, the address that truly listens to the request message of a service call. As you can see from the code of the service host program, this address can be obtained through the listener attribute of the channeldispatcher object, and then from its URI attribute. I believe that at this step, the reader understands that each server end point can use the same physical address, because the concept of physical address actually belongs to the channel listener rather than the end point.

The code of the client program is nothing special, that is, simply construct the Service proxy and then call the service, so it is not pasted; but the client configuration file has interesting points:

Code

< Behaviors >
< Endpointbehaviors >
< Behavior Name = "Clientendpointbehavior" >
<! -- <Clientvia viauri = "http: // localhost: 8888/systeminfoservice"/> -->
</ Behavior >
</ Endpointbehaviors >
</ Behaviors >

<! --Other unrelated configurations-->

< Client >
< Endpoint Address = "Http: // localhost: 8000/systeminfoservice"
Behaviorconfiguration = "Clientendpointbehavior"
Binding = "Wshttpbinding" Bindingconfiguration = "Wshttpbinding_isysteminfoservicecontract"
Contract = "Services. isysteminfoservicecontract" Name = "Wshttpbinding_isysteminfoservicecontract" >
< Identity >
< Userprincipalname Value = "KL-THINK \ KL" />
</ Identity >

<! --
Basichttpbinding requires that the physical address must be consistent with the logical address. Therefore, you can only use wshttpbinding for separation.
-->
</Endpoint>
</Client>

In the client configuration file, set a behavior named clientendpointbehavior In the endpoint Behavior Set (<endpointbehaviors> </endpointbehaviors>, this behavior allows you to set a <clientvia/> node to control the physical listening address (viauri) that a client message must pass before reaching the destination endpoint ). When the client endpoint uses this behavior, the client can call the remote service normally, but if the "Transfer Station" address is not set, when the remote service is called, the following exception is thrown:

The last attempt is to deploy an endpoint. The logical address is inconsistent with the physical address protocol, that is, the endpoint commented out in the server configuration file. After the annotation is canceled, the following exception is thrown when the service host Program is started:

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.