我所理解的Remoting(3):创建CAO Service Factory使接口和实现相互分离
我所理解的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
{
conststring REMOTE_ADDRESS ="http://localhost/Artech.CAOFactory/CounterFactory.rem";
staticvoid 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之间的调用状态被保留。
