SOA_001：SOA是个啥东东？

这是我第一次写技术博客，我给自己立了一条规矩：那就是无废话。因为我一直认为：读废话连篇的文章等于谋财害命。
在回答什么是SOA的问题之前，请先看下面的例子：
这是一个网上订书系统，核心的业务流程是这样的：
前台：用户访问网站-->浏览图书-->选择图书-->确认订单。
订单提交后，就进入了后台的处理流程。
后台：订单信息入库-->获取用户信息-->检验客户信用卡额度-->是否需要人工审批-->选择价格最低的供书商-->下单给不同的派送公司-->email通知用户。
我们重点讨论后台系统，可以很明显地看出这是一个包含多个操作步骤和逻辑分支的业务流程，需要和不同的系统打交道。
经验丰富的人一定会想到这里有几个问题需要特别注意，因为它们是项目成败的关键：

问题1．如何实现“是否需要人工审批”?目前的需求是这样的，注意需求可能会随时根据市场变化而发生变化：
订单金额在1000元以下的，不需要人工审批。
金卡客户不需要人工审批。
订单金额在1000元以上的，非金卡的客户需要人工审批。
好像实现起来难度不是很大，几个if else判断就能解决，但是一个月后，为了加快订单处理流程，公司决定放宽要求：
订单金额在2000元以下的，不需要人工审批。
金卡客户不需要人工审批。
订单金额在2000元以上的，非金卡的客户需要人工审批。
三个月以后，为了降低大额交易风险，公司决定修改审批规则如下：
订单金额在2000元以下的，不需要人工审批。
订单金额在2000元以上、10000元以下的，非金卡的客户需要人工审批。
订单金额在2000元以上、10000元以下的，持金卡的客户不需要人工审批。
订单金额在10000元以上的，一律需要人工审批。
．．．．．
还可以有很多变化，不再一一列举，诸位应该明白我的意思了。难道审批规则的每变化一次，都要重新修改，编译、测试、发布？——客户肯定无法接受这个方案。

问题2．如何实现“选择价格最低的供书商”?为了简化问题，我们假设每家供书商都提供查询书价的接口，需求如下：
显然这里有多个供书商可以供你选择，客户的要求是同时向这些供书商发出价格查询，在一定的时间内返回最低价格的供书商获得订单。这里的关键是实现并行查询操作，当然你可以用Thread相关技术来做，至于做的好不好那就很难保证了，你要考虑很多意外情况，某个供书商一直没有返回值怎么办？出现异常怎么办？超过规定时间怎么办？还有，Java多线程编程搞不好就容易发生死锁。

问题3．如何实现“下单给不同的派送公司”?目前的需求是这样的：
四环以内的本来由甲公司负责，四环外的由乙公司负责。
后来由于有些用户抱怨送书时间过长，公司决定与DHL结成战略伙伴关系，规定金卡用户和订单金额在1000元以上的，一律由DHL派送。这里问题的关键是由于派送公司竞争非常激烈，经常会更替不同的派送公司。可以想象，如果跟一个派送公司解除合作关系后，相应的代码改动简直就是一场灾难。
面对以上三个问题，你是否有很好的解决方案，不妨说来听听。
说了半天，还是没说SOA是个啥？别急，今天写累了，留待下回吧。就技术而言，先知道它能干啥，比知道它是啥更重要。等你知道它能干啥后，再反过来看它是啥，印象更深刻。这是我的学习体会，欢迎拍砖。