JointCode.Shuttle，一个简单高效的跨 AppDomain 通信的服务框架

标签：说明   pac   wrap   join   name   blog   高效   lan   自己的   

JointCode.Shuttle 是一个用于 AppDomain 间通信的服务架构。

1. 什么情况下使用 JointCode.Shuttle

在 .net / mono 开发中，一般不太需要使用额外的 AppDomain，但在一些 特定情况 下，让代码运行在新的 AppDomain 中也许是一个好的选择。

当代码需要跨越 AppDomain 边界访问另一个 AppDomain 时，便产生了跨 AppDomain 通信的问题，JointCode.Shuttle 正是专为此目的而开发的一个服务框架。

2. 为什么开发 JointCode.Shuttle

一般来说，在进行跨 AppDomain 调用时，大部分人会选择使用默认提供的 remoting 库作为底层通信机制。代码也很简单，例如：

 1 namespace JoitCode.Shuttle.SimpleSample
 2 {
 3     public class MyService : MarshalByRefObject
 4     {
 5         public void Do() { }
 6     }
 7 
 8     class Program
 9     {
10         static void Main(string[] args)
11         {
12             // 在默认 AppDomain 中创建一个子 AppDomain
13             var serviceDomain = AppDomain.CreateDomain("ServiceDomain", null, null);
14             
15             var myService = (MyService)serviceDomain.CreateInstanceAndUnwrap
16                 (typeof(MyService).Assembly.FullName, 
17                  "JoitCode.Shuttle.SimpleSample.MyService");
18 
19             myService.Do();
20 
21             Console.Read();
22         }
23     }
24 }

View Code

这种方式有什么问题？

• AppDomain 的访问是单点的，即它只能由创建它的宿主（或称父 AppDomain）访问，而不能由其他 AppDomain 访问，即使是由相同宿主创建的其他 AppDomain，甚至其宿主的父宿主也不行。
• 缺少灵活性，由于要求服务类必须继承 MarshalByrefObject 类，这限制了灵活性。
• remoting 库的架构设计复杂（这一点是由需求决定的，因为 remoting 不仅仅是一个跨 AppDomain 通信组件），从本质来说更适合于进程间通信。事实上，进程间通讯才是它的初衷，AppDomain 之间的通信只是其附带产生的价值。
• remoting 的性能问题，由于架构设计的复杂性，必然带来额外的性能开销，因此它造成的最大问题显然是两个 AppDomain 之间访问的速度太慢（测试结果表明跨 AppDomain 访问比普通对象访问慢几百到一千倍）（示例）
• 双向通信。remoting 尽管也支持双向通信，但是服务端如果要调用客户端的代码，需要使用事件 / 回调。对于 AppDomain 之间的通讯来说，这不是一种自然的方式。事实上，它采用的还是一种客户端服务端的思路。

3. JointCode.Shuttle 的特点

与 remoting 相比，JointCode.Shuttle 除了具备相同的跨 AppDomain 通信的功能之外，还有自己的一些特点：

1. 面向接口/服务
2. 服务可管理：可动态注册/注销服务组
3. 更好的性能：比 remoting 快 60～70 倍
4. 使用 Attribute 方式标注服务，对代码无侵入
5. 强类型，使用方便（remoting 依赖 magic string 来查找服务类）
6. 内置 IoC 功能，自动管理服务的依赖项
7. 支持延迟加载类型 / 程序集
8. 支持访问任意 AppDomain 的服务
9. 简单，快速上手
10. 更自然的、任意 AppDomain 之间的通信（remoting 也可以实现双向通信，但不那么自然）
11. 可通过租约方式管理远程服务生命期，也可自行管理
12. 支持 .net 2.0

4. 目前的限制

JointCode.Shuttle 是一个非常新颖的框架，现在功能还不是十分完备，尽管作者计划在未来继续完善现有功能，并推出更多新的功能，但目前还是存在着一些不足，包括：

1. 仅支持 32 位应用程序
2. 仅支持 Windows（目前仅支持 .net framework，不支持 mono）
3. 暂时不支持事件
4. 测试得不够

5. 如何使用 JointCode.Shuttle

如果您对 JointCode.Shuttle 有兴趣，请移步前往 这里，我们提供了一个简单的示例来说明如何使用这个框架。

JointCode.Shuttle，一个简单高效的跨 AppDomain 通信的服务框架

标签：说明   pac   wrap   join   name   blog   高效   lan   自己的   

原文地址：http://www.cnblogs.com/johnny-liu/p/7190730.html