--企业架构师能从SOA中受益，开发人员同样能从SOA中受益。有5个原因说明开发人员与SOA关系密切。
难于解决的问题
现有的应用架构已经无法跟上不断改变的业务模型的步伐了。企业不仅在努力开发内部新应用程序，而且努力把他们的应用程序与合作伙伴、供应商、客户集成到一起，但是他们面临的是单一的、紧耦合的应用程序的限制，在编译和运行时，每个子系统和其他子系统紧密联系在一起。不仅在一个系统中的改变会造成另一个运行的失败，而且还使开发人员陷入反复无穷尽的编码、编译、测试的循环中。开发人员也必须处理渐增的异构环境，每个环境中应用程序运用了一套新的需要学习和连接的API。
早期解决跨异构平台集成应用程序的方法（例如CORBA）没有实现它们的承诺，一部分是因为在对象模型中缺乏标准化，另一部分是因为甚至CORBA没有想到需要考虑能快速开发、集成、重用应用程序的一个更为松散耦合的方法。
在这种背景下，面向服务的架构可以看成是应用程序架构开发的下一个革命性步骤，一个用模块化和松耦合应用程序取代单一、紧耦合应用程序的革命。
SOA使用了一种模块化的方法，其中每个组合或虚拟的应用程序是用来自独立应用程序的许多不同分离服务组合而成的。服务能存在于网络的任何地方，可以通过公共和私有注册表用标准的接口去发现和使用它们。可以通过将主要功能作为服务而公开，从现有应用程序中获得服务，也可以从新的面向服务的应用程序中获得服务。
虽然SOA可以充分利用诸如XML、UDDI、SOAP、WSDL和基于Java消息的技术，但是与CORBA不同，它本身不是一项技术。它是一个全新的思想倾向和结构方法，用来满足企业应用架构中灵活性的需要。
面向对象的开发既是一种成功，也是一种牺牲。随着企业软件开发的发展，面向对象的语言（特别是Java）、方法和框架现在都能很好的被理解。表面上看来，决定是用面向对象的方法还是用面向服务的方法取决于您开发的软件和与之交互的其他软件之间的耦合松紧度。一般人的看法是，面向对象的开发适合于紧耦合的集成，然而SOA适合松散耦合的集成，虽然这种看法一般是正确的，但是它太过于简单了。它不是选择用一个或者其他一个的问题。就像许多新的开发工具建议的那样，为了完成令他们伤脑筋的企业应用程序，开发人员需要理解两者。
SOA不会取代面向对象的开发，面向对象的开发将仍然保持开发单独应用程序的统治地位。但是随着这些架构和框架继续被改进和维护，将会真正的产生一种能支持生态系统（由协作应用程序组成）的基础结构。不管这些应用程序是不是面向对象的，SOA都能扩充它们，通过提供普遍的、可重用的业务级接口而不是组件级的接口，SOA有助于开发人员完成这种扩充。
此外，SOA要求一个实例能从客户/服务器方法转移到考虑事件驱动交互的应用程序开发中去。因为服务可以作为一个业务过程插入到任何地方，开发人员必须对应用程序开发有整体上的把握。主要的不同就在于接口是如何设计的。在SOA中，关键是开发粗粒度并且不是基于应用程序的组件架构的接口。所以，在SOA环境下的应用程序开发、集成、重用和业务过程建模、工作流、程序到程序的通信相吻合。
Carrot
协作应用程序的新世界使开发人员的角色朝更好的方向改变。它在相当大的程度上提高了组织中开发人员的价值，这是因为他们不用在一个特别的基础上再去组装单个应用程序或处理应用程序集成，而是负责给整个业务定义一个架构。企业构架师比一般意义上的开发人员的角色更关键。为了有利于一个新的应用程序，单个工程可能会被取消，开发投入大量个人经验开发的应用程序可能会被清除。但是所有的企业承认他们需要一个可伸缩的、适应性强的基础结构，这个结构可以不影响已有的业务而按照需要添加新的应用程序，他们也在求助于技术专家开发这种结构方法。
SOA给开始用服务构建应用程序的开发人员带来了许多益处。
松耦合
如果您根据由通信服务组成的光纤想一想SOA，很容易会发现松散耦合是如何减少在一个服务中修改代码也会要求在另外一个服务中修改代码的机率。在这种情况中光纤可以看成是总的应用程序。如果使用传统应用程序中的步骤将这些服务硬编码在一起，则更改一个步骤就像在一个真实的光纤上拉一根线一样。结果整个光纤将会坏掉。利用SOA，就能够大批的迁移或者取代单个的服务而不影响总的组合应用程序。
位置透明性
想一下关于从客户/服务器模式转移到事件驱动模型我们说了什么？在事件驱动模型中，服务的消费者无需知道服务位于网络哪个地方。SOA中的服务在注册表中已经注册。这个注册表可能是数据库、目录服务、UDDI注册表或者XML文件，它能很容易地被客户端应用程序定位。所有注册和发现都由SOA处理，所以开发人员可以集中精力去解决业务问题。
事实上，这种位置透明性是让Web服务工作的一个必不可少的部分。以这种方式把应用程序开发和部署分开使得企业能灵活地把服务迁移到不同的服务器中，而不需要考虑那样会如何影响客户端应用程序，它也使得开发人员满足了业务可用性、符合服务级别和可伸缩性的要求。
代码重用
开发人员会怀疑是否有能达到代码真正重用的切实可行的办法，这是可以原谅的。自从过程化语言让位于面向对象的开发，我们一直期待着将来应用程序的开发是一种Lego积木方式的简单插拔对象方式。虽然面向对象的框架在普通环境中有一些成功，但是使它们穿过异构平台工作的困难一直使人畏缩，主要是因为缺乏标准化和一种易理解的公开描述方法的方式。
我们还没有达到那样的程度，但是SOA实际上可以通过用UDDI在注册表中列出服务和公开WSDL文档中方法（包括参数和类型），使开发人员从代码重用中受益成为可能。
每次开发人员要集成新的应用程序时，他们不需要重新开发。不需要修改现有应用程序就能达到新的功能。
通用服务
通用服务将取代硬编码集成，这使得开发人员能够将精力集中于总体解决方案和更高级别的策略实现。例如，企业软件的通用方面（如可靠传递和智能路由）将由基础结构本身作为服务提供，无需开发人员再为这些功能编写代码。
平台独立性
SOA提供了一个能适应多类硬件、操作系统、中间件、语言和数据存储的抽象层，在许多情况下，企业架构师在不了解每个组件的情况下也能够集成这些多样性组件。
文章来源于领测软件测试网 https://www.ltesting.net/
