WCF后续之旅(15) 逻辑地址和物理地址

在WCF中,每个终结点都包含两个不同的地址——逻辑地址和物理地址。逻辑地址就是终结点Address属性表示的地址。至于物理地址,对于消息发送放来讲,就是消息被真正发送的目的地址;而对于消息的接收放来讲,就是监听器真正监听的地址。

1、服务端的物理地址

在默认的情况下,终结点的逻辑地址和物理地址是同一个URI。换句话说,终结的逻辑地址是必须的,如何物理地址没有指定的,默认使用逻辑地址作为物理地址。对于消息接收方的终结点来讲,物理地址就是监听地址,通过ServiceEndpoint的ListenUri表示:

//---------------------------------------------------------------
// EndpointAddress & WCF Addressing (c) by 2008 Jiang Jin Nan
//---------------------------------------------------------------
public class ServiceEndpoint
{
  ... ...
  public Uri ListenUri { get; set; }
}

在对服务进行寄宿的时候,我们可以调用SeriviceHostBase或者ServiceHost的AddServiceEndpoint对应的重载来为添加的终结点指定ListenUri:

//---------------------------------------------------------------
// EndpointAddress & WCF Addressing (c) by 2008 Jiang Jin Nan
//---------------------------------------------------------------
public abstract class ServiceHostBase : CommunicationObject, IExtensibleObject<ServiceHostBase>, IDisposable
{
  ... ...
  public ServiceEndpoint AddServiceEndpoint(string implementedContract, Binding binding, string address, Uri listenUri);
  public ServiceEndpoint AddServiceEndpoint(string implementedContract, Binding binding, Uri address, Uri listenUri);
}

public class ServiceHost : ServiceHostBase
{
  ... ...
  public ServiceEndpoint AddServiceEndpoint(Type implementedContract, Binding binding, string address, Uri listenUri);
  public ServiceEndpoint AddServiceEndpoint(Type implementedContract, Binding binding, Uri address, Uri listenUri);
}

在下面的代码片断中,就为终结点指定了一个同于逻辑地址的物理地址(ListenUri):

//---------------------------------------------------------------
// ListenUri.cs (c) by 2008 Jiang Jin Nan
//---------------------------------------------------------------
using (ServiceHost serviceHost = new ServiceHost(typeof(CalculateService)))
{
  serviceHost.AddServiceEndpoint(typeof(ICalculate),new WSHttpBinding(),
    "http://127.0.0.1:9999/calculateservice",
    new Uri ("http://127.0.0.1:8888/calculateservice"));
  Console.Read();
}

当然,ListenUri也可以通过配置进行指定,下面的配置和上面的代码是等效的:

<configuration>
  <system.serviceModel>
    <services>
      <service name="Artech.WcfServices.Services.CalculateService">
        <endpoint binding="wsHttpBinding"
          contract="Artech.WcfServices.Contracts.ICalculate"  address="http://127.0.0.1:8888/calculateservice"
          listenUri="http://127.0.0.1:8888/calculateservice" />
      </service>
    </services>
  </system.serviceModel>
</configuration>

时间: 2024-12-09 07:20:00

WCF后续之旅(15) 逻辑地址和物理地址的相关文章

WCF后续之旅(7):通过WCF Extension实现和Enterprise Library Unity Container的集成

松耦合.高内聚是我们进行设计的永恒的目标,如何实现这样的目标呢?我们有很多实现的方式和方法,不管这些方式和方法在表现形式上有什么不同,他们的思想都可以表示为:根据稳定性进行关注点的分离或者分解,交互双方依赖于一个稳定的契约,而降低对对方非稳定性因素的依赖.从抽象和稳定性的关系来讲,抽象的程度和稳定程度成正相关关系.由此才有了我们面向抽象编程的说法,所以"只有依赖于不变,才能应万变". 然后,对于面向对象的思想来讲,我们的功能通过一个个具体的对象来承载.对象是具体的,不是抽象的:创建对象

WCF后续之旅(8):通过WCF Extension 实现与MS Enterprise Library Policy Injection Application Block 的集成

在上一篇文章中,我们通过自定义InstanceProvider实现了WCF和微软Enterprise Library Unity Application Block的集成, 今天我们已相同的方式实现WCF与Enterprise Library的另一个Application Block的集成:Policy Injection Application Block (PIAB). PIAB,通过Method Interception的机制实现了AOP(Aspect Oriented Programin

WCF后续之旅(13): 创建一个简单的WCF SOAP Message拦截、转发工具[上篇]

WCF是.NET平台下实现SOA的一种手段,SOA的一个重要的特征就基于Message的通信方式.从Messaging的角度讲,WCF可以看成是对Message进行发送.传递.接收.基础的工具.对于一个消息交换的过程,很多人只会关注message的最初的发送端和最终的接收端.实际上在很多情况下,在两者之间还存在很多的中间结点(Intermediary),这些中间结点在可能在实际的应用中发挥中重要的作用.比如,我们可以创建路由器(Router)进行消息的转发,甚至是Load Balance:可以创

WCF后续之旅(13):创建一个简单的SOAP Message拦截、转发工具[下篇]

在Part I 中,我们创建了一个InterceptService,并且通过一个特殊的EndpointBehavior,ClientViaBehavior实现了message的拦截.转发功能.在本节中,我们将讨论另外一种不同的实现方式.如何说ClientViaBehavior是基于Client端的实现方式,那么我们今天讨论的是基于Service的实现方式. 在对新的实现方式展开介绍之前,我们先来介绍一下关于逻辑地址和物理地址. 一.逻辑地址和物理地址 我们知道,WCF通过Endpoint进行通信

《WCF后续之旅》博文系列总结[共17篇]

<我的WCF之旅>系列自开篇以来,得到了园子里很多朋友的厚爱,并荣登了博客园2007年度系列博文Top 10.由于工作原因,沉寂了一阵,两个月前开始WCF新的旅程.如果说<我的WCF之旅>主要是对WCF基本原理概括性介绍,而对于这个新的系列,我将和大家分享我对WCF的一些实现机制.设计原理的理解,以及我在实际的项目开发中的一些实践经验(比如在后续的一些文章中,我将介绍通过WCF Extension实现一些在真正的分布式项目开发中很有现实意义的功能). [第1篇] WCF是如何通过B

WCF后续之旅(9): 通过WCF双向通信实现Session管理[下篇]

一.Session Management Service的实现 现在我们来看看Session Management真正的实现,和我以前的例子不同,我不是把所有的实现都写在WCF service上,而是定义了另一个class来实现所有的业务逻辑:SessionManager.我们分析一下具体的实现逻辑. 1: namespace Artech.SessionManagement.Service 2: { 3: public static class SessionManager 4: { 5: p

WCF后续之旅(4):WCF Extension Point 概览

在本系列的每篇文章中,我多次提到WCF是一个极具可扩展性的分布是消息通信框架.为了让读者对WCF Extension有一个总体的的认识,在这里我会简单列举了我们经常使用的绝大部分的扩展点,以及通过这些扩展点能够解决实现项目开发中的那些问题. 有一点需要特别提醒的是:对WCF extensions的灵活应用依赖于你对channel layer和service mode dispatching system的深入理解.所以,如果你对channel layer不甚了解,可以参阅本系列的第一个部分(WC

WCF后续之旅(9):通过WCF的双向通信实现Session管理[上篇]

我们都知道,WCF支持Duplex的消息交换模式,它允许在service的执行过程中实现对client的回调.WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCF Service.今天我们就给大家一个具体的例子:通过WCF的duplex communication方式现在Session管理. 一.Session 管理提供的具体功能 我们的例子实现了下面一些Session Management相关的功能: Start/End Session:可以调用s

[原创]WCF后续之旅(12): 线程关联性(Thread Affinity)对WCF并发访问的影响

在本系列的上一篇文章中,我们重点讨论了线程关联性对service和callback的操作执行的影响:在service host的时候,可以设置当前线程的SynchronizationContext,那么在默认情况下,service操作的执行将在该SynchronizationContext下执行(也就将service操作包装成delegate传入SynchronizationContext的Send或者Post方法):同理,对于Duplex同行方式来讲,在client调用service之前,如果