最近为公司完成了一个 ESB 的设计。下面简要说明一下具体的设计方案。
企业 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 网站：
模拟服务：
服务的调用：
服务调用过程中的管道模块设计：
路由表及路由更新：
适配器：
最后，是最重要的持久化的领域实体：
细节不说了，有兴趣的朋友可以参考初步的设计，并欢迎与我交流。:)