某公司面向服务培训教程.docx

《某公司面向服务培训教程.docx》由会员分享，可在线阅读，更多相关《某公司面向服务培训教程.docx（14页珍藏版）》请在第一文库网上搜索。

1、某公司面向服务培训教程面向服务第一部分:新方法的商业驱动力第二部分:作为解决方案的面向服务体系结构第三部分:近距离审视面向服务的体系结构第四部分:面向服务的体系结构所带来的好处摘自IBM红皮书Patterns:Service-OrientedArchitectureandWebServices(sg246303)第2章第1节Min1uo,MarkEndrei,Phi1ippeComte,Pa1Krogdah1JennyAng,TonyNew1ingInternationa1Technica1SupportOrganization,Ra1eighCenter在这一节中，我们简要地描述了面向服务的

2、体系结构的进展。然后，我们探究了面向组件的开发与面向服务的体系结构之间的关系，同时说明了如何将组件作为实现服务的基础设施。1.1第一部分：新方法的商业驱动力尽管IT经理一直面临着削减成本与最大限度地利用现有技术的难题，但是与此同时，他们还务必不断地努力，以期更好地服务客户，更快地响应企业战略重点，从而赢得更大的竞争力。在所有这些压力之下，有两个基本的主题：异构与改变。现在，大多数企业都有各类各样的系统、应用程序与不一致时期与技术的体系结构。集成来自多个厂商跨不一致平台的产品简直就像一场噩梦。但是我们也不能单单使用一家厂商的产品，由于改变应用程序套件与支持基础设施是如此之难。在当今IT经理面临的

3、问题之中，改变是第二个主题。全球化与电子商务加快了改变的步伐。全球化带来了猛烈的竞争，产品周期缩短了，每个公司都想赢得超过竞争对手的优势。在竞争产品与能够从Internet上获得的大量产品信息的推动下，客户要求更快速地进行改变。因而，在改进产品与服务方面展开的竞争进一步加剧了。为了满足客户提出的越来越多的新要求，技术方面的改进也在不断地加快。企业务必快速地习惯这种改变，否则就难以生存，更别提在这个动荡不安竞争猛烈的环境中取得成功了，而IT基础设施务必支持企业提高习惯能力。因此，企业组织正在从上世纪八十年代或者更早的时期的相互隔离的垂直业务部门，到上世纪八十年代与九十年代关注业务流程的水平结构，

4、向新的生态系统业务范例进展。重点是扩展供应链，支持客户与合作伙伴访问业务服务。第19页的图2-1展示了企业的这种进展。图2-1企业的进展我如何使我的IT环境更灵活且更快地响应不断改变的业务需求呢？我们如何使这些异构系统与应用程序尽可能无缝地进行通信呢？我们如何达到企业目标而不使企业走向破产的深渊呢？IT响应者/支持者是随着企业的这种进展而并行进展的，如图2-2所示。现在，许多IT经理与专业人员都同样相信，我们确实快找到了一种满意的答案一一面向服务的体系结构。图2-2体系结构的进展为了减少异构性、互操作性与不断改变的要求的问题，这样的体系结构应该提供平台来构建具有下列特征的应用程序服务： 松散耦

5、合 位置透明 协议独立基于这样的面向服务的体系结构，服务使用者甚至不必关心与之通信的特定服务，由于底层基础设施或者服务“总线”将代表使用者做出适当的选择。基础设施对请求者隐藏了尽可能多的技术。特别地，来自不一致实现技术（如J2EE或者.NET）的技术规范不应该影响SOA用户。假如已经存在一个服务实现，我们就还应该重新考虑用一个“更好”的服务实现来代替，新的服务实现务必具有更好的服务质量。1.2 第二部分：作为解决方案的面向服务体系结构自从“软件危机”促进软件工程的开创以来，IT界一直在努力寻求解决上述问题的方案。在过去几年里，下面简要概述的核心技术进展使我们走到了今天。我们将简要讨论这些核心技

6、术，而我们重点关注的将是这些技术如何帮助解决IT问题。1.2.1 面向对象的分析与设计在aApp1yingUM1andPatterns-AnIntroductiontoObject-OrientedAna1ysisandDesign,中，1arman将面向对象的分析与设计的本质描述为“从对象（物体、概念或者实体）的角度考虑问题域与逻辑解决方案”。在“Object-OrientedSoftwareEngineering：AUSeCaSeDriVenAPPrOaCh”中，Jacobson等将这些对象定义为“特点在于具有许多操作与状态（经历这些操作的影响）的物体”。在面向对象的分析中，这样的对象是用

7、问题域来标识与描述的，而在面向对象的设计中，它们转变成逻辑软件对象，这些对象最终将用面向对象的编程语言进行实现。通过面向对象的分析与设计，能够封装对象（或者对象组）的某些方面，以简化复杂业务场景的分析。为了降低复杂性，也能够抽象对象的某些特征，这样就能够只捕获重要或者本质的方面。基于组件的设计并不是一种新技术。它是从对象范例中自然进展而来的。在面向对象的分析与设计的早期，细粒度的对象被标榜为提供“重用”的机制，但是这样的对象的粒度级别太低了，没有适当的标准能够用来使重用广泛应用于实践之中。在应用程序开发与系统集成中，粗粒度组件越来越成为重用的目标。这些粗粒度对象通过内聚一些更细粒度的对象来提供

8、定义良好的功能。通过这种方式，还能够将打包的解决方案套件封装成这样的“组件”。一旦组织在更高层次上实现了基于完全独立的功能组件的完备体系结构,就能够将支持企业的应用程序划分成一组粒度越来越大的组件。能够将组件看作是打包、管理与公开服务的机制。它们能够共同使用一组技术：实现企业级用况的大粒度企业组件能够通过更新的面向对象的软件开发与遗留系统相结合来实现1.2.2 面向服务的设计在Component-BasedDeve1opmentforEnterpriseSystems,中，A11en涉及了服务的概念，“它是将组件描述成提供有关服务的物理黑盒封装的可执行代码单元。它的服务只能通过一致的已公布接口

9、（它包含交互标准）进行访问。组件务必能够连接到其他组件（通过通信接口）以构成一个更大的组，服务通常实现为粗粒度的可发现软件实体，它作为单个实例存在，同时通过松散耦合的基于消息通信模型来与应用程序与其他服务交互。第22页的图2-3展示了重要的面向服务术语：服务：逻辑实体，由一个或者多个已公布接口定义的契约。服务提供者：实现服务规范软件实体。服务使用者（或者请求者）：调用服务提供者的软件实体。传统上，它称之“客户端工服务使用者能够是终端用户应用程序或者另一个服务。服务定位器：一种特殊类型的服务提供者，它作为一个注册中心，同意查找服务提供者接口与服务位置。服务代理：一种特殊类型的服务提供者，它能够将

10、服务请求传送到一个或者多个其他的服务提供者。图2-3面向服务的术语1.2.3 基于接口的设计在组件与服务开发中，都需要进行接口设计，这样软件实体就能够实现与公开其定义的关键部分。因此，在基于组件与面向服务的系统中，“接口”的概念关于成功的设计非常关键。下面是一些与接口有关的重要定义：接口：定义一组公共方法签名，它按照逻辑分组但是没有提供实现。接口定义服务的请求者与提供者之间的契约。接口的任何实现都务必提供所有的方法。已公布接口：一种可唯一识别与可访问的接口，客户端能够通过注册中心来发现它。公共接口：一种可访问的接口，可供客户端使用，但是它没有公布，因而需要关于客户端部分的静态知识。双接口：通常

11、是成对开发的接口，这样，一个接口就依靠于另一个接口；比如，客户端务必实现一个接口来调用请求者，由于该客户端接口提供了某些回调机制。第23页的图2-4定义了客户关系管理(CRM)服务的UM1定义，它表示为一个UM1组件，实现接口AccountManagementContactManagement与SystemsManagemento在这些接口中只有头两个接口是已公布接口，只是，后者是公共接口。注意，SystemsManagemen1接口与ManagementService接口构成了双接口。CRMservice能够实现许多这样的接口，但是它以多种方式行为的能力取决于客户端在行为的实现方面是否同意有

12、大的灵活性。甚至有可能给特定类型的客户端提供不一致或者附加的服务。在一些运行时环境中，这样的功能也用于在单个组件或者服务上支持相同接口的不一致版本。图2.4已实现的服务1.2.4 分层应用程序体系结构如前所述，面向对象的技术与语言是实现组件的极好方式。尽管组件是实现服务的最好方法，但是您务必懂得的一点是，好的基于组件的应用程序未必就构成好的面向服务的应用程序。一旦懂得了服务在应用程序体系结构中所起的作用，组件开发人员就很有可能会利用现有的组件。进行这种转变的关键是认识到面向服务的方法意味着附加的应用程序体系结构层。第24页中的图2-5演示了如何将技术层应用于程序体系结构以提供粒度更粗的实现（它

13、更靠近应用程序的使用者）。为称呼系统的这一部分而制造的术语是“应用程序边界”，它反映了服务是公开系统的外部视图的极好方法的事实（通过内部重用并结合使用传统组件设计）O图2-5应用程序实现层：服务、组件、对象ICM31Service1ayerDsComponent1ayerObjectZCIass1ayer1.3 第三部分：近距离审视面向服务的体系结构面向服务的体系结构提供了一种方法，通过这种方法，能够构建分布式系统来将应用程序功能作为服务提供给终端用户应用程序或者其他服务。其构成元素能够分成功能元素与服务质量元素。第25页的图2-6展示了体系结构堆栈与在一个面向服务的体系结构可能观察到的元素。

14、图2.6面向服务的体系结构的元素FunctionsBusinessProcessServiceServiceDescriptionServiceCommunicationProto1TransportQua1ityofServiceUoqOeSU1uE6eue行注意：面向服务的体系结构堆栈可能是一个容易引起争议的问题，由于各方面的支持者已经提出了几种不一致的堆栈。我们的堆栈不是作为服务堆栈提出的。我们之因此在此提出它，是由于我们想要搭建一个有用的框架，在本书的剩余章节中，我们将通过这个框架来组织对SOA的讨论。体系结构堆栈分成两半，左边的一半集中于体系结构的功能性方面，而右边的一半集中于体系结

15、构的服务质量方面。这些元素全面描述如下：功能性方面包含： 传输是一种机制，用于将来自服务使用者的服务请求传送给服务提供者，同时将来自服务提供者的响应传送给服务使用者。 服务通信协议是一种通过协商的机制，通过这种机制，服务提供者与服务使用者能够就将要请求的内容与将要返回的内容进行沟通。 服务描述是一种通过协商的模式，用于描述服务是什么、应该如何调用服务与成功地调用服务需要什么数据。 服务描述实际可供使用的服务。 业务流程是一个服务的集合，能够按照特定的顺序并使用一组特定的规则进行调用，以满足业务要求。注意，能够将业务流程本身看作是服务,这样就产生了业务流程能够由不一致粒度的服务构成的观念。 服务注册中心是一个服务与数据描述的存储库，服务提供者能够通过服务注册中心公布它们的服务，而服务使用者能够通过服务注册中心发现或者查找可用的服务。服务注册中心能够给需要集中式存储库的服务提供其他的功能。服务质量方面包含： 策略是一组条件与规则，在这些条件与规则之下，服务提供者能够使服务可用于使用者。策略既有功能性方面，也有与服务质量有关的方面；因此，我们在功能与服务质量两个区中都有策略功能。 安全性是规则集，能够应用于调用服务的服务使用者的身份验证、授权与访问操纵。 传输是属性集，能够应用于一组服务，以提供一致的结果。比如，假如要使用一组服务来完成一项业务功能，