ESB zone

小插曲：一种业务依赖的思考

存在业务A，例如IM工具绑定，用户只有绑带了IM才能使用我们的新闻订阅服务；后来，基于IM工具，我们又开发了交易产品。业务规定：如果用户取消了IM工具绑定，那么IM交易产品也取消。从数据上看，IM交易产品，要是适用IM绑定产品的信息，存在数据上的依赖。

起初系统部署在一个JVM内，当取消IM绑定的时候，也会随着取消IM交易协议（用户选择适用IM交易产品的过程，从业务本质看是客户与我们的签订协议过程，因此取消也是一个协议过程，为什么适用这么复杂的概念？在程序级别就是一个删除或更新。）。

现在2个产品部署在不同服务器上，当取消IM绑定的时候，是否需要取消IM交易协议，在那个点来取消，就引起了争论。

如图所示：第一阶段程序都是Jar依赖，可以认为在一个JVM中，执行取消IM绑定倒也方便。第二阶段，业务分布式部署之后，就对IM交易协议如何处理引发争议。

注：IM绑定、IM交易、客户平台、管理平台都是系统。

观点1：取消IM绑定，IM交易协议也取消。解决方法：客户平台、管理平台直接调用IM绑定、IM交易。

观点2：取消IM绑定，IM交易协议也取消。解决方法：客户平台、管理平台直接调用IM绑定，IM绑定调用IM交易。

观点3：取消IM绑定，IM交易协议也取消。解决方法：客户平台、管理平台直接调用IM绑定，IM绑定利用ESB的可靠Pub/Sub机制触发IM交易。

观点4：取消IM绑定，忽略IM交易协议。由IM交易产品自己获取IM绑定状态，从而做出业务处理。

1-3观点，从业务上是一致的，4是独立的。

从用户的角度来说，好像只要最终不能适用IM交易，系统目标就完成，对于做业务的人这样看问题是否合适？也可以，毕竟是2个独立系统吗，只要数据上作一次判读，就不会有任何问题，这个解释也可以接受的。典型程序员思维，系统作出正确表现即可。

从OO的角度来看，IM交易的是IM绑定的扩展，本体不存在，扩展存在还有什么意义？

从业务角度看，用户2次绑定，意味着发生了2次签约，第一次和第二次是否可以认为是一个签约，如果不是，IM交易协议以谁为依据。对于IM交易系统，它从IM绑定系统获取数据，不是为了验证是否存在IM绑定，而是要验证合约与数据是否一致。从这个角度看，IM绑定取消，意味着IM交易的自动失效。

[注：在单系统的时候，由于方便，往往不会像太多，反正方便，也没有人有啥疑义；一旦分布之后，业务独立切分了，大家都麻烦了，就开始思考了，此时采用什么方式往往由业务本性（什么是业务本质=？本性，我也定义不清楚）来决定。]

既然皮之不存，毛将焉附？1，2，3好像都满足，此时，我们在从业务出发，就会发现2，3更合乎业务，触发IM交易取消的事件不是用户直接发出的指令，而是IM绑定发生业务变化之后，通知它的粉丝（依赖着）。

2与3的选择，从架构扩展性，SOA治理，服务化的角度来看，选择3为佳。

有以下几个细的出发点供参考：

1. 服务化，就是要确保每个独立业务的稳定性，采用观点2，一旦再有一个IM物流业务，就需要修改IM绑定业务。
2. 大规模群集环境下，直接xfire之类的框架调用，需要独立引入软件负载，或者采用硬件负载。
3. IM绑定和IM交易可以接受有限制异步模式，这对于性能，有很多帮助。如果IM交易，又依赖其它业务，同步访问的稳定性和性能会受到影响，事务处理也头痛。【参考：SOA，想说爱你不容易】
4. SOA化之后，对服务的监控、治理要求会逐步提高，由统一的一个ESB产品来解决，会更好一些。

对于业务性比较强的公司和项目，多一些业务本质上的思考，少一些程序、数据角度的解决方案，带来的益处还是很多的。

对于这一类的业务，至于选择哪个方案，还要结合业务量，业务发展速度，成本，时间，人力等多个角度来衡量，对于我们合适的方案未必适合每一个人。