最近为公司完成了一个 ESB 的设计。下面简要说明一下具体的设计方案。
企业 SOA 整体方案
在前一篇《SOA、ESB、NServiceBus、云计算 总结》中说到，SOA 是面向服务的架构，其核心思想是把业务进行组件化，而业务组件的能力服务化。
我们的整个 SOA 的设计分为两个层面：一个是系统间的 SOA 设计，另一个则是单个系统内的 SOA 设计。系统间的 SOA 设计，主要是设计一个 ESB 系统来实现各业务系统间的交互。而系统内部的 SOA 设计，则是建立一个组件化的技术平台，使得系统的开发能以一个个业务组件的形式完成，并通过技术平台来实现各业务组件的组合与互连。
一般说的 SOA 设计，都是在讲如何进行系统间的互连，例如如何进行 ESB 的设计。但是，不论是系统间互连，还是系统内部的组件化，其实都是 SOA 思想在不同层面上的体现。而我认为，应用系统内部的 SOA 设计，会更重要。因为它不但是一个低耦合、高复用的产品设计，而且也为系统间的 SOA 提供了更好的支持。
本文，主要说明如何实现 ESB 的设计。而更重要的应用系统内部的组件化产品开发平台，则留到下一篇。
ESB 目标功能
在前一篇中，列出了一个较完整 ESB 应有的功能。SOA 不但包括简单的系统间互边的功能，也应该包含更高级的 BPM 业务流程编排的功能。
下面，简单列出了我们对于我们的 ESB 的功能树：
图中，功能按优先级进行了排序。第一个阶段，只会实现其中红色的部分。而服务编排，则放到了最后。红色部分，是一个 ESB 应该具有的最小功能集。在交互模式部分，我选择了实现‘响应/请求’模式，这种交互方式在系统间互连时场景相对较少，但是不需要引用 MSMQ 等功能，所以实现起来会更简单。
ESB 主体设计
对于 ESB 的主体设计，是参考了网上另一个 ESB 的设计，下面是它的设计图：
ESB 详细设计
首先，规划出 ESB 整个系统内部的所有组件。
- Web Portal：ESB 对外以网站的形式公布。同时，服务调用者、提供者，都是直接使用网站提供的功能。
- Adapter：协议的适配器组件。
- Service Invoker：服务的同步调用器。
- Async Invoker：异步方式的同步调用器。
- Service Mocker：这个组件用于实体 ESB 的服务可以以 WS 等方式暴露。
- ESB Message：ESB 内部的消息结构体。
- Service Registry：服务的注册库。
- Service Router：服务的路由器组件。
- Service Router Cache Notification：路由缓存通知组件。
- Logger：日志组件。
- Exception Handler：异常处理组件。
- Performance Counter：服务调用过程中的一些性能统计工具。
以下是一些详细的调用设计。
ESB 网站：
模拟服务：
服务的调用：
服务调用过程中的管道模块设计：
路由表及路由更新：
适配器：
最后，是最重要的持久化的领域实体：
细节不说了，有兴趣的朋友可以参考初步的设计，并欢迎与我交流。:)