软件测试SOA and Web services 新手入门 SOA架构
关键字：SOA 或许已经有人告诉您，您公司的新 IT 策略将要涉及到创建一个基于面向服务的体系结构的系统。也许您已经听到了大量的长篇大论，正想知道面向服务的体系结构（Service-Oriented Architecture，SOA）是否适合您的业务。或许您正在经历一场集成噩梦，尝试寻找让很多不同的系统彼此进行通信的方法。不管是何种情况，您都可能希望找到让 IT 基础设施为业务服务的方法，而不是其他。无论您是刚刚接触面向服务的体系结构这一概念，还是已经涉足其中，您肯定都希望找到方法来提高实现的效率，“developerWorks SOA 新手入门” 部分将为您提供了解和着手使用 SOA 所需的资源。
Back to top
什么是 SOA？
我们可能应该回答的第一个问题也是最基本的问题。什么是面向服务的体系结构(Service-Oriented Architecture, SOA)？这个问题的答案实际上涉及与开发相关的若干不同方面。
SOA 是一种 IT 体系结构样式，支持将您的业务作为链接服务或可重复业务任务进行集成，可在需要时通过网络访问这些服务和任务。这个网络可能完全包含在您的公司总部内，也可能分散于各地且采用不同的技术，通过对来自纽约、伦敦和香港的服务进行组合，可让最终用户感觉似乎这些服务就安装在本地桌面上一样。需要时，这些服务可以将自己组装为按需应用程序——即相互连接的服务提供者和使用者集合，彼此结合以完成特定业务任务，使您的业务能够适应不断变化的情况和需求（在有些情况下，甚至不需要人工干预）。
这些服务是自包含的，具有定义良好的接口，允许这些服务的用户——称为客户机或使用者——了解如何与其进行交互。从技术角度而言，SOA 带来了“松散耦合”的应用程序组件，在此类组件中，代码不一定绑定到某个特定的数据库（甚至不一定绑定到特定的基础设施）。正是得益于这个松散耦合特性，才使得能够将服务组合为各种应用程序。这样还大幅度提高了代码重用率，可以在增加功能的同时减少工作量。由于服务和访问服务的客户机并未彼此绑定，因此可以完全替换用于处理订单的服务，下订单的客户机-服务将永远不会知道这个更改。所有交互都是基于“服务契约”进行的；服务契约用于定义服务提供者和客户机之间的交互。通常，您将通过创建“基于消息的”系统来实现此目标。
从业务的角度来说，面向服务的体系结构的重点在于开发能帮助您完成业务任务的技术，而不是通过技术约束来规定您的行动。例如，销售过程（制造、运输和收到货款）可能会涉及数十个步骤和若干不同的数据库和计算机系统。但就其实质而言，此过程包含一系列人工活动，例如：
销售人员找到潜在客户 客户订购产品 生产部门制造产品 生产部门发出产品 收款部门开具产品帐单 客户支付产品货款 面向服务的体系结构基于这些实际活动或业务服务进行组织，而不是形成公司所维护的不同的信息竖井 (Silo)。通过实现 SOA，可以带来大量好处，包括以下各个方面：
更高的业务和 IT 一致性 基于组件的系统 松散耦合的组件和系统 基于网络的基础设施，允许分散于各地且采用不同技术的资源协同工作 动态构建的按需应用程序 更高的代码重用率 更好地标准化整个企业内的流程 更易于集中企业控制 下面提供了一些有用的资源，可帮助您了解面向服务的体系结构的总体概念： IBM vision of Service-Oriented Architecture——了解 SOA 如何帮助您应对当今不断变化的业务环境中固有的业务挑战和 IT 需求 迁移到面向服务的体系结构，第 1 部分 和 第 2 部分——制订实际计划，评估当前的基础设施，并将其迁移到真正的 SOA
体系结构
Web 服务是用于实现 SOA 的最常见技术标准。不过，这并不是可以用于开发 SOA 的各个部分的唯一技术。很多 SOA——实际上是大部分——都涉及到集成遗留数据，此类数据包含在使用 MQSeries 和 Common Object Request Broker Architecture (CORBA) 等技术的系统中。其中的许多技术都已针对 SOA 进行了调整，不管有无 Web 服务包装均可使用。事实上，可以仅使用 MQSeries、CORBA 甚至远程过程调用（Remote Procedure Call，RPC）技术来实现 SOA。但 Web 服务正迅速成为用于支持 SOA 的事实标准。
文章来源于领测软件测试网 https://www.ltesting.net/
