使用IBM面向服务的体系结构（Service-Oriented Architecture，SOA）基础生命周期在软件开发上下文中讨论SOA。体系结构实践 专栏的本部分将重点讨论SOA场景中的第一个场景，服务创建场景。探究SOA中的三个主要服务来源，以及为恰当使用相关服务提供指导的体系结构模式。熟悉各个模式及 SOA 生命周期中的各种活动，并了解用于实现和实例化这些模式的IBM产品的常用建议。

　　引言

　　体系结构实践 专栏文章的第1部分“理解面向服务的体系结构”讨论了IBM的面向服务的体系结构(SOA)基础生命周期（或SOA生命周期），以及其如何允许IBM客户从软件开发生命周期的角度来看待SOA。其中详细讨论了IBM SOA生命周期的四个阶段——建模、组装、部署和管理。

　　本文（第4部分）重点讨论八个场景中的第一个场景：服务创建场景，可帮助您了解SOA如何帮助解决典型的业务挑战。本文将讨论不同的服务创建选项背后的基本原理，并将给出各个选项最相关和最适用的情况。对于每个服务创建选项，文章中会将其与SOA生命周期中各个阶段的高级活动对应起来。另外还将包括有关可用于实现生命周期每个阶段的活动的一个或多个IBM产品和工具的建议。

　　处理业务挑战

　　快速而有效地实现业务计划是大部分组织都必须处理的一项主要业务挑战。企业必须能够认识各种市场情况并快速地调整其战略，以反映变化。为了获得这种灵活的业务模型，需要有同样灵活的IT基础设施作为支持。SOA中的服务 定义为自包含的可重用软件模块，用于执行特定业务任务。现在将这些服务作为基础软件构建块使用，以提供灵活的IT解决方案。服务具有定义良好的接口，独立于其运行的应用程序和计算平台。在现在的环境中，必须了解您的业务及流程（作为一组相互联系的可重复业务任务执行，可以将这些业务任务方便地进行重新排列）。

　　您的组织需要一种机制来为增值投资（提供独有功能的任务）分配资源。您需要将资源集中在能给业务带来突出优势和价值的投资上，而不用担心经常出现的低价值琐事级的任务。

　　您还会希望业务能够稳定地增长。您需要确保自己了解和信任的业务系统具有良好的性能和可靠性，同时与值得信赖的业务合作伙伴和服务提供商合作，以便获得您所需要的服务。而且，如果选择收购某个企业，则必须能够将其业务系统与您的系统集成，以确保快速形成统一体。

　　一个不错的着手点是将业务已有的东西 与业务所需的东西 进行比较。建模现有业务流程和未来业务模型，并模拟其功能和效果，从而提供关于业务应该如何运行的参考框架。然后考虑组成业务流程的各个任务应该如何完成的问题。每个任务都需要由服务提供支持。通过SOA可以将这些服务连接为灵活的模块化系统，从而为灵活业务模型提供支持。确定服务来自何处是实现优化业务流程远景的第一步。

　　服务创建场景的访问模式

　　IBM确定了SOA中服务的三个主要来源，如图1中所示。

　　图1. 三个服务来源
 
　　四个常用体系结构模式提供了相关指南，说明了关于如何恰当地使用三个主要来源提供的服务创建基于服务的IT解决方案。建议的方法是将需要的东西与已有的东西进行比较。可以自己从头创建服务、购买服务或使用现有的支持服务的打包软件或自定义软件。可以通过以下方式利用所有三个类别的服务：

　　·现有应用程序和资产中的现成高价值软件应用程序和系统支持的服务启用任务。
　　·使用外部提供的服务支持琐碎任务。
　　·仅在需要填补剩余空白领域时创建新服务。

　　本部分剩下的内容将对服务方面和使用方面的不同体系结构模式进行概述。

　　启用服务的现有资产

　　SOA并不是“拆除和替换”。最好的做法是在现有应用程序、系统和资产中确定可重用的高价值业务任务，并采用SOA的原则和技术来公开服务。重用已有的应用程序和系统是一项非常明智的业务决策。可以减少新技术方面的投资，而使用现有业务逻辑（这是公司拥有的最宝贵且经过验证和时间考验的资产）。当前应用程序的服务启用工作可以大幅度加速SOA项目的采用进度，并能降低其风险。研究表明，这样的开销比从头构建方法少五倍。由于常用功能的代码已经过了严格的生产使用的检验，因此其维护开销也会减少。

　　图2. 启用服务的现有资产
　
　　在此技术中，单个服务可以利用一个打包或自定义应用程序或者多个系统来提供其预期功能。例如，SAP客户关系管理系统中的地址记录可以与基于大型机的遗留财务系统进行组合，以创建支持开设新客户帐户的服务。此组合服务可以为涉及配送和开单的订单输入业务流程提供部分支持。这样减少了服务大幅度增加的风险，不会在不管粒度如何的情况下将任何现有IT功能都视为服务并加以公开。通过应用恰当的SOA方法，如IBM提供的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）（请参见参考资料），可以解决服务粒度问题。

　　用于处理启用服务的现有资产的两个最流行的体系结构模式如下：

　　·直接将现有应用程序功能作为服务公开。
　　·将功能作为服务组件间接公开。

　　直接将现有应用程序功能作为服务公开

　　当必须将现有应用程序功能作为服务公开，以供其他系统和应用程序使用，或提供更多的访问渠道时，则使用此方法。对于此模式（如图3中所示），其中假定您采用非常简单的场景，其中的现有功能并不复杂，只是使用Web服务技术将其作为服务提供者部署。这个简单的拓扑并不需要任何新基础设施，因为此服务使用支持服务的现有应用程序（通常为遗留应用程序）的工具和技术实现。

　　例如，可以使用IBM CICS Transaction Server V3.1 Web服务技术将COMMAREA应用程序直接作为Web服务公开。最低要求是所公开的服务符合WS-I Basic Profile的要求。（有关技术模式以及现有遗留功能如何作为服务公开的更多信息，请参见参考资料。）

　　对于此方法，一个好处是服务接口由所公开的遗留资产定义，因此不需要进行分析来设计接口规范。而且，由于新服务可以在与包装的现有资产相同的平台上运行，因此没有必要添加新基础设施。能省略接口定义和分析，而且要处理的平台更少，这样部署周期就会更短。

　　采用此体系结构模式来提供服务器支持时，需要考虑以下主要体系结构注意事项：

　　·服务使用者与遗留资产的定义建立联系，而后者在很多情况下的最初设计都比较糟糕。
　　·此模式假定现有应用程序平台提供了对服务调用的最新技术的支持。
　　·实现模式经常给系统带来高服务消息处理负担，而这些系统经常针对无内部互锁管道级的微处理器（Microprocessor without Interlocked Pipeline Stages，MIPS）使用进行了优化。

　　图3. 直接将现有功能作为服务公开
 
　　将功能作为服务组件间接公开

　　此服务支持体系结构模式代表了在现有应用程序功能和服务之间引入中间软件组件（称为服务组件）的情况。下面的图4显示了一个示例。

　　服务组件也称为企业组件（请参见参考资料），是提供服务和实际实现之间的抽象层的IT组件。服务组件可以通过以下方式之一发挥作用：

　　·从头创建业务逻辑和功能时，服务组件可以对内聚业务逻辑从逻辑和功能方面进行封装。
　　·当必须对一个或多个现有操作系统的业务逻辑集成和重用，从而为服务提供集成业务逻辑实现时，服务组件可以封装对外围操作系统（可能为异类系统）的访问机制。

　　使用中间服务组件有一些好处：

　　·可以在不影响服务使用者的情况下更改现有操作系统中的业务逻辑实现。服务组件可以方便地进行扩展，以封装数据和信息，并为数据或信息服务提供外观层。
　　·可以在操作系统层进行系统和功能的IT合并或迁移，而对服务使用者的影响很小或者没有影响。
　　·可以将服务部署在与现有应用程序不同的基础设施上，而现有应用程序的基础设施通常针对服务的特定处理要求进行了硬编码。

　　对于直接将应用程序功能作为服务公开的情况，此模式还有一些主要体系结构注意事项。首先，它允许与业务保持紧密一致但并不一定直接映射到现有应用程序接口的服务接口定义。可以使用SOA的原则和最佳实践来以正确的粒度级别设计服务和接口。不过，这会增加恰当定义服务的设计时间，而且开发周期更长。其次，其设计经常比直接公开更为复杂，因为可能会涉及到使用适配器或连接器技术来与操作系统进行连接。

　　图4. 服务组件作为操作系统功能与应用程序层的服务间的中间层
 
　　使用外部提供的服务

　　在此场景中，服务的来源为一个或多个第三方服务提供商。应用程序利用第三方服务来实现其所需的功能。图5显示了服务如何依赖第三方实现提供者进行实现。

　　图5. 依赖第三方提供商
 
　　此模式的主要优势在于，并不需要花时间为服务定义开发实现构件，将由外部服务提供者提供这些构件。这可以大幅度减少开发时间。还有个值得注意的优势是，客户机能够根据各种技术、财务和政策注意事项在服务提供者之间进行切换。

　　有一些主要体系结构注意事项需要加以处理：

　　·必须恰当地定义服务的服务级别协议（Service-Level Agreement，SLA）。在寻找最佳的第三方提供商时，满足SLA的能力是一项重要考虑事项。
　　·由于服务实现位于企业防火墙之外，所以必须为服务及其调用配备恰当的安全性措施。
　　·应该非常强调服务治理，以建立用于选择最合适的服务提供者的标准。对行业及开放标准的遵从，以及作为服务提供者的第三方的成熟度之类的因素，应该由治理组织加以确定。

　　从头构建服务

　　在此场景中，必须从头设计、定义和开发服务。现有应用程序或任何第三方提供商都不能提供功能或服务来满足您的需求。此场景依赖于Java 2 Platform Enterprise Edition(J2EE)应用服务器支持服务实现。核心业务功能通常使用标准J2EE开发，而且通常采用Enterprise JavaBeans(EJB)或简单的传统Java对象（Plain Old Java Object，POJO）的形式。采用了标准J2EE集成开发环境（Integrated Development Environment，IDE）功能和技术来将EJB或POJO转换为标准Web服务。

　　此方法的优势在于，可通过其根据现有业务需求建模服务，并对其进行恰当的设计来满足将来的业务需求。服务并不受现有操作系统或第三方提供商的约束。

　　体系结构方面的一个重要注意事项是，需要在整个服务开发流程中（从表示到规范再到实现）应用完整的SOA方法（例如SOMA）。

　　服务定义和实现“菜谱”

　　前一部分所讨论的体系结构模式可帮助标识和设计服务，需要对其进行实例化，以实现端到端SOA解决方案。您需要将模式步骤应用到SOA生命周期中，并提供正确的工具和产品来创建特定的SOA构件。

　　IBM使用和遵循SOA生命周期（建模、组装、部署和管理）、治理和流程；我们确定了可应用于SOA生命周期的每个阶段的每个体系结构的活动（请参见参考资料）。IBM还提供了大量的相关产品，可帮助实现任何工业强度SOA解决方案。

　　此部分将以下体系结构模式及其较高级别的活动放入SOA生命周期的上下文中进行讨论：

　　·现有功能的直接公开
　　·现有功能的间接公开
　　·第三方提供的服务
　　·从头创建的服务

　　另外，还提供了经常建议使用的IBM产品的概述，可通过使用这些产品来在真实的合作项目中帮助实现和实例化模式。

　　实现现有功能的公开

　　和所有SOA项目一样，最好从生命周期的角度来看待现有功能的直接公开（也称为现有IT资产的服务支持）。此处我们将利用得到广泛认可的IBM SOA Foundation所定义的服务生命周期。图6显示了可以如何应用SOA生命周期来为现有资产启用服务。

　　图6. 在现有资产的服务支持中应用SOA生命周期
 
　　SOA生命周期的每个阶段都可以应用到服务支持工作中。建议的较高级别的活动包括：

　　建模

　　开始从当前IT应用程序和系统投资组合中形成候选资产目录，以启动建模阶段。在此阶段，最需要关注的是服务建模方法。IBM的SOMA方法是用于面向服务的建模的可靠且经过严格验证的方法。Rational Unified Process(RUP)也扩展为可处理面向服务的方法(RUP for SOA)。RUP for SOA基于SOMA方法。IBM的Rational Software Architect(RSA)提供了建模框架对服务模型进行建模和设计。

　　组装

　　使用各项技术在不更改其提供的基本功能的情况下将资产转换为可重用服务。转换流程实际上将涉及使用定义良好的接口包装现有功能。

　　在此阶段，通常为在IBM System z系统（之前的IBM eServerzSeries系统）上运行的CICS应用程序提供服务支持的工具是名为IBM WebSphere Developer for zSeries(WDz)的IDE。将需要启用服务支持的现有代码库导入到WDz的工作区中。可以利用工具功能来开发Web服务描述语言（Web Services Description Language，WSDL）定义。在此过程中，现有应用程序的数据和语言结构可能需要一些映射和转换。可以从此IDE生成WSDL和特定应用程序绑定。

　　组装阶段也包括对所开发代码的单元测试。WDz提供了用于CICS Transaction Server(TS)的测试环境，提供了所有基本功能，以便测试在实际工业强度CICS TS上运行的WSDL。可以在CICS TS测试环境中作为组装阶段的一部分对生成的WSDL进行测试。

　　部署

　　使用SOA基础设施和中间件产品来部署服务，从而将访问扩展到其他涉及到更多系统和用户的功能。

　　在此阶段，要将经过单元测试的WSDL和所生成的COBOL源代码（进行了可能的数据和语言转换后）部署到CTS上。随CTS 3.1提供了很多Web服务功能（如WS-Security），可以在部署过程中对其进行配置。

　　管理

　　以实时方式仔细管理和监视所部署的服务，以了解更新后的资产的性能和安全性。对于此阶段，主要的焦点转移到了管理和监视所部署的服务上。必须仔细地监视服务，以确保遵从已发布的功能和非功能需求。

　　IBM的Tivoli品牌产品针对一般系统管理和监视进行了优化，包含用于满足监视和管理服务的大量产品。Tivoli Omegamon-XE for CICS 3.1常用于在IBM z/OS上管理和监视CICS TS。Tivoli还提供了一套产品，专门针对服务调用和安全性的特定领域，如：

　　·IBM Tivoli Federated Identity Manager(ITFIM)，提供松散耦合联合标识模型来跨企业边界管理标识。
　　·IBM Tivoli Identity Manager(ITIM)，提供企业内的集中标识管理系统。
　　·IBM Tivoli Access Manager(ITAM)，提供单点登录和授权功能。

　　治理和流程

　　确保遵循服务生命周期及其有效控制和管理方面的策略、标准和最佳实践。

　　对于此阶段，WebSphere Service Registry and Repository(WSRR)是支持整个SOA生命周期的IBM产品。WSRR允许服务提供者安全地注册业务服务，以供服务使用者进行查找和绑定。另外还提供了发布在SOA中管理服务的生命周期所需的元数据的功能。

　　总而言之，在实现直接访问现有应用程序的模式时，可以遵循标准IBM SOA生命周期的阶段，并在各个阶段中使用以下产品：

　　·RSA，用于服务的建模和设计。
　　·WebSphere Developer for zSeries，用于将现有功能组合为服务，并从CICS TS Test Environment对其进行单元测试。
　　·在CICS TS 3.1上部署服务定义以及所生成的遗留代码。
　　·使用一系列Tivoli管理与监视产品，如主要用于管理和监视服务SLA的Tivoli Omegamon-XE、ITFIM、ITAM等。
　　·WebSphere Service Registry and Repository，用于在SOA中在服务的整个生命周期中对其进行管理。

　　实现现有功能的间接公开

　　服务创建的每个机制都具有一组规程，即给定场景下最常遵循的步骤。前面所述的这些步骤可以与SOA生命周期的五个阶段建立联系。此场景的主要步骤与实现现有功能的公开非常相似，因此将不在此进行重复说明了。

　　正如服务创建场景的访问模式中所述，间接公开和直接公开的区别在于其中包含了服务组件层。服务组件提供与业务保持一致的服务接口——自顶向下方法。通过分析现有资产，可以确定可以使用哪些系统中的哪些应用程序功能来实现服务组件定义的服务接口。服务组件充当业务中心视图和现有应用程序之间的中间层。因此，这个新的外观组件在组装阶段需要执行额外的步骤。

　　在建模阶段，可以使用SOMA方法及其抽象规范进行服务定义。这与第一个访问模式并没有太大的区别。在这两者中，都将执行SOMA的服务标识阶段。不过，其区别在于阶段中的活动重点。在直接公开期间，其重点在现有资产分析上。在非直接公开场景中，重点在使用自顶向下方法标识与业务一致的服务。此处建议使用的IBM产品是Rational Software Architect。

　　在组装阶段，最常用的工具是Rational Application Developer(RAD)。如果在此阶段将RAD作为IDE使用，请遵循以下步骤：

　　·在RAD工作区创建Web或J2EE项目——最好是新项目。从与业务一致的角度来认识服务及其接口操作，并据此定义WSDL。使用SOMA标识阶段的输入来定义与业务一致的服务（业务服务）。如果已经定义了WSDL并且其可用，直接将其导入到RAD的项目工作区中即可。

　　·从WSDL生成会话EJB框架。应该随后实现所有操作的业务逻辑。对于遗留系统在其他环境中运行的情况，应该在实现期间使用适配器技术。例如，对于在独立System z(zSeries)计算机上运行的CICS应用程序，需要使用CICS ECI资源适配器连接到CICS系统。

　　资源适配器通常采用资源存档(.rar)文件的形式，需导入到RAD工作区。资源适配器包包含应用程序编程接口（Application Program Interface，API），可用于帮助从会话EJB访问CICS应用程序。还应该针对遗留系统中使用的特定语言使用相关的Java数据绑定。

　　·将WSDL定义以及所实现的会话EJB、Java数据绑定以及可选资源适配器打包为企业存档（Enterprise ARchive，EAR）文件，以供进行部署。

　　尽管在组装阶段使用RAD是一种很常见的做法，但很多IT企业仅在使用遗留系统方面非常专业。在这样的客户机环境中，建议使用WebSphere Developer for z(WDz)。WDz V6.0.1提供了内置的CICS TS测试环境，可与CICS Transaction Gateway V6.0.2组合使用，从而提供一个非常强大的用于从遗留系统公开服务的环境。

　　如前面所提到的，WebSphere Service Registry and Repository是用于服务生命周期治理的标准IBM产品，同时我们也建议使用此产品。

　　实现第三方提供的服务

　　当现有遗留系统和应用程序过于晦涩难解而难以替换，或业务需求要求提供现有系统中没有的功能时，则下一个选项就是第三方服务提供商。行业中经常出现第三方程序包提供的功能影响企业的业务需求的情况。很多企业都出现了这样的情况，但后来却发现由于所感兴趣的第三方程序包的特性或功能影响，就开始改变自己的业务需求。这是SOA采用中的一个反模式，应该加以避免。

　　在此场景中，功能需求可由第三方服务提供商完全或几乎完全满足。在业务需求强制要求的可接受限制范围内，必须满足功能需求和SLA需求。

　　此场景的高级活动也可以映射到SOA生命周期的各个阶段，如图7中所示。

　　图7. 将第三方服务包含到企业SOA中
 
　　SOA生命周期的每个阶段都可以应用到服务支持工作中。建议的高级活动总结如下：

　　建模

　　首先运行转换范围内的业务流程的模拟，并决定哪些服务适合自己创建，哪些服务适合从外部获取。

　　在建模阶段，重点是分析使用第三方服务提供商而不自行构建服务的理由。将执行各种业务分析和模拟，并评估成本、时间、资源和IT可行性。

　　组装

　　访问外部服务，并将其与自有服务编排在一起，从而支持端到端业务流程。组装将对第三方服务和企业自有服务进行编排。

　　在组装阶段，将执行主要工作。所建议的IBM产品为RAD。相关步骤包括：

　　·从服务提供者获取WSDL。
　　·验证WSDL，并与提供者进行合作，以成功地通过完整的验证。
　　·在RAD中创建新企业应用程序。
　　·将WSDL导入项目工作区。
　　·从WSDL生成客户端存根。这时请仔细分析哪种XML绑定类型是恰当的（JAX-RPC、JAXB等）。
　　·根据客户端存根开发客户机应用程序，以调用服务。
　　·将项目打包为可部署EAR文件。

　　部署

　　可以对经过编排的服务进行部署，而不用担心每个服务的出处。

　　在此阶段，可部署EAR文件安装在Web服务兼容中间件服务器上。此处建议的IBM产品是WebSphere Application Server。所安装的EAR文件提供了客户端API，以使用第三方服务。

　　管理

　　如果第三方服务提供商进行实现工作，则务必监视服务，以确定是否符合和满足业务强制要求的SLA和合同规定的关键性能指标（Key Performance Indicator，KPI）。IBM Tivoli Composite Application Management(ITCAM)for SOA是用于监视运行时服务器来确定遵从性的最为全面的Tivoli产品。

　　治理和流程

　　在注册中心创建和维护外部服务目录，以方便访问和管理。

　　在此阶段，将提供外部服务的WSDL定义此阶段建议的IBM产品是WebSphere Service Registry and Repository(WSRR)。任何采用服务增强形式出现的更改都在管理服务的生命周期的WSRR中进行管理。

　　实现从头创建的服务

　　此场景通常是最后的选择。当没有现有应用程序功能可以直接或间接地作为服务公开，而且没有第三方服务提供商提供所需的业务功能时，就会采用此方法。服务定义和所有实现构件都需要从头构建。这可能看起来很简单，没有需要作为基础的现有遗留系统，没有要集成的遗留代码，没有要挂接的第三方提供商服务，也没有部署时要考虑的复杂拓扑。但要确定服务标识和深入规范，可能会有不少的工作要做。图8显示了SOA生命周期的不同阶段的主要活动。

　　图8. 应用于从头创建服务时的SOA生命周期
 
　　从SOA生命周期的角度而言，从头创建服务所涉及的活动如下：

　　建模

　　其重点在于设计与服务一致的服务，同时涵盖当前需求和将来的需求。建议的方法是应用SOMA的服务标识技术，并同时使用Rational Software Architect进行服务建模，以创建实际的建模构件。

　　组装

　　用于服务开发的建议IBM产品是Rational Application Developer(RAD)；RAD是一个可靠且功能丰富的J2EE应用程序开发IDE，它还提供了用于服务开发和实现的各种简单功能和高级功能。它提供了基本服务实现的简单功能，并将其作为WSDL文件公开。Rational Application Developer还可以添加有关Web服务实现的高级功能，从WS-I遵从性开始，以增量方式逐渐添加WS-Addressing、WS-Transactions等实现。使用Rational Application Developer进行服务开发的一般步骤（与实现第三方提供的服务类似）如下：

　　·在Rational Application Developer中的新工作区创建J2EE企业应用程序项目。
　　·基于服务的设计规范创建WSDL定义。或者，如果存在WSDL，则将其导入工作区。
　　·从WSDL生成会话EJB服务框架。
　　·为服务框架中的所有已定义操作完成业务逻辑实现。
　　·或者，创建用于调用服务的Web服务客户机代码。对于调用服务的J2EE应用程序客户机，此客户机代码已经足够了。对于非J2EE客户机，需要提供技术特定的客户机代码来进行服务调用。
　　·将实现构件打包为部署时使用的EAR文件。

　　对于将企业业务流程作为服务编排实现的端到端解决方案，可以将此场景作为服务设计和开发工作进行构造；组装是这些服务在业务流程上下文中的编排。

　　建议使用的IBM工具为WebSphere Integration Developer(Integration Developer)，此工具提供了业务流程执行语言（Business Process &#101xecution Language，BPEL）开发环境。除了其他功能外，还提供了将现有服务编排为业务流程流的功能。所得到的流程可以随后部署到BPEL运行时引擎中，从而提供编排功能来执行企业级业务流程。

　　部署

　　经过打包的EAR部署模块安装到WebSphere Application Server运行时上。对于分布式环境，建议使用WebSphere Application Server Network Deployment Edition V6作为运行服务的中间件。要部署所提到的业务流程，建议使用的IBM产品是WebSphere Process Server V6（属于IBM WebSphere Business Service Fabric中间件）。

　　管理

　　需要对所部署的服务进行监视和管理。监视通常是保证遵从服务的SLA的典型强制要求，并在达到不遵从阈值时引发警报或事件。在企业范围外公开服务时，最低要求是，要保证非授权访问无法访问服务。前面提到的Tivoli产品均适用于此场景。简要总结如下：

　　·IBM Tivoli Composite Application Management(ITCAM)for SOA，用于监视服务以确保SLA遵从性。
　　·IBM Tivoli Federated Identity Manager(ITFIM)，用于在整个企业范围内进行联合标识管理。
　　·IBM Tivoli Identity Manager(ITIM)，用于跨企业系统提供集中标识。
　　·IBM Tivoli Access Manager(ITAM)，用于单点登录和在服务调用前进行授权。

　　治理和流程

　　服务生命周期管理的建议IBM产品是WebSphere Service Registry and Repository，此产品具有可靠的高级功能，能以模块化的方式进行使用。

　　总结

　　IBM确定了典型的基于SOA的IT项目的八个不同的常见SOA场景。IBM还提供了全面的指导信息，说明应该如何使用面向SOA的IBM工具、产品及方法对每个场景进行建模、设计和实现。

　　在本文中，我们讨论了第一个SOA场景，服务创建。我们还对基于以下三个主要服务来源进行良好服务支持的四个最常用的体系结构模式进行了概述：现有应用程序、第三方服务提供商以及从头创建服务。另外，我们还了解了如何将SOA生命周期应用到四个体系结构访问模式，以及IBM产品套件可以如何处理服务支持的特定设计、开发和运行时需求。