使用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. 依赖第三方提供商
