SOA从诞生之日起，已经被热炒几年。随着行业标准的逐渐完善，越来越多的厂商投入其中，先后推出自己的SOA解决方案，比如Oracle“融合”中间件，IBM中间件，以及多个国内厂商的产品。事实证明，SOA并不一定与高风险、高投入画等号，“经济适用”的SOA显然比价格高昂的厂商产品更能吸引企业的眼球。 　

　　 一、高高在上的SOA

　　SOA（面向服务的架构）是一种优秀的IT架构设计理念，它既满足了企业对敏捷和速度的需要，也适应了业务流程不断变化的现状，让信息系统像电脑硬件一样，可以随时用新“服务”替换过时的旧“服务”。

　　SOA从诞生之日起，已经被热炒几年。随着行业标准的逐渐完善，越来越多的厂商投入其中，先后推出自己的SOA解决方案，比如Oracle“融合”中间件，IBM中间件，以及多个国内厂商的产品。

　　然而，不管各家厂商把SOA概念炒得多火爆，归根到底都是为了推销自家产品，难免有自卖自夸、制造虚假繁荣的嫌疑。否则，既然SOA这么好，为什么市场却“叫好不叫座”呢？

　　究其原因，SOA解决方案的实施难度大、价格成本高、失败风险大，最终让很多企业打了退堂鼓。尽管每次的产品推介会都热闹非凡，客户却是看得多、用得少，真正实施SOA的企业少之又少。

　　或许是高昂的价格、复杂的实施和难以衡量的收益让SOA的“落地”显得举步维艰。毕竟，企业进行信息化建设目的是为了提升效率、节约成本，复杂又昂贵的SOA让企业“想说爱你不容易”，结果只能是无奈的擦肩而过。

　　二、只是“多加一个按钮”？

　　随着竞争的日益激烈，业务部门对信息系统的依赖程度越来越高。然而，市场总是瞬息万变，尤其是在产品生命周期不断缩短、客户需求不断变化的前提下，业务流程的调整已经成为常态，随之而来的是对IT系统的灵活性和应变能力提出了更高的要求。

　　应用系统与业务流程的结合越来越紧密。同时，也由于这种业务相关性，给IT系统的改造和升级带来了不少麻烦。

　　系统改造不比新建，不仅要考虑原有功能的修改，同时也要仔细评估本次修改对其它的功能、模块、甚至其它系统的影响程度，可以说是“牵一发而动全身”。尤其是对那些涉及到基础数据、基本流程、底层系统的变更请求，所需工作量绝不是像业务部门以为的那样——“多加一个按钮”就能解决的问题。

　　如果系统设计不够灵活，很可能会影响到相关的多个功能模块和应用系统，导致多个信息系统被迫进行“伤筋动骨”式的升级改造。

　　业务部门对IT系统的变更请求层出不穷，IT部门的响应速度则显得迟缓而滞后。往往是一个变更请求还没有满足，下一个变更请求已经提出，系统改进的速度远远跟不上需求提出的速度。

　　在这样的情况下，SOA这种面向服务的架构所体现出的“随需应变”的能力，让企业看到了希望。

　　三、“白菜价”实现SOA

　　SOA本身并不拘泥某种特定的实现方式，也不一定非要多么高深的技术，它是脱离于任何具体厂商和产品的思想理念。与其说它是一个解决方案，倒不如说它是一个优秀的设计理念。

　　实现SOA不意味着必须购买谁的产品，接受谁的咨询服务，只要深入理解SOA的设计思想，用很平常的技术手段和开发工具也能实现SOA。那么，如何才能实现“白菜价”的SOA架构呢？

　　我们可以从以下几个方面着手，在尽量不改变现有技术体系和应用系统的基础上，提高IT系统的灵活性，实现对变化的业务需求的敏捷响应。

　　首先，系统功能相对独立

　　每一个应用系统都实现了特定的业务流程，在业务上联系紧密的系统之间相关性自然也高，降低系统间的耦合度首先就要从这里入手。只有在不同的业务系统之间，以及系统内部的各个模块之间，功能上实现有效的“切割”，减少相互间的依赖和影响程度，才能保证相互间的独立性和完整性。

　　企业可以通过整体的IT规划实现业务系统在功能上的相对独立。每个应用系统在建设之前，要首先明确项目的范围和目标，减少与现有系统在功能上的嵌套和叠加。让每个IT系统专注做好自己的事，尽量把业务逻辑封闭在系统内部，减少“被升级”的现象发生。

　　其次，业务流程尽量抽象

　　实际工作中有很多变更请求都与具体的人员调整有关，并不是根本上的业务逻辑改变，比如原来的业务人员离职、或者审批的环节调整。

　　这些请求虽然不大，累积起来工作量也很吓人，而且往往时间要求紧迫，不该过来流程就走不下去。把本来有限的时间浪费在这上面，难怪IT部门没时间响应别的变更请求。

　　在应用系统建设过程中，应该尽量减少类似的人员和逻辑绑定，通过开发特定的功能模块，实现关于人员权限管理、基本业务流程设置和维护等系统管理功能，实现IT 系统与人员和业务逻辑的分离。

　　再次，接口标准化

　　尽管在业务逻辑上尽量保持了系统之间的独立性，但跨部门的流程交叉和接口也是不可避免的。在实现系统交互时，尽量采取通用的、标准化的接口，是降低系统耦合度的方法之一。

　　即使不使用SOA架构下的标准和协议，我们也有许多实现接口的方式可以选择。比如：利用XML文件传输数据、通过Biztalk服务抓取接口文件并进行处理、利用数据库的DTS实现后台数据传输，或者为仅需查询数据的其它系统开放具有只读属性的通用视图，都是很方便实用的方法，大大降低了技术难度和风险。

　　最后，基础架构整合

　　随着企业信息化建设的逐步推进，很多业务人员都面临让人头痛的窘状，一笔业务从开始到结束，可能要在三、四个系统里走不同的流程，繁琐又效率低下。

　　SOA架构下的服务虽然多种多样，但带给用户的体验却是完全透明的。用户看到的是整个业务流程的运转，而不是一个个割裂的服务。
通过部署统一的基础架构，可以把不同的业务应用系统整合成为一个功能完整、流程顺畅的IT系统，实现系统间的整合和流程驱动，避免重复造轮子的浪费。并且，由于内聚高、耦合低，每个系统的内部改造不会或者很少影响其它的应用系统，不但降低了系统修改的难度，也提高了IT部门的相应速度。

　　IT系统的整体规划，信息系统各自在功能和目标上相对独立，大大提升了系统的内聚程度，因此，每个应用系统都可以独立开发，相互之间通过标准接口实现互联互通。独立的模块式开发，给开发过程中的代码/组件重用提供了良好的基础。

　　以上的几方面都不涉及技术体系的切换，对现有应用系统也不必做一次性、大规模的改变，可以在新建应用系统、改进现有系统功能的过程中，循序渐进的结合进面向服务架构的设计思想，最终实现低投入、低风险、“白菜价”的SOA体系。

　　四、SOA架构的魅力

　　企业内部的应用系统越来越多，灵活型却越来越差。IT系统像一头身材巨大的大象，再也踩不出灵活的舞步。

　　在这种情况下，SOA倡导的面向服务的架构成为企业的最佳选择，通过以上方面的努力，不必事事复杂的中间件技术，也能实现敏捷应变的SOA特性。不仅如此，SOA架构本身还具有更多独特的魅力。

　　盘活企业的IT资产

　　只要符合相应的标准，任何服务都可以在SOA架构下连通起来。通过系统功能独立、业务流程抽象、基础架构整合、标准化接口等手段，企业可以把过去投资的信息系统重新整合到新的架构下来，等于节省了重新开发的费用。

　　实现快速响应

　　服务的重复使用和再利用，加快了信息系统相应业务变更请求的速度，缩短了过去需要很长时间才能实现的组织流程重组。IT系统变得“灵动”的同时，也使业务部门能更快速的接近和适应市场。

　　降低变更风险

　　由于高内聚、低耦合的特点，每个业务系统之间互不影响，在对某一个模块进行修改和更新的时候，可以不必影响到其它的业务系统，把系统的变更请求封闭在单个应用系统/模块 内，降低了大面积修改现有系统所带来的风险。

　　促进持续改进

　　业务变动和人员更替是避免不了的，通过SOA架构可以支持持续不断的流程改进，局部的业务改造对整个业务系统的影响比较低，不会造成大面积、高风险的系统更替。可以令IT部门用最少的代价实现对业务变更请求的迅速反应。

　　“后台松散，前台紧致”是SOA架构的特点，也给我们采用经济实惠的技术手段实现SOA架构提供了可能。事实证明，SOA并不一定与高风险、高投入画等号，“经济适用”的SOA显然比价格高昂的厂商产品更能吸引企业的眼球。