(一)基础：什么是 BPM 商业流程管理？
CNET 中国· 类型:转载 作者: csdn 责编:小蝎 时间:2006-10-23
BPM 是流程自动化的应用，帮助企业进行业务流程的分析之外，另可利用 IT
技术，自动化组织内各部门的原本以人力及公文传递的流程。
根据数据整合软件供货商 Ultimus 的定义，BPM 主要精神在于管理企业的流
程。除工作流程自动化系统之外，还必需提供企业应用软件整合（EAI）与交换
的功能、流程成本效率评量与绩效管理，以及流程初始设计的模型最佳化工具，
用以涵盖企业管理流程中所有的必要环节。
分析师建议，决定 BPM 工具之前，企业必须用严谨的态度检讨目前使用的
软件，决定业务角色的授权，权衡数据模型（data model）与分析工具（analytical
applications），并建立未来采用 BPM 后的假想情境。
目前包括 IBM、微软、BEA 也努力催生商业模型标准，联合起草网络服务
（Web Services）商业流程执行语言（BPEL4WS）。业界相信，先建立商业流程
模型，再从这些流程模型中建立应用程序进而监视这些模型，将有助在企业内部
的 IT 部门与业务主管之间建立起环环相扣的自动化流程
（二）体系架构蓝图----SOA 和 BPM 的
合并
CNET 中国· 类型:投稿 作者: BEA 责编:小蝎 时间:2006-10-23
面向服务的体系架构（Service-oriented architecture，SOA）已经成为软件工
程中一个最重要的主题。无疑，随着 Web 服务的推广和广泛接受，以及支持基
于 SOA 解决方案开发的 case 风格的 IDE 这一新浪潮的兴起，SOA 已经成为构
建企业级分布式应用程序的首选蓝图。与此同时，业务流程管理（business process
management，BPM）作为操作灵活的新企业并为其建模的主要支持者，正在强
力反弹。
面向服务的体系架构（Service-oriented architecture ，SOA）已经成为软件工
程中一个最重要的主题。无疑，随着 Web 服务的推广和广泛接受，以及支持基
于 SOA 解决方案开发的 case 风格的 IDE 这一新浪潮的兴起，SOA 已经成为构
建企业级分布式应用程序的首选蓝图。与此同时，业务流程管理（business process
management ，BPM）作为操作灵活的新企业并为其建模的主要支持者，正在强
力反弹。基础结构厂商已经使 BPM 成为他们出售的系列产品的主要组件，瞄准
%20
%20
机会的厂商使用专用的 BPM 系统提供垂直的业务解决方案，纯使用 BPM 的厂
商正在得到更加广泛的接受。
尽管两种趋势均显露出了征兆，它们的趋同现象仍不明显，而且关于这种现
象没有统一的看法。它们是互补的表示法吗？它们会重叠吗？我该如何一起使用
它们？这样做有没有另外的优点？此外，为什么 80 年代末期的企业流程重构
（BP reengineering）失败了，而第三次 BPM 浪潮却将要取得成功呢？
在这一系列三篇文章中，我将解决这些问题。首先，我将讨论一个体系架构
蓝图的最佳实践如何将面向服务体系架构与 BPM 框架合并，从而为构建健壮的
企业级集成解决方案并对其建模提供可重复的方案。我描述了为什么在当今，任
何使用技术支持其任务陈述需要的企业比以往更能拥有合适的体系架构蓝图。最
后，我讨论了什么是实时交易的挑战，以及 BPM 方法如何能够实现企业灵活性、
智能企业建模、系统开发和以客户为中心的运作优点。
在第二篇文章中，我将应用 BPM 技术来为一个支持“用于汽车保险”业务场
景的软件解决方案建模和设计体系架构。我将讲述两种设计：一种纯 BPM 设计
和一种混合型设计。我还将讲述一些新兴的建模工具和标准，并讨论一些建模和
各种体系架构选择和策略方面的难题。
在第三篇（也是最后一篇）文章中，我将使用 BEA 的 WebLogic Platform
构建一个 POC。我将讨论 BEA 的 IDE 新引入的可视化编程范型及其优缺点，
和构建完全分布式的企业级应用程序所需的一些技术。我还将解释，为什么流行
的请求/响应模式的 WEB 协议与基于事件的流程建模，以及它在进行架构决策时
的意义不一致的原因。
体系架构模式 —— 谁需要它们?
软件工程是艺术还是科学？在科学中，我们有明确的定义、定理和证据。在
艺术中，我们有工具和技术、趋势以及最佳实践。科学中提出了一些假设，其中
一些变成定理，另外一些在经过数个世纪的研究之后得到验证，还有一些永远没
有答案。在艺术中，新技术带来新的趋势，比如新闻和数字摄影。如果软件工程
是一门科学，定义我们在日常业务语言中使用的所有术语不应该是一件困难的事
情，像服务、Web 服务、面向服务的体系架构、BPM 和 BPM 系统（BPMS）。
的确，我可以利用数学精度来证明一个数据库查询算法的正确性。但是，我能够
以一种干脆、简洁且通常会被接受的方式来回答，J2EE 中的 B2B 集成是与
纯.NET Web 服务解决方案相对的正确答案吗？据我了解，对于我们中间的一些
人来说，这不是问题。最后，任一种常见的贸易出版物的随机调查指出，每个人
都可以给出自己的定义，而有些人甚至质疑 IT 存在的本质。我不得不得出结论，
软件工程仍然是艺术多于科学。这正好是我们需要合适的最佳实践、框架和可重
复过程的原因。
模式封装了最佳实践，简练地定义了域问题，描述了使问题值得关注的原因，
并提出了解决方案。模式并没有解决独特的问题。专业人员结合各种模式来解决
更为复杂而且有时更为独特的问题。Christopher Alexander 说：“模式同时也是发
生在世界上的事件和告诉我们如何创建该事件的规则，以及我们必须创建它的时
刻。它既是过程，也是事件。”我回想起我一直以来最喜欢的定义：对象是带有
状态或数据及行为的数据结构。就目前来说，可以把 Web 服务看作带有一个方
法的对象。就像 BEA WebLogic Platform 所实现的那样，会话式 Web 服务看
起来更像是真正的对象：对它进行一次初始化，然后一直执行方法。万一您仍然
不能肯定 Web 服务是粗粒度的对象，考虑：(1) IBM、BEA 和 Microsoft 宣布了
WS-Eventing 规范。它就像是优秀但老式的对象观察者模式。(2) 开放式网格服
务体系架构（Open Grid Services Architecture）实现了网格服务协议的 Web 服务
接口继承。因此，Web 服务提供数据和行为（Alexander 的定义中的事件和规
则），而 BPMS 实现模式的流程组件。SOA 是一个用于解决企业集成和系统开
发问题的体系架构模式。
我们已经看到，SOA 不是体系架构趋势的革命，而是它经过一段时间发展
的演变成果。它围绕为企业构建分布式系统而发展。诚然，Web 服务以一种普
遍接受且无二义性的方式提供底层技术，以解决系统连接性问题。也许是头一次，
Web 服务成功地解决了互操作性的问题，而这是 CORBA、COM、 DCOM 和
RPC 做梦也从未想过的事情。我肯定，作为中立语言，XML 对此也准备一展身
手。然而，SOA 中包括进来的 BPMS 框架是一个新的、革命性的元素。Howard
Smith 和 Peter Fingar 描述的第三次浪潮是指一组全新的概念、框架和主流产品。
它正在显著改变企业转化的方式，从而灵活地管理和运行全局的和协作的电子商
务实体。
业务流程管理的出现已经有一段时间，它更多地用于工业中，而与 IT 无关。
并发工程和六西格玛被开发用来解决生产和流程改进中的及时协作问题，并且确
实取得了相当的成功。然而，在 80 年代晚期，出于多方面的原因，业务流程重
构管理获得的成功非常有限。但是最根本的原因是，重构是纸上谈兵。没有软件
来支持这样一个复杂的任务。BPM 在没有考虑 IT 系统的情况下设计了自适应的
企业。正如 David Taylor 所写：
“对连续性流程优化的需要要求从根本上重新考虑如何设计和构建信息系统。
提出解决固定问题的固定解决方案已经不再够用。”
信息系统，像它们支持的业务模型一样，必须在本质上就是自适应的。
Taylor 提出一种基于 OO 的开发技术，作为开发自适应 IT 的一种方法，这种
技术称为聚合工程（convergent engineering）。然而，OOP 无法成功解决分布式
计算和企业集成的问题。另外，负责对企业建模的业务分析人员也没有采用
OO。
BPMS 将流程建立为用于建模、软件设计和运行时执行的统一结构。过去，
开发趋势一直在影响我们对企业建模的方式。功能式编程使功能需求技术流行起
来。关系数据库带来了 RDBS 分析和设计的流行。面向对象的编程则为 OO 分析
和用例开发铺平了道路。但是在大多数情况下，业务分析人员不会使用开发专门
术语，因此产生了对需求可跟踪性中通常影响的另一种翻译的需要。
BPM 规范正在快速演变为标准。市场中已经出现了支持业务建模、优化和
运行时执行的产品。正如 BEA 的 WebLogic Platform 和其他 BPMS 产品所实
现的那样，以流程为中心的 BPMS 方法用于系统开发生命周期，它消除了对运
行时阻抗不匹配的业务需求。
灵活的企业拥有自适应的业务和自适应的 IT 系统。如果构建企业解决方案
的过程中出现一个新的问题，那么它一定是需求变化的速度。它的速度之快是前
所未有的。BPMS 引擎添加了一个新的层到传统的开发堆栈（参见图 1）中，并
引入服务质量来解决企业集成中的根本问题。BPMS 引擎使编程最易变的部分
——集成点——的软布线变得容易。软布线是以正式语言显式描述的，并由
BPMS 引擎（又名有限状态机引擎）执行。正如 BEA WebLogic Integrator 和其
他 BPMS 产品所实现的那样，业务与 IT 资源可以同时在一个可视化的只能 IDE
中查看和修改流程。只需轻击鼠标，便可部署到运行时 BPMS 执行引擎。业务
模拟可以运行，而性能工程可以在系统完成之前完成；这种方式听起来就像
CASE 工具。SOA 和 BPMS 工具将灵活企业的实时执行仪表板带向主流。
（图 01）
在本文余下的部分中，我将描述一个典型的金融服务企业的开发，并提出一
条通向基于 BPMS 的 SOA 的迁移路径。该路径是增量的，但是它需要战略思考
和对未来远景的承诺。作为回报，它将允许投资的早期回报，并将遗留企业转化
为完全自适应的灵活企业。
从企业远景到组织筒仓（Silo）
企业从远景开始。CEO 和董事会采用远景和行业使命陈述。C 级管理人员
定义策略，并适当地安排流程来管理执行（参见图 1）。定义功能角色和责任，
然后创建企业界线。业务分类（Line of business，LOB）在本质上可以是水平或
垂直的（参见图 2）。垂直 LOB 具有以下特征：
独立的操作域。
特有的管理和策略。
开发和维护自己的 IT—自动化孤岛。
足够大以至于可以创建多种业务分类；例如，抵押贷款证券、市政公债、货
币市场，等等。
（图 02）
水平 LOB 具有不同的特征集合：
提供业务控制。
管理的支配和一致。
需要访问由垂直 LOB 管理的数据。
合适的手动流程和书面报告。
在第二个信息纪元（不要与第二次浪潮混淆）中，我们使用了各种编程技术
来链接自动化孤岛，从 FTP、数据库复制、EAI 和消息收发开始。此方法产生了
一整套新问题：
· 接口的多重性: 一份 Morgan Stanley Dean Witter 报告表明，通常的金融服务客
户需要维护 6000 个接口，为此每年花费 2500 万美元，而且每年还需构建 900 个
新的点到点接口，为此需另外花费 2500 万美元进行构建，并且还要花费 400 万
美元进行维护。
· 调停流程: 必须在每一个仓库上实现，需要消耗有价值的时间和昂贵的资源。
这是一项常用技术，用于检验由多个实体修改的引用数据。
· 流程: 在中间件中进行硬布线。在分析过程中捕捉流程所花费的时间和金钱属
于浪费。企业最重要的资产——流程——隐藏在 n(n-1)个意大利面式接口的迷宫
中。
· 开发新的水平流程：需要多个 LOB 的协调。
· 实现特定和专用的接口：需要专门化和一次性编程。重用消失，维护方面的投
入显著增加。
· 异常难于跟踪： 错误解析通常需要访问多个系统。人工干预和解释是不可避
免的。找寻答案需要花费大量宝贵时间，并对客户满意程度和收益性方面的大致
情况有着直接影响。
流程无处不在。您能发现它们吗？
对于企业来说，流程可以是客户层面上的，也可以是内部的，或者可以是更
大流程的组成部分。我们在同样的企业中可以找到内部流程。流程通常涉及到人
与系统的交互，或者只是系统之间的交互（参见图 3）。交易流程是大规模流程
的一个很好的例子。行政管理部门的交易人员在他的销售订单系统中接收一个来
自对冲基金管理人员的交易执行命令，或者他接到一份传真或一个电话。交易人
员检查库存系统的安全性或资金，并借助他的交易对手执行交易。可以制造纸质
入场券，而交易助手可能必须在下行系统中进入它。
（图 03）
当因为下行系统之一错误地再进入，而帮助台分析人员收到一份异常报告时，
另一个内部流程启动了。然后，他在内部记事薄之一中查找数据（原始进入记
录），请求来自事务部门的传真（我们假定讨论的交易超过了结算日期），而且
因为他在两天内没有收到回复，也许他会再次重复同样的行为。这个流程最终当
分析人员解决了问题时终止，当然，除非他调到另一个部门或者调出公司。然后，
顾问们必须参与进来，跟踪问题和流程，这通常需要一大笔钱。
每月的客户声明是定期性企业范围内流程的一个传统例子，通常为水平 LOB 所
特有。在大多数情况下，客户在被不同 LOB 支持的产品中拥有帐号，例如，股
票、.证券和外汇。在月末发送多个声明将会十分混乱。法律和一致性问题还
需要交叉引用多个仓库的数据。Patriot 和 Sarbanes-Oxley Acts (一个新的业务流
程，但是不赚钱)的一个主要问题是要访问由大量 LOB 所拥有的数据，有时还要
环绕半个世界。EAI 技术和消息收发试图借助早先阐明的限制解决这些问题。
通向灵活性的道路：以 BPM 为中心的 SOA
让我们考虑带有 Web 服务的、以 BPM 为中心的 SOA 如何将现有的遗留企
业转换为自适应性的企业。水平流程和异常管理是用于 SOA 启用的理想候选者，
可以演示可调整的和速度快的 ROI。没有经历业务流程再造的严谨，我们必须定
义良好的流程图。流程图也是实行业务流程重新设计的第一步。如果使用 BPMS
设计工具(Proactivity, Intalio, Interfacing Technologies)，您可以把度量关联到流程
和行为，例如，性能、开销、IT 资源、FTE、逝去的时间、容量，等等。许多 BPMS
设计工具允许您运行模拟，并继续进行流程优化（运行 what-if 场景），但是这
并非本文的重点。对于我们的重点来说，以下列出的是良好流程图的一些特征：
· 考虑流程而不是功能 : 流程告诉您完成什么工作以及如何完成。功能描述谁
在哪里来完成它。
· 从客户的观点出发： 考虑从外部业务事件开始的流程，例如，一次交易、一
份订单、一个主张、一个报价请求。
· 在更宽泛的意义上并基于不同的服务质量来划分客户类别： 您生态系统中的
性能、供应商、业务伙伴。
· 流程反映状态变化：交易订单、现金支付。从可管理的流程数量 6－10 开始。
记住，大多数人最多只能保留一个页面上的七样东西。
· 定义核心流程和子流程：这里没有科学理论，只有最佳实践。然而，要当心
P-calculus2 和 Petri-nets；它们将在接下来的 10 年内带给 BPM 科学的严密性。
· 将流程分解为行为
下一个目标是通过分解行为来定义小单元。我们将这项工作称为 Elementary
Business Services (EBS)。如果您从多维矢量代数开始回想，空间中的任意一点都
可以被定义为单元矢量的线形组合。在我们的例子中，我们以可以通过编排 EBS
子集来构造任何流程的方式定义了所有 EBS。正如您可能猜想的那样，我们将
EBS 实现为 Web 服务。识别 EBS 的正确集合和粒度水平很重要。这与设计对象
的重要程度相同。相同的规则和技术——封装、状态相关性、内聚性、松散耦合
和重构——同样适用，这并不使人惊奇。
EBS 的业务量体现出了大量实际优点：
1. 它是要重用的最终指南。可以通过任何想像得到的方式编排 EBS，以形
成新的 LOB。
2. 连续性流程改进不必等到 IT 适应新的业务模型。
3. EBS 对企业生态系统中的企业和业务伙伴可用。
4. 放弃使用一个系统并不是一个一蹴而就的过程，而是一个循序渐进的过
程。
5. 可以以一种易于管理且性价比高的方式合并和获得 IT。
6. 可以几乎实时地设计和执行一个新的业务流程。
从图 4 中可以看出，我们可以使 EBS 在 BEA WebLogic Platform （集成
组件）的一个实例中可用。从技术上说，在 BEA WebLogic Integration 中，Web
服务被称为业务流程资源。我们使用 IDE 编排新流程，使用门户添加 UI，然后
将它部署为一组 EJB 来执行。就是这么简单！现在流程是一项 IT 资产了，就像
数据库表、存储过程、遗留 COBOL 书籍和专用的计算 c 库。
（图 04）
许多金融服务机构的业务分类是水平的，管理高净值的私有客户。在启用
了 BPMS SOA 的企业中，开发 IT 基础结构来支持这样的新 LOB 完全可以与正
确放置业务模型并行完成（参见图 5）
（图 05）
考虑 现象，它们并没有创造任何新的 EBS。所有 EBS 位于任
何其他邮件订单一览表书店中的恰当位置：定购书籍，检查库存，信用卡付帐，
打印声明，准备装运，给客户发送电子邮件。但是它没有创建新流程，没有质疑
已经建立好的流程，甚至不用花费什么力气。
正如 Howard Smith 和 Peter Fingar 所说的那样：“在 BPM 的第三次浪潮中，
筒仓式思考和点到点的技术集成被灵活的、基于业务流程的体系架构所代替。”
此外，Gartner Group 现在声明，继续将业务逻辑硬布线到软件或中间件中或者
坚持人工步骤的公司将输给部署流程管理体系架构的竞争对手。
实时处理业务
退一步说，预测将来是很困难的事情，但是我们用非常科学的态度对待它，
而且始终试着这么做，不管对还是错。统计和预测是关于预测将来的两门科学。
投资组合评估和保险统计研究是有关预测的科学。实际上，我们的预测仅仅基于
我们已经经历过的、过去的性能和趋势。实时处理业务需要预测未来的业务情况。
然而，基本的业务协议和框架必须合适。今天，技术革新、BPMS 和 SOA 是将
业务目标与 IT 相结合的基础。流程提供一个封装了变化的新层。90 年代早期，
PowerBuilder 和 VB 风格的工具使客户端/服务器和关系数据库系统的开发流行
开来，通过与此相同的方式，BPMS 引擎将在未来建立流程驱动的企业。事实上
我预测，在我们的一生中，我们将看到对运行时流程的需求，该类流程用于实时
变化或对自修改流程的需要。无疑，人类希望能够掌管该类变化，但是通过使
用 UDDI-š (š 代表流程)找出最可能的服务契约和使用描述域专业知识和市场情
况的规则进行决策，BMPS 能够使这项工作更加容易。随着 BPMS 的普及，灵活
性将被极端自适应所代替。
结束语
在本文中，我描绘了合并 SOA 和 BPM 的蓝图。从一幅企业的自顶向下流
程图开始，我们定义了基本业务服务的组合选择。垂直 LOB 拥有并部署 EBS。
Web 服务实现它们，并使它们对企业可用。通过使用 BPMS 引擎的一个实例，
可以设计、开发、测试新的流程，并通过结合现有的 EBS，在数日内添加业务值。
在我的下一篇文章中，我将：(1) 讲述用于给现实世界业务保险流程建模的
BPM 技术，并提出一个纯 BPM 解决方案和一个混合解决方案；(2) 使用 Web 服
务和 JMS 连接设计 EBS 并实现它们；(3) 提出一个使用 WebLogic Platform
的物理基础结构；并 (4)讨论面向服务体系架构中的 BPMS 难题和新出现的模式。
直到：流程无处不在。您能发现它们吗？
(三)简单到复杂，BPM 技术促进 SOA 发
展
CNET 中国· 类型:转载 作者: csdn 责编:小蝎 时间:2006-10-23
BPM(企业流程管理，Business Process Management) 与 SOA (服务导向架构，
Service Oriented Architecture)各自历经多年的发展，越来越成为人们的焦点。 众
多厂商成为了 SOA 技术架构的推动者，其中包括 IBM、BEA、HP、Oracle 和
SAP。
SOA 可以看作是 B/S 模式、XML/Web Service 技术与管理软件的结合。它通
过组合单独业务和流程实现复杂的业务应用，而这些业务功能和流程称为服务，
SOA 把业务流程视为独立于应用程序及其运行的平台的可复用组件。 从 SOA
概念提出以来，越来越多的主流厂商开始了 BPM 与 SOA 的应用。今年 3 月，
BEA 收购 Fuego 扩展 SOA 到 BPM 软件，以此使用新的 BPM 升级 SOA 平台。2
月，HP 和 Oracle 集团宣布，HP 的服务咨询和集成（Services Consulting &
Integration）将会同 Oracle 的 Fusion 中间件，加入到它的 SOA 的投资组合以及
HP OpenView 管理软件套件，以 Fusion 融合 SOA。去年，Oracle 收购了 BPM
专业公司 Collaxa；SAP 重新设计软件，以便集成自由版本的面向 BPM 的中间
件 NetWeaver。
除平台提供商以外，开源厂商也试图占领拥有自己的 SOA 却缺乏服务的市
场。JBoss 公司在 2005 年 10 月发布的企业过程管理引擎，围绕业务过程执行语
%20
言（Business Process Execution Language BPEL）提供了一种可插拔的体系结构、
扩展的任务管理以及新的可扩展性。BPEL 虽然是用来编排 Web 服务的，但依然
适合用来集成，而不是深入的业务逻辑。 BPM 无论从技术还是方法上都将促
进 SOA 的发展。在此过程中，大型平台厂商 IBM、BEA、SAP、Oracle 等将会
尝试建立一种新 SOA 标准；而开源厂商努力构建一套工具，不把自己禁锢于用
一种方法构建 SOA。 从 BPM 的 IT 需求与 SOA 技术角度上看，BPM 与 SOA
的融合也具有先天优势。BPM 的范围覆盖了企业运营的各个环节，如生产、销
售、物流、财务等企业经营活动，甚至延伸到供应商和经销商。其产品开发包
括 6 个部分，从基础开始为：开发语言，如 BPEL、Java 等；BPM 服务器，包
含 EAI/BPM 平台产品；BPM 工具，包括用户接口工具、过程建模工具、软件需
求工具等；BPM 套件；BPM 知识架构；BPM 系统和其应用。由此可见，BPM
的 IT 需求与 SOA 技术具有以下相似点： 1．BPM 涵盖范围广泛，需要完成因
事件触发的完全不相干的事件，此特点正与 SOA 的松散耦合特点相吻合。
2．BPM 需要多部门、区域的协同。在此中环境中网络环境的安全性可由 SOA
技术构架中的 WS-Security、LDAP(Lightweight Directory Access Protocol-轻量级
目录访问协议)、PKI(Public Key Infrastructure-公钥基础设施)架构和数位签章等机
制来完成。 3．BPM 系统构成元素种类繁多而复杂，包含分布于各模块的企业
逻辑和规则。而 SOA 可以看作是 B/S 模式、XML/Web Service 技术与管理软件
的延续。
当前多数 SOA 环境能提供系统管理工具给系统管理员使用，协助管理 SOA
架构下模块的安装、移除、启动等。目前能够实现 SOA 的产品包括：Microsoft
Biztalk Server, webMethods Business Integrator, IBM SeeBeyond, TIBCO 和
Vignette。在 SOA 提出以前，大部分 BPM 产品在流程图中采用自有定义流程逻
辑。 4．企业 BPM 系统的实施往往从最简单的开始，逐渐提升为复杂的 BPM
系统。而 SOA 模块化的特性正好吻合了此特性。
(四)分析:BPM 与 SOA 之间的区别及联
系
CNET 中国· 类型:转载 作者: newhappy2008 责编:小蝎 时
间:2006-10-23
关于业务流程管理(BPM)和面向服务架构(SOA)之间关系的讨论热闹非凡。二
者也是多年来的热门话题，但是关于它们的讨论通常都出现在互不相关的论坛上，
讨论它们的人通常也属于不同的圈子。不过现在这种情况正在改变，因为这两个
概念以及相关技术的使用者和提供者正日渐将二者结合起来看待。
BPM 阵营通常声称，SOA 对于实现 BPM 来说不是必需的。只需部署一个 BPM
套件，就可以更快地实现目标而不会带来多少复杂性。SOA 阵营则注重于如何
从一般意义上解决企业 IT 的复杂性。该阵营通常声称 BPM 是 SOA 的一个特性，
但是它是 SOA 解决方案的一部分，而不是一个单独的东西。当 SOA 领域的人士
%20
谈到 BPM 时，该术语通常与服务编排或流程整合同义，而不强调对业务分析人
员友好的建模或人员交互，而后者对 BPM 阵营来说非常重要。
为了澄清这些误解，我认为有必要阐明 BPM 与 SOA 的不同本质:SOA 是一种
架构方法;BPM 则是一组协调活动。
因此，可以很容易地得到使用 SOA 或不使用 SOA 的 BPM，反之亦然。我们
来看看不同组合的优点。
如果部署一个不使用 SOA 的 BPM 套件，则可以获得快速创建、执行和监控/
管理业务流程的能力。业务流程的模型可以由业务分析人员创建，但是其完整实
现则需要与底层 IT 系统的集成(以及定义用户如何与该流程交互，但是现在我们
暂不考虑)。BPM 套件(如 BEA 的 AquaLogic BPM Suite)支持使用各种不同的技
术(面向服务的或不是面向服务的)对应用程序和数据库进行轻松访问。实现由代
码和来自于并依赖于底层系统接口的元数据组成，因此，对底层数据库和应用程
序的任何更改都将导致对业务流程的更改。
如果组织和 IT 环境规模比较小，并且由同样一组人来控制所有的系统(包括
BPM 套件)的话，这是完全可以的。如果底层系统完全不更改的话，这种方法同
样运行良好。
但是，如果 BPM 套件由一个小组部署，并消费来自另一个小组的系统的服务，
那么协调和管理每个小组中的更改的任务很快就会变得非常困难。这是 SOA 要
解决的典型问题，因此，SOA 可以应用于 BPM 套件的部署，就像应用于其它地
方一样。
如果 BPM 作为 SOA 的一部分进行部署，这意味着当一个业务流程连接到底
层系统时，它连接到由企业服务总线所提供的代理服务，这样就隐藏了底层应用
程序和数据库的复杂性。这具有以下优点:
将业务流程连接到系统的过程会更简单，因为 IT 可以公开更有用的接口，比
如聚合的数据服务或使用标准协议而不是专有协议的服务。这减少了实现流程所
需的 IT 工作量，并允许流程人员将精力集中于流程，而不是粘合流程与底层系
统所需的技术。
它使得实现更为健壮，因为对底层 IT 系统的更改不必影响流程所使用的接口。
它在 BPM 套件之外提供了一个独立的控制和管理层。这允许 IT 小组更好地
管理他们所拥有和维护的服务的策略和资源。
SOA 还支持从 BPM 套件中获得对它所连接到的系统的更好可见度。IT 小组可
以在服务注册库中注册服务，流程开发人员(甚至可能是业务分析师)可以在构建
流程时浏览这样的注册库。这确保了服务可以被正确地使用和重用，而且通常简
化了业务流程，因为使用正确的服务可以将流程本身的复杂性降至最低。
无疑，这些优点只有在 IT 基础架构足够复杂，并且/或者 BPM 项目达到一定
的范围和规模时才能显现出来。因此，在很多情况下，应该首先开发出 BPM，
而将 SOA 组件留待以后考虑。
最好的方法是一开始就让业务运作团队和 IT 企业架构小组保持良好的对话，
并针对未来进行规划，同时支持战术性执行。这就需要正确地组合产品。例如，
BPM 套件本身应该能够提供丰富的连通性，以便无需全面应用完善的 SOA 来使
得 BPM 运行，这一点非常重要。类似地，BPM 套件应该支持 SOA，这样 BPM
与 SOA 才不至于存在于独立的竖井中，这也很重要。
(五)OASIS 总裁 Patrick Gannon 谈
SOA 与开放标准
CNET 中国· 类型:转载 作者: Cnet 责编:小蝎 时间:2006-10-23
Patrick Gannon：今天来给大家介绍一下 SOA 对产业的一些好处和标准对产业
的一些影响。这一页是我的简单介绍。主要介绍一下开放标准和 SOA 对公司的
发展有哪些影响。今后的电子商务将会搭建在 SOA 的平台上，现在 SOA 和开
放标准还处于初期阶段。这一页幻灯片是介绍了一下 SOA 的基本情况。为了达
到 SOA 所承诺的前景，需要建立一个共同的框架体系和标准体系。公司要在
SOA 投资，必须要获得一些收益，这样保证他们的资产有更好的流动性，也保
证他们的资产有长期保值的能力。所谓流动性就是灵活多样的意思，也就是说
SOA 的标准体系和核心技术要能够满足各式各样应用的需求。SOA 很重要的特
性是能够让你对软件的投资有长期的保值性，能够避免重复投资，可以让你的软
件模块可以重复地使用。
为了达到这些目标，有一些很基本的工作需要做。我们必须要有一个共同的
体系结构和一套共同的词汇表，大家都知道每一个软件的变量代表了什么意思。
现在的问题是各个行业一些主要的技术厂商，他们看的都局限于他们这个行业或
者是自己的技术体系来考虑整个软件应用的问题。这个问题是不同的词汇表，不
同词汇的意义和不同的表示方法都对使用软件技术的发展带来了障碍。我们的解
决方法是什么？在商业业务层面创造互操作性。
其中一个方法是实现跨部门的应用互动和应用的集成。为了达到这个目标，
开放标准是其中一个很重要的措施。很多公司问为什么我们需要标准？我们看到
为了建立标准体系需要很多的投入，一个标准组织就是为了让业界的企业一起共
同做标准的工作，降低大家分头做标准的成本。软件公司需要知道他们做什么标
准、同时应该了解标准是怎么产生的，通过什么样的方式使标准有一个基本的接
受情况。我们请了 Delphi Group Research 做一个标准的调研，看整个企业对标
准的认识，和目前对标准研究的看法。有三个重要的调研结果。采用开放标准使
得企业的软件可以重复使用，数据也可以在不同的平台上进行共享。第二个结论
是采用了开放标准，企业的研发工作可以在更大的协同范围，甚至是摄入最终用
户来进行共同的开发。我们看到开放标准对于 Web Service 的使用是非常重要的。
%20
OASIS 是一个国际标准组织，主要是针对先进的结构化数据的信息标准。
OASIS 不光只是研究和产生标准，同时也跟其他国际组织一起合作来推动标准
的采用和技术的发展。OASIS 有一个非常开放的组织结构，可以让会员很容易
在组织里面表达自己，目前有 650 个不同的企业会员，来自 80 个国家。OASIS
在 Web Service 、电子商务、eBusiness 和文档管理方面是目前世界上权威的标
准组织。通过 13 年的努力，OASIS 已经得到广泛的承认，OASIS 不仅可以直
接向国际标准组织、国际电联和联合国相关标准组织直接提交标准提案。
OASIS 不光只是由技术厂商参加的标准技术组织，实际上有 35％的成员来自
于客户，也就是说可以对甲方有影响力的部门，还有大概 15％的研究单位。
OASIS 也是一个发展很快的组织，我来中国很重要的目的是希望能够参与快速
发展的亚太地区的经济活动。
这是 OASIS 在亚太地区目前的成员，这是在大陆地区的会员成员，我已经参
观过了书生、长风联盟和神州数码，以及互联网中心。根据我这个星期在这边的
感觉，我认为很快会有更多的公司参加 OASIS 这个组织。我邀请大家能够参与
OASIS 这个组织。
OASIS 是为 SOA 和 Web 服务的发展提供重要的指导作用。OASIS 的工作
覆盖了 SOA 和 Web 服务一些非常重要的领域。这是 OASIS 在 SOA 和 Web
服务里重要的领域和技术工作组所覆盖的一些 SOA 和 Web 服务的重要领域。
OASIS 不但是推动标准的研发和发布，也推动标准的全面采用。OASIS 是有 25
个技术委员会在 SOA 领域里展开技术的研究工作。对于公司对 eBusiness 有兴
趣的公司，有一个商业编排工作组。标准、访问权限控制也是 OASIS 在 SOA
和 Web 服务领域里的重要工作。
Web 服务的管理也是我们一个很重要的技术研究工作。可靠的消息传输也是
我们的工作之一。这是 UDDI 部分的工作。你们看到在 OASIS 里对 SOA 和 Web
服务做了大量的研究和标准建设工作，这也是很多公司参加 OASIS 的直接目的。
大家都知道当一个公司在新技术方面做投入时都会涉及到一个潜在的风险。SOA
可以帮助公司降低采用新技术的风险。企业今天可以做什么呢？一个是可以参
加 OASIS 组织，或者是可以观察、了解一下 OASIS 组织能做什么。因为这些
标准都是在全世界推广和采用的，所以非常重要的是要让在中国的软件企业或者
是中国的最终用户能够对他们的技术需求和他们的一些要求很明确地表示出来。
表示出来以后，能够影响标准的产生，而且标准是在全球范围内推动的。其中软
件公司在 OASIS 的工作是提出新的研究方向。其中一个例子就是书生公司已经
在上个星期提出了 UOML 在 OASIS 里立项。我相信肯定有很多其他的公司可以
把他们创新性的技术提案通过 OASIS 这个平台建立起来。对于小的公司，没有
很多钱来参加像这种标准组织的话，也可以多看一看标准组织能不能对你们的市
场活动带来好处。
除了标准的研究工作以外也跟很多组织合办活动，把会员的一些技术在更大
的范围里展示。对于最终客户来说，OASIS 对他们也有很多好处。对于最终用
户如果能够把他们对技术的需求明确提出来之后，可以在明确的过程中考虑进去。
OASIS 有很多会员是政府部门，这些政府部门参加的原因是他们希望观察标准
的研究情况，对标准提出一些建议。这些政府部门也利用 OASIS 平台来了解哪
些技术方向值得政府的资助，对参加这些研究方向的企业优先考虑进行资助。对
于开放标准和 SOA 的研究，希望能够邀请和 OASIS 一起共同讨论 SOA 和开
放标准的工作
(六)业界观察：为什么 SOA 如此得势？
【正文】
作为未来的技术趋势之一，SOA 正无可争议地引领着软件业的新一轮浪潮，
并在未来给软件和网络带来革命性的变化。为什么 SOA 如此得势?这是因为
SOA 改变了过去开发应用的模式，将软件按照业务需求定义成“组件”，作为共
享资源，提供以服务为中心的应用软件设计方法。这种方法，能够提高 IT 对业
务的响应能力，使企业得以实时支持业务的变化，最终帮助企业转变为服务驱动
型企业。
早在 2002 年 Gartner 就预测，到 2008 年，SOA 将成为占有绝对优势的软件
工程实践方法，它将结束传统的整体软件体系架构长达 40 年的统治地位，届时，
将有 70%的企业在进行企业 IT 建设时会转向 SOA。从技术上讲，SOA 并不是一
个新概念，早在 20 世纪 90 年代中期，Gartner 就提出了 SOA 的概念，但当时的
软件技术发展和信息化水平还不足以使它走入实用阶段。进入 21 世纪，随着
Web 服务等相关标准的出现和成熟，SOA 开始从概念走向实用。
SOA 不是某个产品，也不是某个技术，而是一种软件设计架构和方法。SOA
要求开发者从服务集成的角度来设计应用软件，它将应用程序的不同功能组件定
义为“服务”，通过“服务”之间的良好接口联系起来。(也就是“服务”之间的松耦
合。)接口是采用中立方式进行定义的，独立于实现“服务”的硬件平台、操作系
统和编成语言。而且这些构建在各种各样系统中的“服务”可以以一种统一和通用
方式进行交互。保证系统灵活性，另外，还可以保证“服务”的重复利用。
由此可以看出，SOA 的核心概念是“重用”和“互操作”，从而使企业的 IT 系
统拥有极大的灵活性。SOA 的另一层意义就是整合，它将企业的 IT 资源整合成
标准的、可操作的服务，使其能被重新组合和应用。在这种架构下，IT 系统的
复杂性并没有增加，相反，随着系统的不断完善，整个系统的架构将变得更加清
晰。
现在随着网络技术的发展，企业在信息化建设中产生了大量为满足产品或服
务需要的软件系统，如:ERP、CRM、OA、SCM 等一系列 IT 软件系统。但这些
系统一般都是单独实施、独立存在的，由于数据标准不统一，接口不一致，系统
间往往缺少联系与合作，这也就导致了一个系统成为一个“孤岛”。而基于 SOA
的理念，则使企业在需要改变 IT 系统时的灵活性大为增加。
SOA 架构定义了搭建企业软件架构的一种新方法，它的出现使所有应用在
交换数据和处理过程中，不需要考虑应用软件是用什么编程语言开发的或在什么
操作系统下运行。在这种模式下，一个应用或应用的一部分其实是一种服务，其
他的应用和客户都可以在无需编写大量代码的情况下使用这些服务，这一切都使
一些大企业或在地理上分布范围比较广的开发队伍能够更好地合作，因为这些
SOA 架构下的中间件业务模块都能够被重新配置或以新方式优化来满足新的需
求。正是 SOA 的重用性和互操作性所带来的灵活性实现了企业 IT 资源整合，使
企业 IT 资源真正面向于服务。
SOA 作为一种概念虽然已经成熟，并得到了国内外主流软件开发商和企业
客户的认可，目前主流软件厂商均已经完成了基于 SOA 的改造，但在客户端大
规模的应用还有许多事情要做。首先，它包括一系列技术和规范，面临诸多挑战，
尤其在项目开发初始，付出的代价要比传统软件项目大得多。其次，实现 SOA
的 Web 服务技术尚不成熟，标准还处在发展之中。目前，很多企业对于 SOA 的
认识还仅限于一种“整合”IT 技术的概念，人们对于 SOA 认识的误区还有很多。
面向服务架构（SOA）的原则
Web service 已经不再是新婚的娘子。众多企业都已经创建各种实验性 Web Services
项目，事实证明，这项新兴的分布式计算技术确实能够降低集成和开发的成本。另外，
一些关键的 Web Ser
vices 标准纷纷制定，强安全（robust security）和管理方面的产品也陆续问世。对
于志向远大的企业来说，他们已经在考虑下一步了。
对大多数公司来说，下一步要考虑的不再是点对点的应用，而是 Web services 在企
业间以及业务伙伴间更为宽广的应用。这种技术的变迁需要更松散耦合、面向基于标准
的服务的架构。这样一个架构要求对 IT 在组织中的角色有新的观点和认识，而不仅仅
是一种实现方法。通过对业务的敏捷反应，企业可以得到实实在在的回报，而要达到这
一点，面向服务架构设计师的角色非常关键。除此之外，潜在的回报更是不可胜数－分
布计算技术能够保证对业务需求足够灵活的反应，而这种业务上的敏捷正是各公司梦寐
以求而目前还遥不可及的。
分布式计算将网络上分布的软件资源看作是各种服务。面向服务架构是一种不错的
解决方案。但这种架构不是什么新思想；CORBA 和 DCOM 就很类似，但是，这些过去
的面向服务架构都受到一些难题的困扰：首先，它们是紧密耦合的，这就意味着如分布
计算连接的两端都必须遵循同样 API 的约束。打比方说，如果一个 COM 对象的代码有
了更改，那么访问该对象的代码也必须作出相应更改。其二，这些面向服务架构受到厂
商的约束。Microsoft 控制 DCOM 自不必说，CORBA 也只是一个伪装的标准化努力，
事实上，实现一个 CORBA 架构，经常都是在某个厂商对规范的实现上进行工作。
Web services 是在改进 DCOM 和 CORBA 缺点上的努力。今天应用 Web services 的
面向服务架构与过去不同的特点就在于它们是基于标准以及松散耦合的。广泛接受的标
准（如 XML 和 SOAP）提供了在各不同厂商解决方案之间的交互性。而松散耦合将分
布计算中的参与者隔离开来，交互两边某一方的改动并不会影响到另一方。这两者的结
合意味着公司可以实现某些 Web services 而不用对使用这些 Web services 的客户端的知
识有任何了解。我们将这种基于标准的、松散耦合的面向服务的架构简称为 SOA。
SOA 的强大和灵活性将给企业带来巨大的好处。如果某组织将其 IT 架构抽象出来，
将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值，那么，这
些服务的顾客（可能在公司内部，也可能是公司的某个业务伙伴）就可以得到这些服务，
而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现并绑定可用的服务，
那么在这些服务背后的 IT 系统能够提供更大的灵活性。
但是，要得到种强大和灵活性，需要有一种实现架构的新方法，这是一项艰巨的任务。
企业架构设计师必须要变成“面向服务的架构设计师”，不仅要理解 SOA，还要理解 SOA
的实践。在架构实践和最后得到的架构结果之间的区别非常微妙，也非常关键。本文将
讨论 SOA 的实践，即：面向架构的设计师在构建 SOA 时必须要做的事情。
SOA 的原则
SOA 是一种企业架构，因此，它是从企业的需求开始的。但是，SOA 和其它企业
架构方法的不同之处在于 SOA 提供的业务敏捷性。业务敏捷性是指企业对变更快速和
有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个
业务敏捷的架构意味着创建这样一个 IT 架构，它可以满足当前还未知的业务需求。
要满足这种业务敏捷性，SOA 的实践必须遵循以下原则：
* 业务驱动服务，服务驱动技术
从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一
方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服
务与提供这些服务的底层技术之间的关系。
* 业务敏捷是基本的业务需求
SOA 考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是
处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的
需求，因为，在 SOA 中任何的瓶颈都会影响到整个 IT 环境的灵活性。
* 一个成功的 SOA 总在变化之中
SOA 工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋房子”。IT
环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。对于习惯于
盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。如下文所写的，
SOA 的基础还是一些类似的架构准则。
SOA 基础
在 IT 行业有两个越来越普遍的发展方向，一个是架构方面的，一个是方法学方面
的，面向服务的架构设计师可以从中有所收获。第一个就是 MDA（模型驱动架构），
由提出 CORBA 的 OMG 模型提出。MDA 认为架构设计师首先要对待创建的系统有一
个形式化的 UML（也是由 OMG 提出）的模型。MDA 首先给出一个平台无关的模型来
表示系统的功能需求和 use cases，根据系统搭建的平台，架构设计师可以由这个平台无
关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成
需要的代码。
MDA 的核心就在于在设计阶段系统就已经完全描述，这样，在创建系统的时候，
几乎就没有错误解释的可能，模型也就可以直接生成代码。但 MDA 有一些局限性：首
先，MDA 假设在创建模型之前，业务需求已经全部描述，而这一点，在当前典型的动
态业务环境中几乎是不可能的。第二，MDA 没有一个反馈机制。如果开发人员对模型
有需要改动的地方，并没有提供给他们这么一个途径。
SOA 的另一个基础是敏捷方法（AM），其中非常有名的方法是极限编程（XP）。
象 XP 这样的 AM 提供了在需求未知或者多变的环境中创建软件系统的过程。XP 要求
在开发团队中要有一个用户代表，他帮助书写测试来指导开发人员的日常工作。开发团
队中的所有成员都参与到设计之中，并且设计要尽量小并且非形式化。AM 的目标是仅
仅创建用户想要的，而不是在一些形式化模型上耗费工作量。AM 的核心思想就在于其
敏捷性－处理需求变更的敏捷性。AM 的主要弱点是其规模上的限制，例如，XP 在一
个小团队和中型项目中效果不错，但是当项目规模增大时，如果没有一个一致的清晰的
计划，项目成员很难把握项目中的方方面面。
从表面看来，MDA 和 AM 似乎是相对立的－MDA 假定需求是固定的，而 AM 恰恰
相反。MDA 的中心是形式化的模型，而 AM 恰恰要避开它们。但是，我们还是决定冒
险把这些不同方法中的一些元素提取出来，放入到一个一致的架构实践中。
在 SOA 中有三个抽象层次，按照 SOA 的第一条准则：业务驱动服务、服务驱动技
术。AM 将业务模型直接和实践连接起来，表现在平台相关的模型之中。MDA 并没有
把业务模型和平台无关模型分开来，而是把平台无关模型做为起点。SOA 必须连接这
些模型，或者说抽象层次，得到单一的架构方法。我们将从五个视图的架构实现方法来
实现这个连接。
SOA 的五视图实现方法
企业架构设计师发现他们的职业非常有竞争力并且值得骄傲，因为他们要从很多方
面来通盘考虑 IT 系统。Kruchten（RUP 的开发负责人）将这些方面提取出来，在应用
到 SOA 时，我们称为五视图实现方法（five-view approach）。
四个方框表示对一个架构的不同审视方法，分别代表不同的涉众（stakeholder）。
弟五个视图，use-case 视图涵盖了其它视图，在架构中扮演的是一个特殊的角色。部署
视图将软件映射到底层平台和相关硬件上，是系统部署人员对架构的视图；实现视图描
述了软件代码的组织，是从开发人员角度出发的视图；业务分析人员则利用过程视图进
行工作，它描述的是软件系统的运行时特性。最后，逻辑视图表示的是用户的功能需求。
在 SOA 中，面向服务的架构必须能够以 use-case 视图中的用例将用户连接到服务，将
服务连接到底层的技术。
为了表示面向对象的架构是如何工作在这些视图之上，让我们将他们置于 SOA 元
模型的上下文之中。SOA 中两个领域存在重叠：由业务模型和服务模型表示的业务领
域和由服务模型及平台相关模型表示的技术领域（两个领域共享服务模型）。业务用户
通过逻辑视图和过程视图处理粗粒度的业务服务，根据变化的业务需求，按照需要将它
们安排在过程之中。另一方面，技术专家的工作是创建并维护服务和地层技术之间的抽
象层。表示这些服务的中间模型，起到的是轴心的作用，业务以它为中心进行。
SOA 元模型从 MDA 中继承平台无关模型和平台相关模型，但是添加了 AM 和用户
交互以及敏捷的反馈这两部分，后者通过椭圆之间的双向箭头来表现。类似地，元模型
通过引入由中心的服务模型提供的中间层抽象解决了 AM 在伸缩性方面的问题。这样，
服务模型中的任何需求的变化，都会反映到用户每天的业务处理中。同样，由于底层技
术是模型驱动的，技术专家也可以根据这些变化的需求迅速而有效地作出应变。
SOA 实践和过去解决企业架构传统方式的不同之处就在于其对敏捷性的支持。如前
所说，SOA 的第三条原则就在于它总在变化之中。这种恒在的变化性环境是 SOA 实践
的基石。如图所示，涉众（stakeholders，译者注：RUP 中也有这个词，表示软件开发中
涉及到的各种角色如：用户、设计人员、开发人员乃至测试人员等等。）在一个必需的
基础上影响到整个架构的变化。在当技术专家在每天的日常工作中不断对变化的业务需
求作出响应的这种情况下，设计阶段和运行阶段之间的界限变得模糊起来，很难清晰地
分离这两个阶段。
剩下的部分
我们已经为面向服务的架构提供了一个高层次的框架，其中 MDA 和 AM 的元素帮
助工具的使用者来创建和维护 SOA。但是，SOA 中还缺少一些内容－那就是软件开发
商和专业的服务组织必需提供的。理想情况下，开发商必需提供面向服务的业务流程、
工作流以及服务的协调工具和服务；另外，能够以一种敏捷的、平台无关的方式充分反
映业务服务的建模工具也是必须的；技术专家必须配备可以从模型中自动生成代码，并
在代码变化时更新模型的工具，最后，开发商必须提供支持 SOA 的软件，帮助面向服
务的架构设计师以一种可信并且可伸缩的方式创建位于服务和底层技术之间的抽象层
次。幸运的是，这方面的产品即将上市。
另外，最重要的就是贯穿本文的自顶而下的 SOA 实现方法了。今天关于 Web
services 的大部分思考都是自底而上的：“这是如何创建 Web services 的方法，现在，我
们来使用它们集成吧”，对 Web services 技术的这种方法是伟大的第一步，因为它可以
惊人地降低集成的开销，这是现在的技术管理人员最乐意见到的了。但当经济进一步发
展，IT 走出低谷，企业会寻求 IT 的帮助来提高组织战略意义上的核心价值。使用面向
服务的架构，IT 可以提供给企业实现业务敏捷性的这样一个框架。
