为何不让软件测试SOA变得简单？[2]

关键字：soa

　　我的观点是，SOA对不同的需求需要不同对待。在本文中，我只关心J2EE架构方面的SOA，而我认为这意味着功能重用。其他从J2EE观点来看SOA的优点还有：

　　1、松耦合的组件，这是软件设计中重要的部分

　　2、引入ESB作为消息层意味着强制“面向接口编程，而不是实现”

　　3、异步消息增加了应用的伸缩性

　　让我们通过问三个特定的问题来看一下软件重用中更细节的问题：

　　1、为什么重用软件是重要的?

　　2、SOA是如何提出解决软件重用问题的?

　　3、是否SOA的允诺能够使软件重用应用到现实中?

　　首先，软件重用是重要的原因如下：

　　1、时间和花费上的效率—能够重用已经的组件来满足陈述的业务需求将节省大量的时间和金钱。

　　2、重要的特性包括但不限于如稳定性/性能/可管理性/文档/可配置性。因为一个组件被重用的次数越多，对这个组件的投资也越多，他的优势也越多。

　　3、 良好设计的可重用框架无论在哪里被使用都拥有正面的效果，而且你愿意的话可以封装更好的想法来解决通用问题。

　　因此我们需要重用性。那么最简单的方法是什么呢?就是打包软件作为一组良好定义的组件来满足离散的功能需求。然后，如果其他应用需要相同的组件，他就可以重用了。还有些细节需要考虑，如如何配置，但这些细节已经偏离了主题：重用任何语言编写的代码，那些代码必须被设计成一组离散的组件或重构为集合。

　　其次，SOA是如何解决软件重用的问题呢?是通过基于组件模型来构建和引入一个重要的强制约定：组件间的通讯要通过下发到ESB的消息来进行，而这就确保了松耦合。实际上，最广泛布署的SOA实现—Web services可以通过使消息层技术中性来缝合用不同语言开发的组件。

　　最后，SOA对软件重用的允诺真有实际意义吗?不，我想念如果SOA在1945(大概是和ENIAC同时代吧)被发明的话确实可以解决软件重用的问题。但没有，现存的大量代码是用不同的开发语言编写的，有COBOL/C/C++/C#和其他语言。这些代码没有作为离散的组件来编写，因此也没有SOA来解决。事实上，我认为有大量的SOA项目的工作是花费在重构相同的代码库。

原文转自：http://www.ltesting.net