--企业架构师能从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提供了一个能适应多类硬件、操作系统、中间件、语言和数据存储的抽象层，在许多情况下，企业架构师在不了解每个组件的情况下也能够集成这些多样性组件。