基于WCF搭建的ESB （一）

因为博客这里还没搞明白怎么上传源代码，先把我写在codeproject上的链接挂到在这里

How to abstract a WCF Service out of business logic

Service Bus Architecture based on WCF (3): build your ESB

这两篇是系列文章，其实还有第一篇，codeproject告诉我写的太简单不能发表在article里面，所以一直都无法见天日.

 

---

ESB已经不是一个新的概念，各个软件供应商也有相应的产品支撑。MS的biztalk，ORACLE的aqualogic等等。很早以前提的EAI可以理解成为ESB+BMP。讨论这些企业级的产品不是今天的主题。我想讨论的是在wcf推出后，我们是否能基于wcf建立一套轻量级的ESB架构以支撑一般业务下的企业消息分发。

一个企业里都有不同的为某项功能而实现的IT应用，每个应用在一定程度上都是信息孤岛。在我的理解里不同用途的企业应用从设计上本来就应该是信息孤岛，这并不违背SOLID原则里的任何一条原则。

 

Single Responsibility原则描述了小到一个方法，大到一个模块，再大到一个应用程序，它的功能应该是单一的。一个方法如果是更新一条记录那么就不要在这个方法里实现如果这条记录没有找到去而新增一条记录，我们可以剥离出一个更小的方法去实现新增这个功能。同样的，一个财务系统就应该去作财务的事情，不需要去想代码里或者数据库里将要考虑未来公司货物的库存问题。但是很显然我们很容易事先知道出入库会直接影响到财务。考虑的越多，系统就会变的越复杂，当我们把库存纳入到视野里，那么人事系统，采购系统等等就要考虑。我们哪里有时间考虑这么多。就像敏捷里说refactoring，重构就是为了应对明天的改变。预期是没有尽头的，因为这个世界上本身就没有完美的东西。那么放到application级别上何尝有不是呢，每个application都做好自己的事情，他们之间的未来合作就像是基于实现ESB而做的重构一样。所以不要苛求一个数据库支撑了不同的应用系统，也不要去考虑太多系统间的依赖关系。他们之间原本上就应该没有关系。

 

SOLID原则还有一条我个人认为很重要的原则，就是开放封闭原则(Open Closed Principle)。上面其实我们讨论了封闭原则，可如果所有的应用都像上面讨论的完全的封闭而自我管理是不是正确的？我曾经实施过很多类型的EAI项目，当你试图和一个10几年前的没有实现远程调用的程序通讯的时候，那种痛苦是可想而知的。通常我们有几种做法：

1. 改数据库，添加触发器：比如一个10年前的程序是出入库管理，在出入库的table里添加一个触发器，当出入库了，通知某某财务程序把相应的钱改一下。

2. 轮训侦听：有时候应用封闭的纹丝不动，数据库也不允许做任何改动。那么轮训变化是一种折衷的办法。

3. 把老程序扒开来做代码的修改以使得它和其他程序互通。

。。。。等等，方法有很多，人的想象力总是无限的，无数惊人的创造都是因为开始要解决一个无聊的问题。

方法2是最不触碰老程序的方法，显而易见是最安全的方法。但一般来讲侦听是代价很大的。

方法1和3都是触碰了程序代码，不管是数据库还是应用程序，我们都做了手术，有手术就会有风险，割个双眼皮都会死人。

我们转回来看看开放封闭原则，封闭就是指程序不要改代码，开放是指程序要有扩展性。连在一起就是说好的应用程序应该可扩展的但不可以修改源代码的。如果一定要通过方法1，3去做修改，那么这个应用程序设计的就违背了开发封闭原则。那么那些基于插件的编程，基于接口的编程就是设计的很棒的程序。当你的应用程序公布了足够多的webservice接口；当开发一个应用的插件可以触碰到足够的接口代码。。。那么我们的ESB就具备了很好的基础。回过头来说，不管是连接webservice，plugin编程，扫描文件，轮训数据库，等等等等。。他们都是ESB外面的胶水，搭建外部的程序和企业总线的连接。这些东西我们叫做适配器，Biztalk，aqualogic等等都有很多对特定应用的适配器，有了这些适配器基于不同协议/类型的数据就可以转换成ESB可识别的共同数据。还有一些加速器封装了特定行业的业务和适配器一起使用加快ESB的实施。

说到这里，好像有点跑偏了，刚过年脑子还不太清楚。其实无论是适配器还是加速器，无非是对某些程序做的外部整理工作，将整理好的数据交到ESB，ESB来做分发。

下次我们再一起讨论一下整合有哪些方面的整合。困了，来日再议