面向服务

面向服务第一部分：新方法的商业驱动力第二部分：作为解决方案的面向服务体系结构第三部分：近距离审视面向服务的体系结构第四部分：面向服务的体系结构所带来的好处摘自IBM红皮书《Patterns:Service-OrientedArchitectureandWebServices》(sg246303)第2章第1节MinLuo，MarkEndrei，PhilippeComte，PalKrogdahl，JennyAng，TonyNewlingInternationalTechnicalSupportOrganization，RaleighCenter在这一节中，我们简要地描述了面向服务的体系结构的发展。然后，我们探究了面向组件的开发与面向服务的体系结构之间的关系，并且说明了如何将组件作为实现服务的基础设施。1.1第一部分：新方法的商业驱动力虽然IT经理一直面临着削减成本和最大限度地利用现有技术的难题，但是与此同时，他们还必须不断地努力，以期更好地服务客户，更快地响应企业战略重点，从而赢得更大的竞争力。在所有这些压力之下，有两个基本的主题：异构和改变。现在，大多数企业都有各种各样的系统、应用程序以及不同时期和技术的体系结构。集成来自多个厂商跨不同平台的产品简直就像一场噩梦。但是我们也不能单单使用一家厂商的产品，因为改变应用程序套件和支持基础设施是如此之难。在当今IT经理面临的问题之中，改变是第二个主题。全球化和电子商务加快了改变的步伐。全球化带来了激烈的竞争，产品周期缩短了，每个公司都想赢得超过竞争对手的优势。在竞争产品和可以从Internet上获得的大量产品信息的推动下，客户要求更快速地进行改变。因而，在改进产品和服务方面展开的竞争进一步加剧了。为了满足客户提出的越来越多的新要求，技术方面的改进也在不断地加快。企业必须快速地适应这种改变，否则就难以生存，更别提在这个动荡不安竞争激烈的环境中取得成功了，而IT基础设施必须支持企业提高适应能力。因此，企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业务部门，到上世纪八十年代和九十年代关注业务流程的水平结构，向新的生态系统业务范例发展。重点是扩展供应链，支持客户和合作伙伴访问业务服务。第19页的图2-1展示了企业的这种发展。图2-1企业的发展我如何使我的IT环境更灵活且更快地响应不断改变的业务需求呢？我们如何使这些异构系统和应用程序尽可能无缝地进行通信呢？我们如何达到企业目标而不使企业走向破产的深渊呢？IT响应者/支持者是随着企业的这种发展而并行发展的，如图2-2所示。现在，许多IT经理和专业人员都同样相信，我们真的快找到了一种满意的答案——面向服务的体系结构。图2-2体系结构的发展为了减少异构性、互操作性和不断改变的要求的问题，这样的体系结构应该提供平台来构建具有下列特征的应用程序服务：松散耦合位置透明协议独立基于这样的面向服务的体系结构，服务使用者甚至不必关心与之通信的特定服务，因为底层基础设施或服务“总线”将代表使用者做出适当的选择。基础设施对请求者隐藏了尽可能多的技术。特别地，来自不同实现技术（如J2EE或.NET）的技术规范不应该影响SOA用户。如果已经存在一个服务实现，我们就还应该重新考虑用一个“更好”的服务实现来代替，新的服务实现必须具有更好的服务质量。1.2第二部分：作为解决方案的面向服务体系结构自从“软件危机”促进软件工程的开创以来，IT界一直在努力寻求解决上述问题的方案。在过去几年里，下面简要概述的核心技术进展使我们走到了今天。我们将简要讨论这些核心技术，而我们重点关注的将是这些技术如何帮助解决IT问题。1.2.1面向对象的分析和设计在“ApplyingUMLandPatterns-AnIntroductiontoObject-OrientedAnalysisandDesign”中，Larman将面向对象的分析和设计的本质描述为“从对象（物体、概念或实体）的角度考虑问题域和逻辑解决方案”。在“Object-OrientedSoftwareEngineering：AUseCaseDrivenApproach”中，Jacobson等将这些对象定义为“特点在于具有许多操作和状态（记忆这些操作的影响）的物体”。在面向对象的分析中，这样的对象是用问题域来标识和描述的，而在面向对象的设计中，它们转变成逻辑软件对象，这些对象最终将用面向对象的编程语言进行实现。通过面向对象的分析和设计，可以封装对象（或对象组）的某些方面，以简化复杂业务场景的分析。为了降低复杂性，也可以抽象对象的某些特征，这样就可以只捕获重要或本质的方面。基于组件的设计并不是一种新技术。它是从对象范例中自然发展而来的。在面向对象的分析和设计的早期，细粒度的对象被标榜为提供“重用”的机制，但是这样的对象的粒度级别太低了，没有适当的标准可以用来使重用广泛应用于实践之中。在应用程序开发和系统集成中，粗粒度组件越来越成为重用的目标。这些粗粒度对象通过内聚一些更细粒度的对象来提供定义良好的功能。通过这种方式，还可以将打包的解决方案套件封装成这样的“组件”。一旦组织在更高层次上实现了基于完全独立的功能组件的完备体系结构，就可以将支持企业的应用程序划分成一组粒度越来越大的组件。可以将组件看作是打包、管理和公开服务的机制。它们可以共同使用一组技术：实现企业级用况的大粒度企业组件可以通过更新的面向对象的软件开发与遗留系统相结合来实现1.2.2面向服务的设计在“Component-BasedDevelopmentforEnterpriseSystems”中，Allen涉及了服务的概念，“它是将组件描述成提供相关服务的物理黑盒封装的可执行代码单元。它的服务只能通过一致的已发布接口（它包括交互标准）进行访问。组件必须能够连接到其他组件（通过通信接口）以构成一个更大的组”。服务通常实现为粗粒度的可发现软件实体，它作为单个实例存在，并且通过松散耦合的基于消息通信模型来与应用程序和其他服务交互。第22页的图2-3展示了重要的面向服务术语：服务：逻辑实体，由一个或多个已发布接口定义的契约。服务提供者：实现服务规范软件实体。服务使用者（或请求者）：调用服务提供者的软件实体。传统上，它称为“客户端”。服务使用者可以是终端用户应用程序或另一个服务。服务定位器：一种特殊类型的服务提供者，它作为一个注册中心，允许查找服务提供者接口和服务位置。服务代理：一种特殊类型的服务提供者，它可以将服务请求传送到一个或多个其他的服务提供者。图2-3面向服务的术语1.2.3基于接口的设计在组件和服务开发中，都需要进行接口设计，这样软件实体就可以实现和公开其定义的关键部分。因此，在基于组件和面向服务的系统中，“接口”的概念对于成功的设计非常关键。下面是一些与接口有关的重要定义：接口：定义一组公共方法签名，它按照逻辑分组但是没有提供实现。接口定义服务的请求者和提供者之间的契约。接口的任何实现都必须提供所有的方法。已发布接口：一种可唯一识别和可访问的接口，客户端可以通过注册中心来发现它。公共接口：一种可访问的接口，可供客户端使用，但是它没有发布，因而需要关于客户端部分的静态知识。双接口：通常是成对开发的接口，这样，一个接口就依赖于另一个接口；例如，客户端必须实现一个接口来调用请求者，因为该客户端接口提供了某些回调机制。第23页的图2-4定义了客户关系管理(CRM)服务的UML定义，它表示为一个UML组件，实现接口AccountManagement、ContactManagement和SystemsManagement。在这些接口中只有头两个接口是已发布接口，不过，后者是公共接口。注意，SystemsManagement接口和ManagementService接口构成了双接口。CRMservice可以实现许多这样的接口，但是它以多种方式行为的能力取决于客户端在行为的实现方面是否允许有大的灵活性。甚至有可能给特定类型的客户端提供不同或附加的服务。在一些运行时环境中，这样的功能也用于在单个组件或服务上支持相同接口的不同版本。图2-4已实现的服务1.2.4分层应用程序体系结构如前所述，面向对象的技术和语言是实现组件的极好方式。虽然组件是实现服务的最好方法，但是您必须理解的一点是，好的基于组件的应用程序未必就构成好的面向服务的应用程序。一旦理解了服务在应用程序体系结构中所起的作用，组件开发人员就很有可能会利用现有的组件。进行这种转变的关键是认识到面向服务的方法意味着附加的应用程序体系结构层。第24页中的图2-5演示了如何将技术层应用于程序体系结构以提供粒度更粗的实现（它更靠近应用程序的使用者）。为称呼系统的这一部分而创造的术语是“应用程序边界”，它反映了服务是公开系统的外部视图的极好方法的事实（通过内部重用并结合使用传统组件设计）。图2-5应用程序实现层：服务、组件、对象1.3第三部分：近距离审视面向服务的体系结构面向服务的体系结构提供了一种方法，通过这种方法，可以构建分布式系统来将应用程序功能作为服务提供给终端用户应用程序或其他服务。其组成元素可以分成功能元素和服务质量元素。第25页的图2-6展示了体系结构堆栈以及在一个面向服务的体系结构可能观察到的元素。图2-6面向服务的体系结构的元素注意：面向服务的体系结构堆栈可能是一个容易引起争议的问题，因为各方面的支持者已经提出了几种不同的堆栈。我们的堆栈不是作为服务堆栈提出的。我们之所以在此提出它，是因为我们想要搭建一个有用的框架，在本书的剩余章节中，我们将通过这个框架来组织对SOA的讨论。体系结构堆栈分成两半，左边的一半集中于体系结构的功能性方面，而右边的一半集中于体系结构的服务质量方面。这些元素详细描述如下：功能性方面包括：传输是一种机制，用于将来自服务使用者的服务请求传送给服务提供者，并且将来自服务提供者的响应传送给服务使用者。服务通信协议是一种经过协商的机制，通过这种机制，服务提供者和服务使用者可以就将要请求的内容和将要返回的内容进行沟通。服务描述是一种经过协商的模式，用于描述服务是什么、应该如何调用服务以及成功地调用服务需要什么数据。服务描述实际可供使用的服务。业务流程是一个服务的集合，可以按照特定的顺序并使用一组特定的规则进行调用，以满足业务要求。注意，可以将业务流程本身看作是服务，这样就产生了业务流程可以由不同粒度的服务组成的观念。服务注册中心是一个服务和数据描述的存储库，服务提供者可以通过服务注册中心发布它们的服务，而服务使用者可以通过服务注册中心发现或查找可用的服务。服务注册中心可以给需要集中式存储库的服务提供其他的功能。服务质量方面包括：策略是一组条件和规则，在这些条件和规则之下，服务提供者可以使服务可用于使用者。策略既有功能性方面，也有与服务质量有关的方面；因此，我们在功能和服务质量两个区中都有策略功能。安全性是规则集，可以应用于调用服务的服务使用者的身份验证、授权和访问控制。传输是属性集，可以应用于一组服务，以提供一致的结果。例如，如果要使用一组服务来完成一项业务功能，则所有的服务必须都完成，或者没有一个完成。管理是属性集，可以应用于管理提供的服务或使用的服务。1.3.1SOA协作图2-7展示了面向服务的体系结构中的协作。这些协作遵循“查找、绑定和调用”范例，其中，服务使用者执行动态服务定位，方法是查询服务注册中心来查找与其标准匹配的服务。如果服务存在，注册中心就给使用者提供接口契约和服务的端点地址。下图展示了面向服务的体系结构中协作支持“查找、绑定和调用”范例的实体。图2-7面向服务的体系结构中的协作面向服务的体系结构中的角色包括：服务使用者：服务使用者是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。服务使用者根据接口契约来执行服务。服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现和访问该服