为何使用面向服务的架构

1

SOA专业人员指南 第1部分

为何使用面向服务的架构？

作者：Surekha Durvasula

2

参与本书的SOA专业人员

Surekha Durvasula，Kohls，企业架构师

Martin Guttmann，Intel公司Customer Solutions Group，首席架构师 Ashok Kumar，Avis/Budget，SOA Architecture经理 Jeffery Lamb，Wells Fargo，企业架构师

Tom Mitchell，Wells Fargo Private Client Services，首席技术架构师 Burc Oral，个人贡献者

Yogish Pai，BEA Systems, Inc.，AquaLogic Composer首席架构师 Tom Sedlack，SunTrust Banks, Inc.，企业架构工程师 Dr Harsh Sharma，MetLife，高级信息架构师

Sankar Ram Sundaresan，HP-IT，首席电子商务架构师 审校人员

Prasanna Deshmukh，WebEx Communications，架构主管 Noam Fraenkel，Mercury Interactive，首席IT技术官

Steve Jones，Capgemini Group的Application Development Transformation部门，首席技术官 Brenda Michelson，Elemental Links, Inc.，首席顾问及分析师 Ashok Nair，关于EAI和信息技术服务的管理系统分析师，卡尔加里城 George Paolini，Georgepaolini.com，顾问 Jeff Pendelton，SOA Alliance，执行主管 Annie Shum，BEA，SOA战略副总裁

作者十分感谢为本文档做出贡献的组织和个人，他们撰写了部分文档，进行了大量编辑工作，还帮 助审校了文档并提供反馈。此外，作者还要特别感谢BEA Systems, Inc.，是这个公司提供了本文档 中的开发和演示所需的基础架构和平台。

3

1 关于本文档

1.1 摘要

SOA是一门相对较新的技术，所以很多致力于实现它的公司无法获得良好的实践专业指导。如果没有 基于共同经历的通用语言和行业词汇，SOA技术很可能最终只会为IT基础架构带来更多自定义逻辑并 提高其复杂度，而无法实现其提供企业内和企业间服务重用和流程互操作性的承诺目标。为了帮助 开发共享语言和有关SOA的知识集，一群SOA专业人员创建了《SOA专业人员指南》这个文档系列。在 这个文档系列中，这些SOA专家描述并评注了一些与SOA相关的最佳实践和关键知识，以帮助其他公 司迎接SOA的挑战。他们对《SOA专业人员指南》的期望是，这个分为多个部分的知识集在出版之后，

能够作为所有SOA相关人员的标准参考百科全书。

1.2 目标受众

本文档的目标受众为：

需要跨企业/LOB启动和管理SOA战略的业务和IT领导

需要促进实现SOA计划的理想和路线图以及其中包含的每个实现的架构的企业架构师 需要管理SOA整体业务战略中的子项目组合的程序管理员 需要映射依赖关系并开发满足业务期望的时间线的项目团队成员 为业务和IT提供新业务能力的解决方案和工具的供应商

需要更好地了解业务和IT计划如何利用技术实现其目标的使用案例的标准机构。

1.3 《SOA 专业人员指南》的优点

本文档可帮助读者：

向他人学习：很早就开始使用SOA的用户可共享其有关跨行业采用SOA的最佳实践、看法以及 观点

比较替代产品：识别和定义SOA的关键技术组件，建立对选项比较的基线参考点 改进合作：使用一种通用语言澄清本文档中定义的SOA组件的性质

加速实现：本指南定义了其服务生命周期和需求、建议的工具以及每个阶段的最佳实践。 了解标准的价值：本文档建议了用于SOA的各个方面的标准 避免潜在风险：本指南指出了供应商社区尚未指出的一些问题领域。

5

1.4 SOA 专业人员指南：章节

《SOA专业人员指南》包含三个单独的部分。

本文档（《为何使用面向服务的架构？》）是第1部分，它为SOA提供了一个高级摘要。 第2部分《SOA参考架构》提供企业级SOA实现的工作设计，包括详细的架构图、组件描述、详细 要求、设计模式、有关标准的观点、法规遵从性模式、标准模板以及成员的潜在代码资产。 第3部分《服务生命周期简介》提供了在整个服务生命周期（从项目初期到完成或重新定位服务）中 提供服务管理的详细过程。该文档还包含一个附录，其中包含组织和治理最佳实践、模板、对关键 SOA标准的评论以及建议的到详细信息的链接。

2 执行摘要

2.1 行业背景

经过多年的发展，面向服务的架构（SOA）已经可以通过定义一种使用和重用软件组件和业务流程 的方法为IT提供空前的灵活性和成本节约。不过，SOA仍然是一种新的技术，组织仍然需要学习如 何实现这种技术从而实现企业间和企业内的服务重用和流程的互操作性。同时，潜在的SOA专业

人员遇到一些典型挑战，就是其软件方法目前还不受完全成熟的行业的支持。例如：

几个大的供应商全部声称采用了SOA并发布了自己的观点和SOA参考架构。SOA启动技术为较 大供应商所掌握，导致系统更加不稳定

IT通常无法与业务部门有效地沟通，他们无法了解如何投资于SOA技术使得业务功能自动化

以及提供更便宜、更好更快的解决方案

每个主要标准机构都组成多个团队尝试对SOA进行定义，使得情况更加混乱，也延缓了SOA的

采用。

开发和管理工具不足

行业之间通用词汇的缺乏使得最佳实践的共享变得困难。

2.2 业务系统的当前状态

传统情况下，IT与业务所有者一起工作，后者受到应用程序供应商的影响。这就使得IT战略更加关 注应用程序或集成。此外，管理方式和资金模型促使业务和IT涉众尽一切可能满足特定业务单位或 部门的需要。这就导致产生许多可以或者不可以集成到现有架构中的“一次性”应用程序。兼并和 收购导致在本已支离破碎的架构中加入新的软件平台和方法，而IT很少有足够的资源来完成业务系 统集成。其结果是，IT最终通常在企业或业务单位内部署多个执行相同任务的系统。身份验证、单

6

点登录和数据集市的冗余基础架构解决方案以及（打包或自定义的）应用程序（例如销售自动化 （SFA）、引用和订单管理）加剧了IT的复杂性，也使其成本剧增。因此，通过修改此组合对业务 流程更改进行响应或者调节获取成本变得几乎不可能，自然也无法实现。

在许多组织中，IT小组使用点对点或EAI方法将这些独立的系统集成起来，这些方法可以将应用程序 连接到上行和下行系统。为了跨业务流程跟踪事务，IT跨应用程序传播一些关键值（有时候是不一 致的），并为每个业务单位创建不同的操作数据存储以便跟踪关键的性能指标。这样，为了提供完 美的用户体验，IT经常构建门户应用程序以便连接到多个后端应用程序、数据集市和主要数据。 图1：目前最佳的企业架构案例

从架构的观点来看，这种架构非常有效，但维护或扩展起来十分复杂和昂贵。这些解决方案难以修 改，因此需要更改业务时IT很难快速响应。这就带来冲突的感觉。

2.2.1 影响IT 的业务问题

企业的IT小组对于企业迎接挑战的能力至关重要，挑战包括竞争性定价、离岸供应商以及目前不断 变化的全球市场中出现的其他问题。

7

2.2.1.1 全球化

企业要想在全球化环境中存活下来必须具有良好的灵活性。如果竞争对手能够制造更廉价的相同产 品，企业就需要更具创造性并且更快速地进行响应，IT很少有机会影响期望和替代产品。

2.2.1.2 经济压力

虽然各个公司的记录中都存在现金余额，但是市场仍然不见增长。于是各公司尝试通过兼并和收购

获得增长。合并和精简各地分散员工、流程和系统的要求给业务和IT小组施加了额外的压力。

由于增长减缓，企业更加关注成本削减。为了减少预算，IT将非核心功能外包，并采取离岸式开发 模型。这种方式不算理想，但这使得IT能够在有限的预算中释放出一部分资金，用于开发新的业务 功能。

2.2.1.3 业务流程外包

这种倾向在接下来的几年还将呈指数级别增长。外包方式使得企业能够关注其核心业务，而将非差 异性服务（如人力资源、呼叫中心和数据中心管理）外包出去。不过，这样IT又必须应对将第三方 业务流程和数据集成到核心业务中的挑战。

2.2.1.4 法规遵从性

企业必须遵从政府法规才能长盛不衰。最近公布的一些法规（特别是Sarbanes-Oxley）要求IT组织 检查（有时候还要改进）所有业务系统。这又要从新业务功能开发中挪用本已不算充裕的IT资源和 资金。未来法规更改时也会要求系统进行相应的更改。

2.2.1.5 技术

通过使用新技术能够创建新的业务能力。通过抓住新的机遇也可以带来新的挑战，对于IT来说更是 如此，因为这通常必须向企业指出如何销售和提供新产品或服务以及如何收费。

由于资源的缺乏，IT必须在维护和升级现有IT系统与投资于新系统以便创造新的业务机遇之间进行 艰难的抉择。

2.2.1.6 缺乏聚合性业务信息战略

在大多数情况下，LOB决策人员并不清楚共享基础架构和业务逻辑的优点。他们更关注其直接需要 以及IT响应，通常开发多个功能几乎相同但算法冲突的系统，使集成和合并变得非常复杂。许多公 司通过多个不兼容的解决方案实现身份验证、单点登录和数据集市，并通过多个（打包的和自定义 的）应用程序实现销售自动化（SFA）、报价和订单管理

公司结构通常也能促进共享和跨团队协作。这可导致对IT的项目关注，而不是一致的业务信息战略 和基于业务的IT基础架构。

8

2.2.1.7 标准

最近的统计表明目前存在超过56个涉及SOA的各个方面的标准机构。他们的工作未能协调一致，因 此标准众多实际上等于没有标准。要遵循哪个“标准”完全由各个IT小组自行决定。

2.2.2 必要的转化

企业希望IT组织能够更加灵活，但又不愿意支付更多的费用。而IT组织需要使用资源来使旧的应用 程序能够更好地运行，开发更灵活更有效率的基础架构以及增加需要的业务功能。传统的治理、组 织和项目管理模型无法解决这种冲突。迎接这种不断加剧的业务挑战的唯一办法就是合并业务和IT 转化。

大多数业务和IT执行人员都赞同下面的基础业务原则：业务流程能够使企业在竞争中脱颖而出。对 有些人来说，这指的是处理供应链的方式，而对其他的一些人来说，这可能是指他们将新的创新性 产品推向市场的能力。关注业务流程对企业更理智地对待更灵活的面向目标的模型来说非常重要。 不过，业务和IT运营团队采用的方法经常存在差异。例如，有些业务运营团队倾向于通过演示“速 效方案”验证方法，而IT操作团队倾向于构建基础架构。幸运的是，SOA提供了上述两种方法。 图2：业务价值与复杂性

图3：存在冲突的业务与IT优先事项

9

2.2.3 建议的方法

有经验的SOA专业人员建议使用下面的方法开发路线图以便解决业务和IT目标之间的冲突： 了解业务服务：这是成功采用SOA的关键的第一步

开发识别关键性能指标的信息战略，这些指标包括“产品缺陷减少x%”或“在24小时内响应所 有按揭申请”

开发一个能够清晰地描述业务优点的SOA蓝图，在其中包括业务原则、参考架构、路线图，以 及治理和组织方针

识别“速效方案”，说明IT通过采用SOA可改进目前需要15-18个月的提供新功能的时间。 一旦专业人员采用了这些步骤，IT组织就需要识别提供业务解决方案所需的基础架构服务。设计和 构建基础架构服务以支持粗粒度、松耦合的和基于标准的服务使得IT能够将自身转化为业务需

求。然后IT就可以预测性或响应性地提供全局解决方案，同时降低应用程序和基础架构复杂性，提

高业务服务的重用性以及服务编排能力。

蓝色：业务解决方案 红色：服务基础架构 灰色：业务流程

上图显示了要提供这些解决方案需要的业务解决方案和服务基础架构。SOA专业人员建议根据需要