我所理解的Remoting(3):创建CAO Service Factory使接口和实现相互分离

我们知道对于Remoting，有两种不同的Activation模式：Server Activation和Client Activation。他我在前面的系列文章中分析、比较了这两种不同激活方式的区别：Marshaling方式，远程对象创建的时机，状态的保持，生命周期的管理。 在编程模式方面Server Activation和Client Activation也具有一定的差异：为一个SAO（server activated object）和一个CAO（client activated object）注册一个远程对象类型的方式是不同的（Wellknown Service Type Re V.S. Activated Type Registration）;为为一个SAO（server activated object）和一个CAO（client activated object）创建Proxy的方式也不一样：对于SAO，一般通过Activator的静态方法GetObject(传入一个远程对象的地址)；而我们一般通过new 关键字或者Activator的静态方法CreateInstance。

String remoteAddress = "http://localhost/Artech.CAOFactory/CounterFactory.rem";        
ICounter counter = ICounterFactory counterFactory = (ICounterFactory)Activator.GetObject(typeof(ICounterFactory), remoteAddress);

对于Client Activation，由于我们在创建Proxy对象的时候，必须利用远程对象对应的原数据，所以在Client端，需要引用远程的对象所对应的dll。比如我们现在做一个简单的计数器的例子（Client远程调用获得计数器当前的计数）我们把业务逻辑封装在Counter Service的实体中。下图反映了这样一种架构的依赖关系。

经验丰富的开发人员很快会意识到这是一种很不好的分布式构架。从SOA的角度来讲也是不值得推荐的构架方式。SOA崇尚的是Contract层面的共享，而拒绝Type层面的共享。Common　Type增加了交互双方的依赖性，造成的紧耦合。所以我们一般从Service中把相对静态的Contract（可以简单地把 Contract看成是Service提供的所有操作的列表和调用的接口）提取出来，作为双方交互的契约：Client只要满足这个Contract，它就能够调用相应的Service，而Service 真正实现的改变对Client没有任何的影响，实际上Service的实现对于Client来说是完全透明的。我们可以说基于Contract的共享成就了SOA的松耦合。通过提取Contract之后，各个实体成为了下面一种依赖关系。

但是对于Client Activation，要直接实现这样的构架是不可能的。我们已经说过，Client创建一个CAO Proxy，需要和Host端注册的远程类型对应的原数据，换句话说，如果远程类型实现在CounterService的dll中，Host和Client双方都需要引用这个dll——虽然实现部分的代码对Client毫无意义。但是现在我们的目的的吧这个dll仅仅驻留在Host中，Client只需引用存储Contract的dll。

在一个分布式环境中，一个Application要跨AppDomain调用一个驻留在另一个AppDomain的的方法，他不需要获得这个真正的远程对象（而实事上它也不可能获得在另一个AppDomain中创建的对象），它只需要获得该对象的一个引用（说得具体点，它只需要获得该对象的ObjRef），并根据这个引用创建相应的Proxy来进行远程调用。或者说，我们只要通过某种方法把Server端创建的对象通过Marshaling传递到Client端，Client就可以进行远程调用了。

那么如何为一个远程调用从另一个AppDomain中获取一个远程对象的引用并创建Proxy呢？而这个获取的方式本身也是一个远程调用。我们的做法是：通过一个基于SAO的远程调用获取一个远程对象的引用并同时创建Proxy。而这个Proxy对应的远程对象就像当于一个CAO．

下面是我们的解决方案简要的类图。我们整个基于计数器的Service封装在CounterService中，它实现了ICounter接口，CounterFactoryService用于创建一个CounterService对象，它实现的接口是ICounterFactory。

现在我们就来实现它：

Step 1: 建立这个Solution的整体结构

整个Solution包含3个Project：Artech.CAOFactory.Contract；Artech.CAOFactory.Service；Artech.CAOFactory.Client。Artech.CAOFactory.Contract被Artech.CAOFactory.Service和Artech.CAOFactory.Client引用。我们使用IIS的Host方式，从而省略了Host Application。

Step 2 创建Contract

ICounter

using System;
using System.Collections.Generic;
using System.Text;

namespace Artech.CAOFactory.Contract
{
  public   interface ICounter
    {
      int GetCount();
    }
}

ICounterFactory

using System;
using System.Collections.Generic;
using System.Text;

namespace Artech.CAOFactory.Contract
{
    public interface ICounterFactory
    {
        ICounter CreateService();
    }
}

Step 3 实现Contract：Artech.CAOFactory.Service

using System;
using System.Collections.Generic;
using System.Text;
using Artech.CAOFactory.Contract;

namespace Artech.CAOFactory.Service
{
    public class CounterService : MarshalByRefObject,ICounter
    {
        private int _count;

        ICounter Members#region ICounter Members

        public int GetCount()
        {
            this._count++;
            return this._count;            
        }

        #endregion
    }
}

CounterFactoryService

using System;
using System.Collections.Generic;
using System.Text;
using Artech.CAOFactory.Contract;

namespace Artech.CAOFactory.Service
{
    public class CounterFactoryService :MarshalByRefObject, ICounterFactory
    {
        
        ICounterFactory Members#region ICounterFactory Members

        public ICounter CreateService()
        {
            return new CounterService();
        }

        #endregion
    }
}

Step 3 通过IIS Host CounterFactoryService

修改编译配置把Dll生成在Project根目录的bin目录下，基于这个根目录创建虚拟目录（假设Alias就是Artech.CAOFactory），并添加Web.config。

<?xml version="1.0"?>
<configuration>
    <configSections>
        <section name="WorkflowRuntime" type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </configSections>
    <WorkflowRuntime Name="WorkflowServiceContainer">
        <Services>
            <add type="System.Workflow.Runtime.Hosting.ManualWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
            <add type="System.Workflow.Runtime.Hosting.DefaultWorkflowCommitWorkBatchService, System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        </Services>
    </WorkflowRuntime>
    <appSettings/>
    <connectionStrings/>
    <system.web>        
        <compilation debug="false"/>        
        <authentication mode="Windows"/>        
    </system.web>
    <system.runtime.remoting>
        <application>
            <service>
                <wellknown type="Artech.CAOFactory.Service.CounterFactoryService, Artech.CAOFactory.Service"
                           mode ="SingleCall" objectUri="CounterFactory.rem"></wellknown>
            </service>
        </application>
    </system.runtime.remoting>
</configuration>

Step 4 创建客户端Artech.CAOFactory.Client

Program

using System;
using System.Collections.Generic;
using System.Text;
using Artech.CAOFactory.Contract;
using System.Threading;
using System.Runtime.Remoting;

namespace Artech.CAOFactory.Client
{
    class Program
    {
        const string REMOTE_ADDRESS = "http://localhost/Artech.CAOFactory/CounterFactory.rem";
        static void Main(string[] args)
        {
            ICounterFactory counterFactory = (ICounterFactory)Activator.GetObject(typeof(ICounterFactory), REMOTE_ADDRESS);
            ICounter counter = counterFactory.CreateService();

            while (true)
            {
                Console.WriteLine("The current value of the counter is {0}", counter.GetCount());
                Thread.Sleep(5000);
            }
        }
    }
}

从上面的代码我们可以看到，我们希望使用的远程对象的Proxy（counter），是通过另一个SongleCall Proxy（counterFactory）获得的。

下面来运行，从输出结果来看，和我们平常使用的SAO方式的结果没有什么两样——同一个Proxy之间的调用状态被保留。


相关章节：
[原创]我所理解的Remoting（1）：Marshaling & Activation - Part I
[原创]我所理解的Remoting（1）：Marshaling & Activation - Part II
[原创]我所理解的Remoting（2）：远程对象生命周期的管理—Part I
[原创]我所理解的Remoting (2) ：远程对象的生命周期管理-Part II
[原创]我所理解的Remoting(3):创建CAO Service Factory使接口和实现相互分离
[原创].NET Remoting: 如何通过Remoting实现双向通信（Bidirectional Communication）