“白菜价”实现经济适用SOA解决方案

其次，业务流程尽量抽象

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

这些请求虽然不大，累积起来工作量也很吓人，而且往往时间要求紧迫，不该过来流程就走不下去。把本来有限的时间浪费在这上面，难怪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显然比价格高昂的厂商产品更能吸引企业的眼球。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友