我所理解的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
ExpandedBlockStart.gif {
  public   interface ICounter
ExpandedSubBlockStart.gif    {
      int GetCount();
    }

}

ICounterFactory

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

namespace Artech.CAOFactory.Contract
ExpandedBlockStart.gif {
    public interface ICounterFactory
ExpandedSubBlockStart.gif    {
        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
ExpandedBlockStart.gif {
    public class CounterService : MarshalByRefObject,ICounter
ExpandedSubBlockStart.gif    {
        private int _count;

ContractedSubBlock.gif        ICounter Members
    }

}

CounterFactoryService

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

namespace Artech.CAOFactory.Service
ExpandedBlockStart.gif {
    public class CounterFactoryService :MarshalByRefObject, ICounterFactory
ExpandedSubBlockStart.gif    {
        
ContractedSubBlock.gif        ICounterFactory Members
    }

}

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
ExpandedBlockStart.gif {
    class Program
ExpandedSubBlockStart.gif    {
        const string REMOTE_ADDRESS = "http://localhost/Artech.CAOFactory/CounterFactory.rem";
        static void Main(string[] args)
ExpandedSubBlockStart.gif        {
            ICounterFactory counterFactory = (ICounterFactory)Activator.GetObject(typeof(ICounterFactory), REMOTE_ADDRESS);
            ICounter counter = counterFactory.CreateService();

            while (true)
ExpandedSubBlockStart.gif            {
                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)


作者:蒋金楠
微信公众账号:大内老A
微博: www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送,或者想看看个人推荐的技术资料,可以扫描左边二维码(或者长按识别二维码)关注个人公众号(原来公众帐号 蒋金楠的自媒体将会停用)。
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
相关文章
|
2月前
|
存储 前端开发 Java
一篇文章带你搞懂Controller、Service等各层的功能与作用
本文将深入探讨这些controller.service等层的作用与功能,帮助读者更好地理解它们在软件开发中的重要性和运作原理。
468 0
|
4月前
|
存储 缓存 前端开发
WorkBox 之底层逻辑Service Worker(一)
WorkBox 之底层逻辑Service Worker(一)
|
4月前
|
存储 Web App开发 缓存
WorkBox 之底层逻辑Service Worker(二)
WorkBox 之底层逻辑Service Worker(二)
|
6月前
|
存储 XML Java
Flowable:ProcessEngin(引擎)与Service(服务接口)讲解
Flowable:ProcessEngin(引擎)与Service(服务接口)讲解
113 0
|
10月前
|
SQL 前端开发 JavaScript
JAVA框架的层级和各层理解 controller,service,dao,mapper,model等层和各包的作用
JAVA框架的层级和各层理解 controller,service,dao,mapper,model等层和各包的作用
435 0
|
11月前
|
存储 负载均衡 Kubernetes
简单说说K8S的Service底层,总感觉还是说不清楚。
简单说说K8S的Service底层,总感觉还是说不清楚。
147 0
|
监控 安全 Serverless
AAS即As-a-Service的概念
列举一些接触到的AAS即As-a-Service的概念
340 0
|
域名解析 Kubernetes 负载均衡
k8s service 概念和原理
详细讲解k8s的概念和原理
705 0
k8s service 概念和原理
|
IDE Java 开发工具
Service 层和 Dao 的接口是不是多此一举?
今天我们要探讨的问题是:Service 层和 Dao 的接口是不是多此一举? 现在结合我参与的项目以及阅读的一些项目源码来看。如果「项目中使用了像Spring这样的依赖注入框架,那可以不用接口」! 先来说说为什么使用了依赖注入框架以后,可以不使用接口!
191 0
|
SQL 前端开发 Java
JavaWeb - Action + Service + Dao 三层功能划分
JavaWeb - Action + Service + Dao 三层功能划分
125 0