软件质量保证SOA如何使开发人员受益 软件质量保证
关键字：SOA 开发
企业架构师能从SOA中受益，开发人员同样能从SOA中受益。有5个原因说明开发人员与SOA关系密切。
难于解决的问题
现有的应用架构已经无法跟上不断改变的业务模型的步伐了。企业不仅在努力开发内部新应用程序，而且努力把他们的应用程序与合作伙伴、供应商、客户集成到一起，但是他们面临的是单一的、紧耦合的应用程序的限制，在编译和运行时，每个子系统和其他子系统紧密联系在一起。不仅在一个系统中的改变会造成另一个运行的失败，而且还使开发人员陷入反复无穷尽的编码、编译、测试的循环中。开发人员也必须处理渐增的异构环境，每个环境中应用程序运用了一套新的需要学习和连接的API。
早期解决跨异构平台集成应用程序的方法(例如CORBA)没有实现它们的承诺，一部分是因为在对象模型中缺乏标准化，另一部分是因为甚至CORBA没有想到需要考虑能快速开发、集成、重用应用程序的一个更为松散耦合的方法。
在这种背景下，面向服务的架构可以看成是应用程序架构开发的下一个革命性步骤，一个用模块化和松耦合应用程序取代单一、紧耦合应用程序的革命。
SOA使用了一种模块化的方法，其中每个组合或虚拟的应用程序是用来自独立应用程序的许多不同分离服务组合而成的。服务能存在于网络的任何地方，可以通过公共和私有注册表用标准的接口去发现和使用它们。可以通过将主要功能作为服务而公开，从现有应用程序中获得服务，也可以从新的面向服务的应用程序中获得服务。
虽然SOA可以充分利用诸如XML、UDDI、SOAP、WSDL和基于Java消息的技术，但是与CORBA不同，它本身不是一项技术。它是一个全新的思想倾向和结构方法，用来满足企业应用架构中灵活性的需要。
面向对象的开发既是一种成功，也是一种牺牲。随着企业软件开发的发展，面向对象的语言(特别是Java)、方法和框架现在都能很好的被理解。表面上看来，决定是用面向对象的方法还是用面向服务的方法取决于您开发的软件和与之交互的其他软件之间的耦合松紧度。一般人的看法是，面向对象的开发适合于紧耦合的集成，然而SOA适合松散耦合的集成，虽然这种看法一般是正确的，但是它太过于简单了。它不是选择用一个或者其他一个的问题。就像许多新的开发工具建议的那样，为了完成令他们伤脑筋的企业应用程序，开发人员需要理解两者。
SOA不会取代面向对象的开发，面向对象的开发将仍然保持开发单独应用程序的统治地位。但是随着这些架构和框架继续被改进和维护，将会真正的产生一种能支持生态系统(由协作应用程序组成)的基础结构。不管这些应用程序是不是面向对象的，SOA都能扩充它们，通过提供普遍的、可重用的业务级接口而不是组件级的接口，SOA有助于开发人员完成这种扩充。
此外，SOA要求一个实例能从客户/服务器方法转移到考虑事件驱动交互的应用程序开发中去。因为服务可以作为一个业务过程插入到任何地方，开发人员必须对应用程序开发有整体上的把握。主要的不同就在于接口是如何设计的。在SOA中，关键是开发粗粒度并且不是基于应用程序的组件架构的接口。所以，在SOA环境下的应用程序开发、集成、重用和业务过程建模、工作流、程序到程序的通信相吻合。
Carrot
文章来源于领测软件测试网 https://www.ltesting.net/
