SOA&Web 2.0:新商业语言

★IBM资深副总裁,顶级SOA战略大师Sandy Carter 力作!

［名 家 书 评］
一本正在寻求企业IT成功之道的中国CIO乃至CEO们值得一读的书！
--用友软件股份有限公司董事长、总裁：王文京

［本书最大的闪光点］
Sandy Carter引述了IBM近年来帮助企业开发SOA的案例，这对刚刚起步的企业有很大的借鉴意义。此外，这本书与其说是在传播实现SOA的具体技术，不如说是为企业介绍一些关键的基本理念，为其提供实现SOA所需的正确思想，全书并不涉及如何进行SOA或Web服务应用的实际开发，所以您会发现本书很少有源代码或API讲解。

　　现在，在机构的灵活性和业务表现之间存在一种直接的、可查证的联系。为了将灵活性最优化，企业必须对其内部、外部的关键流程与基础架构实现前所未有的整合与自动化。同时，企业必须学会以更具动态性和反应性的方式来管理流程。
总而言之，企业必须实现灵活应对。
直到最近，技术都一直阻碍着这些目标的实现。正是由于面向服务架构(SOA)、Web2．0和开放标准的出现，才促成企业实现了这些目标。在本书中，IBM的顶级SOA策略家展示了业务经理该如何利用技术创新来推动动态流程的发展，以应对当今世界越来越快的变化。
在本书中，Sandy Calter示范了将企业解构为“组件化”业务模式的方法，然后用相互连接的、可重复的并且能快速、轻松、经济地适应各种变化的IT服务来支持该模式。这些技术将帮助IT专家和业务经理达到崭新的运营水平，以开展着眼于市场的创新，这才是最重要的。

第Ⅰ部分 从起点开始—— 业务

第1章 创新迫在眉睫 3
1.1 专注于增长 4
1.1.1 增长的议程 4
1.1.2 灵活性：一项核心的技能 5
1.1.3 技能：对企业围城内部组织的挑战 6
1.1.4 创新迫在眉睫 6
1.2 关注业务流程，信息是关键 7
1.3 本章小结 9
第2章 什么是灵活应对 11
2.1 灵活应对意味着什么 11
2.2 业务响应：它如何引领您取得成功 15
2.3 本章小结 17
第3章 剖析业务：组件化业务模式 19
3.1 专业化时代的竞争 20
3.1.1 步骤1：剖析业务 20
3.1.2 步骤2：决定哪些业务是企业的独特之处，
哪些业务是一般性的共性业务 25
3.1.3 步骤3：决定如何投资 26
3.2 成功模式 29
3.3 采用CBM创造价值 30
3.4 本章小结 32
第Ⅱ部分 灵活业务需要灵活IT
第4章 SOA是企业灵活应对与创新的关键 35
4.1 SOA的定义 36
4.2 灵活性竞争 41
4.3 为灵活性力求SOA连通性 47
4.4 通过SOA重用，实现灵活性 49
4.5 SOA参考架构 51
4.6 为什么SOA项目能成功以及如何汲取经验 54
4.7 本章小结 57
第5章 关于SOA的重要概念 59
5.1 互操作标准：Web服务 60
5.1.1 定义Web服务 60
5.1.2 松耦合 61
5.1.3 服务粒度 62
5.2 业务服务注册中心和存储库 63
5.3 企业服务总线(ESB) 65
5.3.1 什么是企业服务总线(ESB) 66
5.3.2 ESB的最佳实践 67
5.3.3 支撑业务的企业ESB 75
5.4 协调工作：企业ESB的服务、连通性以及BSRR 77
5.5 SOA生命周期驱动灵活性 78
5.6 本章小结 80
第6章 SOA的监管和服务生命周期 81
6.1 什么是监管 82
6.2 整合的挑战实现了一切 84
6.3 应对未来的整合 85
6.4 SOA监管挑战 88
6.4.1 确立决策权 89
6.4.2 定义高价值业务服务 90
6.4.3 资产生命周期管理 91
6.4.4 有效性度量 92
6.5 SOA监管与生命周期管理的连接 94
6.5.1 服务安全 97
6.5.2 服务管理 97
6.5.3 虚拟服务 98
6.6 通过服务注册中心和存储库连接监管和生命周期管理 99
6.7 如何开始 101
6.8 本章小结 102
第7章 以业务为中心的三个SOA切入点 103
7.1 业务流程管理作为切入点 103
7.1.1 促使业务和IT协作，从而选择最适合的业务流程，最终促进改善 106
7.1.2 使用面向服务架构部署BPM 111
7.1.3 建立业务流程域 112
7.1.4 使用管理仪表板和业务记分卡来管理业务 113
7.2 BPM的最后见解 115
7.3 信息作为切入点 119
7.3.1 通过SOA提供单一的信息源 119
7.3.2 变幻莫测的信息统一视图 120
7.3.3 提高信息的价值 122
7.4 协作作为切入点 125
7.4.1 基于角色的协作观点 126
7.4.2 利用协作工具扩展门户 126
7.5 底线：业务新语言 128
7.6 小结 131
第8章 Web 2.0与SOA之间的关系 133
8.1 什么是Web 2.0 134
8.2 Web 2.0和SOA：灵活性带来的优势 138
8.3 作为新一代平台的Web 142
8.4 促成的商业模式 143
8.5 本章小结 147
第Ⅲ部分 如何实现灵活应对
第9章 十诫 151
9.1 没有SOA，就不要期待商业利益的最大化 152
9.2 不要停留在纯粹的技术层面，要把它看作完成业务的变革途径 153
9.3 不要丢弃原来的所有东西 154
9.4 不要急于拿下过大的项目 155
9.5 不要忘记制订目标 156
9.6 没有通过监管机制进行的彻底文化变革，就无法实现SOA 160
9.7 不要忘记掌握正确的技能 161
9.8 没有开放的标准，就没有灵活性 163
9.9 不要孤军作战，要善于利用有经验的合作伙伴 164
9.10 不要忽视第一个项目的重要性，要有周密计划 166
9.11 本章小结 167
第10章 IBM案例 169
10.1 背景 170
10.2 监管模式 171
10.2.1 CIO领导的企业投资审查委员会 172
10.2.2 企业架构理事会 173
10.2.3 跨功能团队 173
10.2.4 部门功能团队 174
10.3 转型过程 175
10.4 第一个项目 176
10.5 生机勃勃的SOA和重用 176
10.6 确定预期目标 178
10.7 业务度量 179
10.8 企业文化的变革 181
10.8.1 侧重于具有灵活性的横向业务流程 181
10.8.2 侧重于利用重用而不仅仅是新的发明进行创新 181
10.9 正确的技能 182
10.9.1 技术技能 182
10.9.2 将IT和业务结合的技能 183
10.10 本章小结 184
第11章 将所有元素整合 185
11.1 业务增长、灵活性及创新是企业变得灵活应对的结果 185
11.2 如何“推销”SOA 187
11.3 SOA与Web 2.0将成为“激活工具” 188
11.4 在切入点问题上，向其他企业学习是至关重要的 190
11.4.1 人员和协作 191
11.4.2 流程 193
11.4.3 信息 195
11.4.4 连通性和重用 196
11.5 让业务价值成倍增长 201
11.6 监管至关重要 206
11.7 用基础架构和管理来画龙点睛 208
11.8 本章小结 209
术语表 213

书摘
关于SOA的重要概念

旧的世界正在逝去，新的时代正在到来。Mark Colan在一篇关于SOA的文章中(http://www-128.ibm.com/developerworks/webservices/library/ws-soaintro.html)运用了大量的类比方法来定义标准。公元前221年，秦始皇统一了过去一直交战的几个州国，建立了一个新的国家。这个国家就是如今的中国。也许，中国之所以能够在历史的长河中经历住考验，一直屹立于世界的东方，其原因之一就是因为秦朝引入了标准的概念，从而巩固了文化，促进了商业。比如说，他们规定了手推车的标准轮间距，这使得手推车可以在任何道路上快速通行；他们统一了常用书面语言，这样，任何人都可以使用这种语言来传递信息(尽管他们平时所说的方言并不相同)。可以说，秦朝建立了标准(如Web服务)和消息传递与交换(如ESB)的模型，为中国的发展方式提供了灵活性。
与此类似，面向服务架构是一个灵活的IT基础架构的关键。因为灵活的业务和灵活的IT都是必须的，所以公司如果希望向灵活应对的方向发展的话，就必须确保深入了解这两个领域，这一点是非常重要的。在上一章中，我们讨论了涉及到重用、连通性、安全和管理的IT流程的重要性，断言SOA是灵活应对企业的DNA。我们不会很深入地讨论这个问题，但是，企业应该明白一些基本原则，为企业的发展作出英明的抉择。
● 确定企业的机构所需的互操作标准(Web服务)
● 确定企业期望得到的服务以及所需要的服务(业务服务注册中心和存储库)
● 连接企业服务总线(ESB)的各种服务


5.1 互操作标准：Web服务
现在的公司拥有许多各种各样的系统，这导致了一种异构环境的形成。系统之间存在的差异使得我们过去一直深陷于互操作能力匮乏的沼泽中。但是，由于SOA是建立在一个开放的标准上，因此我们能够创造出一种解决方案，在不考虑各个现有的独立系统所处环境的情况下，利用这些系统功能的可移植性或互操作性。
5.1.1 定义Web服务
正如本书前面所讨论的那样，Web服务是一种支持互操作的开放标准方式。Wikipedia认为，Web服务是一种软件系统，其设计出发点是通过网络支持电脑与电脑之间的可互操作的交互。Web服务通常都只是一些能够通过网络(如互联网)访问的应用编程接口(API)，并且它们能够在需要服务的系统远程终端上运行。SOA是一种体系结构类型，能够构建以松耦合的互操作服务为基础的应用。这些服务的互操作是基于规范的定义(或约定，如WSDL)的，这种正规标准并不依赖于底层平台和编程语言。在SOA中，因为通信的基本单元是消息而不是操作，所以Web服务一般都是松耦合的。虽然企业不使用Web服务同样能够实现SOA，但是最佳实践证明，为了获得灵活性，SOA的实现一般都会包含Web服务，因为其注重互操作的灵活性。
从技术上讲，Web服务是以可扩展标记语言(Extensible Markup Language，XML)为基础的。XML是一种包含了结构信息的文档标记语言。虽然XML功能和技术细节不在本书的讨论范围之内，但是XML支持电子商务、数学方程式、对象元数据、服务器API以及其他成千上万种结构信息的处理，这正是企业需要的。XML是一种常用的数据表示法，能够作为一种交流中介，在使用不同编程语言写成和执行不同机器指令的程序之间工作。简单说来，我们可以把XML看作结构信息的官方翻译器。结构信息包括内容(文字、图表等)以及用途。例如，在本书中，对于相同的内容，可以通过标题或注脚来说明其在上下文中所表示的不同含义。
作者认为，作为业务主管，最关键的就是要实现前所未有的供应商合作和大宗买进。与过去不同的是，当各个供应商都还在以自己的方式发展的时候，所有的大型企业(如微软、IBM等)已经达成了Web服务的标准。此外，Web服务是基于标准实体工作的，一些Web服务标准建立在另外一些Web服务标准之上，对前一标准的每一次迭代都能够带来新的业务价值。
XML是所有Web服务技术的基础，也是互操作的关键。每一种Web服务规范都是以XML为基础的。(注意：最为典型的例子是，SOAP是对用XML描述的信息之间的交换进行了形式化处理，而WSDL是使用XML词汇表描述SOAP细节)。
Web服务有以下特征：
● 松耦合
● 服务粒度
5.1.2 松耦合
SOA的一部分价值就在于它以服务的松耦合为前提。松耦合指的是，能够随需应变将多种服务结合在一起来构建不同的组合服务的能力，或者反之将组合服务进行解体，成为功能组件。Per Wikipedia认为松耦合描述了一种方法。通过这种方法，收、发双方在最少的前提约束下建立了整合接口，从而减少因部分应用或模块的变化而引发其他应用或模块变化的风险。
紧耦合则涉及到大段的代码之间的暂时性连接。这种或强或弱的连接的产生是由于这些大段的代码间输入或输出接口没有很好的定义被迫造成的，而连接本身通常必须由定制代码产生。SOA服务之间多是动态和灵活的连接。松耦合则是一种将技术细节(如编程语言、平台等)与服务解耦的简单方式。
例如，货币兑换。目前，所有的银行都提供多种货币兑换业务，汇率随时间而变化。如果企业能够提供一种通用的货币兑换服务，使其与银行兑换业务所需的所有功能保持松耦合的话，那么企业就能通过平衡汇率、时间和抽样来保证以最有效的方式进行交易。再例如，普通客户验证。在大部分交易中，由于普通客户没有ID，因此企业很难确定该客户是谁，购买了哪些产品以及为什么购买，更不用说采集任何关于客户的信息了。但是通过创建独立于应用和数据库的普通客户ID，企业能够在应用或数据库为实现存储客户姓名和地点的情况下，使“客户ID”或“所有实际客户”服务与CRM、数据和应用之间实现松耦合。这种服务通常是以消息请求和回应的简单方式调用的，而不是通过使用API或者文件格式实现。
松耦合可以适用于任何类型的流程：从最基本的数据库调用到重要的两国中央银行之间的金融交易。传统的“紧密边界交互”与现在的松耦合服务之间的差别在于，在事务处理发生之前，SOA中操作的功能模块(服务)是静止的、不相关的。当业务流程启动时，这些服务彼此之间只是暂时地关联。它们只在被执行的整个流程中保持这种相关性，尔后又重新回到静止状态，与之前相关联的模块不再保持相关性。如果下次相同的服务被调用，它可以作为不同业务流程中的一部分提供所需服务。
理解以上说明的一种好方法就是分析我们的电话系统。在电话普及的早期，接线员必须通过手动插线来为通话双方建立一个稳定的临时性通话线路连接。电话双方之间是“紧密边界”的。然而在今天，我们拿起电话放在耳边，此时并没有拨号音—— 因为这时还是不相关的。只有输入号码并按下“通话”键后，该流程才启动，并在通话期间建立了一个松耦合连接。通话结束后，又重新回到了“静止”状态，直到下一个连接再次建立。因此，电话服务商即使拥有一百万个电话用户，也并不需要提供一百万个实时的电话链路，只需要支持在任何时间段的最高通话量就可以了。这样能够增强灵活性，促进动态交易。
5.1.3 服务粒度
作者曾经与客户一起部署过SOA，认为成功的关键取决于服务设计和服务焦点。服务是一种独立于应用及其运行的计算平台的自包含的可重用的软件。它拥有定义良好的接口，能够使业务任务和执行这些任务所需的确切IT组件之间形成一对一的映射。SOA服务则主要关注于业务级任务、活动和交互。服务与流程的关系是至关重要的。业务流程是由相关业务任务组成的集合，其中涉及到产生某特定结果或产品的人员、系统和信息。在SOA中，流程由一组服务组成。
在SOA出现之前，关注的焦点在于狭义的技术性细节。有人称其为一个细的“粒度级别”或一个低度的“抽象程度”。尽管SOA简化了业务流程，但是我们知道，一个流程(如核查信用度)的各个步骤与支持提供灵活的业务流程的服务之间并不只是简单的一一对应的关系。
基于企业的不同业务设计，每家公司对于所需的服务粒度大小都有不同的观点。很简单，粒度就是一个服务所包含的功能的数量。例如，一个细粒度服务提供的是较小的业务流程单元，而一个粗粒度服务提供的则是较大的业务任务，其中包含了数量较多的子步骤。
服务粒度不能太大或太小，而应该大小合适。设计并确定企业的服务粒度大小的决策必须是成功的。如果服务粒度太大，就会降低重用性。反之，如果服务粒度太小，会导致性能问题，以及业务任务与支持其的服务之间的映射会变得非常繁杂。
因此，决定以什么粒度去设计一个服务，不仅仅只是设计复合功能的基本功能单位。例如，在贷款发放中，服务的粒度可能比较粗，因为有太多的不同功能与贷款发放相关联。但是在药物生产中，例如，在研制药物的过程中，药物之间存在大量有效或无效的相互转变；因此，与管理研制流程相关的这些不同“服务”变得非常小，需要细粒度的服务设计级。请记住，粒度常常是业务流程分解的功能单元—— 业务流程越详细，服务的粒度就越细。
服务的这种概念是使SOA成为业务语言的关键之一。大部分业务主管都不关心SOA。相反，他们关注于手头的问题—— 这样做当然无可厚非。然而，正是由于这些业务服务，SOA语言和业务服务间的连接成为了解决手头问题和制定未来战略任务的关键法宝。
5.2 业务服务注册中心和存储库
公司必须处理的最大问题之一就是如何存储和管理新建服务和在特定环境中可重用的服务。让我们来看看图书馆是如何做到的。简单说来，图书馆是一个存放图书的地方(书本可以被重复使用)，为查找书籍、借阅书籍和更新新书的系统提供了一个场所。为了获得灵活的IT环境中的服务，企业需要同样的系统帮助实现可见性、可重用性、适应性和易管理性。注册中心和存储库类似于图书馆中的卡片目录。它不是书架，也不是图书本身；它是图书的元数据—— 图书所在的位置、图书作者、出版日期以及参考文献等。
这种“图书馆”还能帮助企业对业务和IT进行关联，是分享关于业务模型和流程的最佳实践和理论知识的地方，尽管，这只在针对IT而言。业务服务注册中心和存储库(BSRR)是实现灵活应对公司技术可行的关键点。
什么是业务服务注册中心和存储库
业务服务注册中心和存储库(BSRR)是存储已用、计划使用或想要了解的系统(或其他机构系统)中的服务信息的地方。它帮助实现服务语义和缩小IT和业务世界之间的差距的业务含义，并提供服务的业务级视图。例如，一个应用能够在其调用服务之前核查BSRR，确定满足功能和性能要求的最合适的服务。BSRR的首要作用就是促进业务服务的产生、访问、监管和重用。它使得业务、服务以及SOA基础架构元素之间的交互可以集中化管理，并统一了监管服务供应商、用户和服务之间进行交互的标准和原则。总的说来，BSRR促进了业务对象之间的协调关系、IT资产的重用和SOA的逐渐推广。
在市场中，业务服务注册中心能够回答“什么是服务”以及“服务定位于何处”的问题。但是您会发现只有业务服务仓库可以回答下列问题：服务如何被使用、它们之间如何交互、谁在使用这些服务以及为什么使用。如图5-1，为了获得SOA收益，注册中心和存储库都是必须的—— 企业需要同时具备这两种能力，才能实现所需的价值。
对于成功的SOA部署而言，当企业不再局限于第一个独立项目时，BSRR对于有效实现SOA的价值是必须的。企业如果决定构建BSRR，就应该努力获得以下这些能力：
● 发布与查找服务—— BSRR需要具备在机构各部分发布与查找服务的能力，这种能力是重用的关键。同时，这种使服务社会化的能力能够让机构明确通用的服务，避免重复工作，并促进重用。企业必须确保在考虑BSRR的时候，不仅仅支持服务发现和服务重用，同时还支持在各个领域彼此关联的服务，例如，元数据管理。否则企业将无法对服务进行分类，订购改变或更新，或者在改变产生之后，无法及时通知相应的客户。
● 监管—— BSRR需要在整个SOA产品的生命周期中进行管理，从开发、测试、生产直到结束。BSRR要管理整个企业机构中的服务访问权限，确定哪些客户能够进行访问以及能够访问哪些服务。它在整个监管生命周期中通过用户、用户类型和服务发布地点来进行监管。
● 增强—— BSRR需要通过在实时运行的服务之间进行动态、有效的交互，来增强企业连通性。通过利用动态连接，BSRR能够使企业的ESB在请求到达时找到最适合的端点，从而支持动态SOA与松耦合。
● 管理—— 为了促进服务性能的优化，BSRR必须确保政策有效执行，并能够对该政策执行的效果进行分析。它必须能够统一服务测量标准并理解服务性能。这种理解能够帮助业务完成服务级的一致化过程。

图5-1 什么是注册中心，什么是存储库
总之，一个BSRR必须要具备发布服务、查找服务、增强服务、管理服务以及监管服务的功能。但是，一个BSRR是否适合于一个企业，除了要具备上述的这些功能之外，还必须保证服务所支持的互操作是标准的。服务标准对于现有投资与基础构架的利用是相当关键的，比如支持WSDL、XML、XSD、BPEL、SCG与其他的一些支持真正互操作的标准。这种开放标准支持所有标准的注册中心与存储库的整合。企业必须保证，对于各种类型的不同的信息源，BSRR支持统一的视图。请记住，BSRR就像图书馆中的卡片目录，因此它需要具有在整个机构中链接信息源的能力。
5.3 企业服务总线(ESB)
企业服务总线(ESB)也许是SOA产生以来最值得称道的技术。想象一下企业中的SOA：即使企业需要的所有东西都已经具备，但是如果所有的应用、功能、数据或者服务没有通过一种有效的方式连接起来，那么SOA还是不能给企业提供一个灵活的业务。然而，仅仅因为企业使用了Web服务创建了新的服务，或者服务启用现有资产使其成为一种服务，就断定这个企业能够预见到所有可能发生的失败(可能破坏那些编写得天衣无缝的Web服务，给服务的执行平添不必要的麻烦)。读者可以参考第4章关于SOA的文章“SOA是企业灵活应对与创新的关键”其中的内容，可以得知，ESB就位于那个架构的中心。
ESB可以在多个层面上对其进行描述，这取决于需要的连接的复杂程度。
(1) 业务的某些部分仅仅要求能够快速、安全、可靠地将信息从一个应用或服务转移到另外一个应用或服务(或者，实际上有时候是从多个应用或服务转移到多个应用或服务)；
(2) 业务的其他部分想获取这样的信息：是否需要改变它们的程序来处理多种不同的但又必须处理的数据格式，而改变之后它们的程序会不会变得非常复杂。对于这些不同数据格式的表格，它们试图找出对发送格式与接收格式进行匹配的方法。
(3) 业务的其他部分正计划在企业内部移动大量的XML，他们知道这将对处理器的负载产生一定影响：因为每台服务器在处理这些数据集的同时，还要在不同的Web服务之间保证安全性或者处理大量基于XML的数据消息，必将导致处理速度变慢。
企业服务总线(ESB)帮助解决了应用接口潜在的不兼容性和维护冲突的问题。SOA的目的之一就是关注于服务如何支持业务，以及如何具有连接到环境中其他部分的本质能力。ESB使得假设变为现实。
5.3.1 什么是企业服务总线(ESB)
企业服务总线(ESB)可以帮助您实现SOA的目标。它是用来整合应用和服务的一个灵活的基础架构。ESB位于SOA的中心，并通过减少接口的数量、大小和复杂度使得SOA更为强大。ESB主要完成以下5件事：
(1) 服务之间的消息路由
(2) 请求者和服务之间的传输协议转换
(3) 请求者和服务之间的消息格式转换
(4) 处理各种来自不同业务的事件
(5) 保证服务质量(安全、可靠和交互处理)
5.3.2 ESB的最佳实践
在考虑ESB的功能性之前，让我们先来仔细研究一下市场上使用ESB的最佳实践。企业需要不受限制的ESB。这是因为SOA不仅仅需要ESB来解决连通性问题，而且还需要ESB与附加产品的运行环境一起得到扩展，以便形成一个可以充分整合并有效连通的解决方案。因为这种关键的整合技术对于成功实现SOA是相当关键的，所以企业必须规划一个实现连通性和整合的可靠方案。
(1) 连接企业所有有价值的资产—— 如果能将所有资产(不论是否支持Web服务)都绑定到一起的话，企业的SOA将会更加有效。为什么如果某个有价值的资产没有被绑定进来，业务的有效性和竞争优势就势必会降低？许多业务拥有非常有价值但不支持Web服务的资产，例如一些现有的应用、文件、数据库，以及其他类型的基于信息的程序和存储器。在企业业务应用中存在哪些信息和流程—— 并在不改变它们的前提下将它们整合到SOA中去—— 的能力将成为企业向随需应变进化的关键。服务注册中心不仅有助于访问未启用服务的资产，而且对于描述和分类所有可用服务具有重要作用。这样能帮助业务快速编制新的流程，从而支持不断变化的业务模型。
(2) 为服务交互端到端的可见性提供服务监控功能—— 企业的ESB需要为企业业务提供所有资源使用的端到端的可见性能力、配置过程中对出现的问题发出警报的能力，以及深入发现这些问题的能力。事实证明，80%的时间花在了发现并确定问题上，而只有20%的时间真正花在了解决问题上。当企业对ESB进行评估以便作出选择时，确保找到的ESB能够提高业务可见度并能优化信息流。也就是说，企业需要从以下几个方面对ESB进行评估：
● 服务问题的确定与解决
● 服务管理自动化
● 支持不同的SOA平台
● 整合的控制台
● 生命周期管理
如果所有资产的运行都要通过ESB，则企业必须确保具备有效的工具，支持在各种资产通过ESB时对其进行跟踪和管理。
假设企业为实现SOA计划，已经取得了一些成功—— 成功连接了所有平台、应用和服务—— 而且企业的应用和通过ESB的流程流之间具有良好的连接，并可以通过现有的基础架构和新的配置实现互联。
但是现在，当SOA发展起来并开始运行以后，企业需要理解某些特定的功能。如何知道正在发生什么？能否跟踪企业系统中正在发生的事件，是否局限于ESB所告知的情况？在高度互联和相互依赖的SOA环境中，对企业定义的任何情形保持敏锐和警惕是非常关键的—— 这样可以提高业务活动的感知性和自动性—— 否则，将会导致企业发展的瓶颈或失败。
在不受限制的ESB中，需要能够发现问题并尽快解决问题，通过表面征兆找到真正的问题所在。这一点需要贯穿整个生命周期—— 不仅仅只是在单一环境中，而是贯穿整个SOA，跨越多个平台。理论上，任何事情都应该可见，并通过单一的功能强大的控制台进行管理，以确保不会丢失任何东西。企业的ESB需要得到有效监控和管理，其中包括对可能部署在SOA中的其他供应商生产的中间件产品的监控。
(3) 传输远程文件—— 根据Gartner提供的信息，我们惊讶地发现，大约70%的企业数据都是通过FTP(文件传输协议)进行传输的。因此FTP必须成为企业SOA的一部分。然而，平均有20%的时间FTP的传输会失败，这会直接导致数据丢失或损坏，带来经济损失。同时，使用这种格式就很难去核实传输的内容和时间，执行传输的人是谁，以及此人是否获得了传输文件的授权。
尽管FTP感觉上是“免费”的，其实它暗藏着成本花费和风险。如何自动传输其他应用产生的文件并对其进行整合？如果目标应用需要其他不同格式该怎么办？企业如何确保流程连贯流畅？标准的FTP程序通常需要大量的人为干预。
就算不考虑文件大小，业务还是需要遵守越来越多的金融规则和其他规则，做了什么、何时做的、谁做的这些信息也变得越来越重要。文件传输很难满足这些要求，并且正如我们前面所提到的，传输经常会失败。而ESB中整合的新型的可管理的FTP解决方案使企业能够遵守这些规则，因为它提供了一种方式，能够核查谁做了什么、何时、何地，以及如何进行操作。
(4) 确保服务质量—— 试想如果所有的供应商、应用、技术都采用同一种标准与协议进行通信和信息交换，生活将变得多么简单？但是这显然是不可能实现的，因为不同的服务需要不同的服务质量来满足业务的在特定时间的特定需求。不同的需求取决于不同的因素：客户的价值、事务的价值、安全的需求，业务的影响以及由于信息没有发送成功带来的风险。而这些因素又因为行业不同而千差万别。例如，零售行业的资产与军用的实时导弹防御系统的资产就存在着不同的需求和优先级。
如果企业面对海量的数据存储类型，应该如何存储和使用企业所有应用产生的数据，并且面对大量的数据处理方法如何进行选择？此时我们应该认识到，企业需要基于业务环境、业务规则和特定时刻事务的实际内容，在ESB的帮助下进行决策。
如果某一客户选择的股票价值超过了他所设定的上限，则ESB必须能够动态地改变服务质量和分发机制。如果该客户是高价值的客户，则必须马上电话通知该客户。还有其他例子：
● 保险领域的操作可以随着政策条款和执行环境的改变而改变(当这些保险还在为客户提供服务时)。
● 当客户在商店购买某件产品时，能够被告知产品的特殊服务以及相关产品。
● 战斗机能够被告知原计划的攻击目标不再敌对，及时取消导弹发射。
综上可知，每个例子都对情况进行了正确分析，从而保证了彼此不同但合理的服务质量。这意味着，企业业务中的任何资产—— 不管在哪，或是以何种方式保存的—— 都能够得到有效整合。
如果企业业务要求以24×7(全天候)的方式运行，那么该企业的ESB同样也应该如此运行—— 这要求不仅所处理的数据要非常灵活，同时定义、部署和管理的方式也要灵活。当然，这样做的原因之一是为了确保企业业务能够提供满足客户要求的服务质量。任何顾客都不想受到企业的基础构造的限制，而不管企业是否是关闭系统来进行更新(因为企业的部分业务是在不同硬件上运行的，而业务的其他部分无法访问该硬件设施)。在ESB的协助下，企业不再为此头痛，因为为客户或业务事务提供高质量的服务可以得到保障；同时，企业不再用单一方法处理所有事务，因为这样是无法根据业务的某一部分、某一时刻甚至事务的内容来调整服务质量的。企业的ESB与业务系统一样，要能随着需求的变化而进行调整。这就好像一家后勤与运输公司，刚起步时在小范围内，用一辆小的卡车运送任何东西；而随着规模不断扩大，公司逐渐需要不同的后勤和运输模式来运营。
企业需要灵活的反应迅速的ESB来提供最高质量的服务。
(5) 确保业务的连续性—— 高可用性、可伸缩性和弹性—— 如果企业业务和吞吐量突然增长，如何才能在不进行重构情况下来升级解决方案？企业必须能够将工作量同时均衡到SOA的多个部件之上。这样，在一个服务器失效的时候，其他的服务器才能够在没有人为干预的情况下，接管这些增加的工作量。一旦服务器修复，它会重新继续处理这些工作量。所有的情况都是在没有改变现有的服务的情况下，动态完成的。当然，避免单点失效同样重要。如果连接失效怎么办？难道告知顾客请明天再来？企业不能降低自身的服务水准，这样只会损失利润。
ESB必须能够作为一个独立的物理实体存在并运行。然而实际上，它能够部署在多个站点甚至是不同地点，也就是说工作量和各种不同类型的流程能够分配在多个相互关联的ESB之上。这样，企业就拥有了先进的、分散的、可以通过单一控制台统一配置与管理的ESB，并不再出现单点失效的情况。
(6) 通过复杂事件流程减少业务风险—— 平均说来，IT部门只能发现—— 或者处理—— 33%发生在企业中的风险事件。在某些情况下，单个事件并没有任何意义，但是对于一些事件组合在一起所形成的“业务形势”，企业则必须处理。
请思考下列三个例子：
a. 一张信用卡在欧洲的ATM上使用过后不到的10分钟，又在美国使用了—— 如何才能迅速发现欺骗行为呢？
b. 一位顾客两天内取消了2次预订，并没有完成一次正规预订—— 这位顾客是否不再忠诚于该企业？
c. 一系列事件在地球一端引起了巨大灾难，而相似的事件又在地球其他地点发生—— 是否能够阻止第二次相同的灾难发生？
请单独考虑以上每个事件，没有哪个事件因为不符合常规而引起重视。但是一个事件模式可能预示着一些意义重大甚至是灾难性的后果。
在SOA中，企业需要能够发现和处理这些事件，并从历史信息中不断学习，一旦类似事件再次发生，就知道该如何处理了。现在，企业的SOA变得有了“意识”，成为了公司业务的“神经系统”。业务分析人员必须能够定义一系列的事件模式，只有这样，企业服务总线(ESB)才能够在事件发生前检测到它们。这样做可以大大降低公司和客户可能面临的业务风险。
来自任意源的消息流经ESB需要一段时间，期间，ESB基于预定义的模式对这些消息进行分析。时间是一个关键因素。如果某一类事件在24小时之内重复发生，就可能被当作普通的正常业务来处理。如果此类事件是在10分钟或者30秒之内连续发生，那么意义就完全不同了。对事件模式的检测使得ESB能够采取必要的措施，例如，向客户的移动电话发出预警信息；给石油管道设备发出指令，关闭或打开阀门；甚至发出控制糖尿病人注射胰岛素的指令。
结论：考察一个ESB系统时，上述评定标准很有帮助，它能保证企业获得一个不受限制的ESB系统(见图5-2)，并在以下几个方面帮助企业处理业务：
● 全局协调的安全事务
● ESB系统的整合
● 提供ESB的SOA硬件
● 全面转换以适应企业需求
● 以动态扩展和管理ESB的服务注册中心
● 服务监控，使服务端到端可见
● 将ESB无缝扩展到业务流程的服务编制

图5-2 不受限制的ESB
案例分析
XEROX公司
Xerox公司研发的干净快捷的影印技术，替代了杂乱模糊的油印机技术，对办公室业务产生了革命性的变化，Xerox因此闻名于世，同时，Xerox也成为了该公司的旗舰产品复印机的代名词。不但如此，Xerox也提出了其他许多创新产品，如以太网、图形用户界面、鼠标等思想，从而定义了当今的个人计算机服务。以Stamford，Connecticut为基础，Xerox全球共有58 100名员工正在为改善人们的办公环境而努力工作。
尽管Xerox在复印业务上已经相当成功，但是为了开发基于客户要求的新业务应用，Xerox在世界范围内进行研究，导致了大量的重复工作，这成为了阻碍Xerox生产力的瓶颈。Xerox公司旗下，生产各种产品的多个部门之间要想彼此通力合作，就必须采用一种新业务应用的合作方式，使手工过程自动化，才能更好地服务客户，占据更大的市场。但是从头开发新业务是一种浪费，因为很多程序都共享相同的后端数据库、企业资源规划和客户资源管理系统。为了使程序开发能够精力集中并降低成本，Xerox采用了有效的方法进行应用开发和整合，创建了自己的整合能力中心(Integration Competency Center)。这一团队专门致力于通过后端系统对Xerox的业务应用进行整合，意在建立一个信息技术(IT)架构，达到代码资源重用，以及利用公共基础架构整合大量应用的目的。
ESB为获得灵活的连通性提供了基础架构
这个团队开始几年使用CORBA代码对应用进行整合。后来，他们发现他们编写的大量定制代码都是无法重用的，这导致成本上升，开发周期延长。Xerox开始研发一种新的ESB架构，这种ESB是一种中间件模式，它能统一并连接公司业务中的各种服务和资源。ESB模型允许软件(这些软件在不同平台上并行，或使用不同的程序语言和开发工具的软件)之间进行连接，这使得Xerox能够更加快速简捷地向客户介绍新的应用和更新。
Xerox选择了一种SOA解决方案进行通用连接，这个方案为ESB框架提供了业务整合逻辑，设计出的ESB系统采用了面向消息、事件驱动以及Web服务的能力。采用新的ESB解决方案，Xerox预测，企业一年就能节约720 000美元的花销，代价是改变之前需要定制代码才能与后端系统进行整合的应用。而且，与以前相比，这种应用的改变只花费了25%的时间。“我们24个月内就获得了回报”，Xerox整合能力中心的经理Ram Sunkara如是说。
开发、灵活、可用的基础架构支持50种解决方案
在新的基础架构上运行的50种应用程序中，包含下列各种Web服务：为Xerox客户支持小组查找服务提供商、信用认证、管理客户服务咨询电话、订单管理、填补打印机客户公文包信息等。这些应用中有很多需要24×7(全天候)的服务。这种基于开放标准的整合解决方案支持与后端系统通信的多种方式兼容的SOA。
在ESB整合解决方案和SOA的支持下，Xerox正在进行全球范围内的标准化应用整合。这包括：建立一系列Web服务，从而利用一些现有的主机信息，使人们通过Web能够进行访问。“现在，我们正在欧洲各部门执行这项工作，为接下来的流程改善积累关于监管的实践经验，”Sunkara如是说。

这种不受限制的ESB有很多的内容。作者建议企业在计划利用SOA的连通性之前，请先理解这些内容。
● 全球协调的安全事务—— 事务对于企业业务来说很关键。每个事务看起来很小，似乎无关紧要，但是业务系统必须很认真地处理这些事务。事务需要更新资源并完成份内任务，否则关键信息就可能丢失，导致系统故障。比如，转账时，必须确保这两个账户都已经得到更新，否则就会出错。再比如，节假日预订房间、航班，或者租赁汽车等。如果在业务处理中，多个资源需要在一个事务中得到更新，就必须确保这些更新能够一起完成，否则会增加复杂程度，因为企业不得不进行回滚操作，以撤销被中断的事务造成的影响。这种回滚操作是我们必须回避的，也正是我们首选ESB的原因。ESB最好能够协调资源更新，不光在本地环境中，还包括扩展环境。企业必须确保ESB能利用已有的资源，而不是破坏或替换这些资源。
企业在处理那些对业务很关键的事务时，必须确保信息是安全的，而且还必须确保这种安全操作不会使处理流程变得更加复杂。
● 与ESB完全整合—— 企业的ESB需要各事物之间的广泛连接。市场上的一些ESB只与应用和Web服务相连接。然而，ESB不仅应该能够整合应用和Web服务，而且还应该为业务各部分的所有系统、文件和信息提供连接，从而延长生命周期，扩展现有应用、系统和数据的价值。
● 扩展ESB能力的SOA硬件—— XML和Web服务对整合提出了新的挑战，因为过多的XML处理能够导致限制核心功能的瓶颈的产生。因此，企业在提高业务流程(遵守SOA规范的前提下实现的业务流程)的性能、安全性和管理性的同时，还希望能够使复杂程度最小化，并缩减构建SOA基础架构的周期，尤其是那些包含XML和Web服务的SOA基础架构。
在SOA的世界里，服务可以来自任何地方，完成任何事情—— 内部的或外部的。SOA引发许多问题，其中包括大部分ESB没有考虑过的形势严峻的安全问题。这些问题给ESB造成了限制，导致业务目标甚至业务本身的降低。这样，我们就足以理解为什么一定要将一些被认为不属于ESB的功能，整合到专用的处理器(为了处理特定功能而优化的)中—— 促使企业可以利用具有特定功能的硬件来扩展企业的ESB。
这就是为什么企业需要没有限制且可以被应用策略扩展的ESB。应用是企业的SOA硬件。应用在提高业务流程(遵守SOA规范的前提下实现的业务流程)的性能、安全性和管理性的同时，使复杂程度最小化并缩减了构建SOA基础架构的周期。应用为服务提供了很多功能，包括降低成本、加速关键流程和处理关键整合功能—— 从而保证企业ESB是真正高效并且安全的。企业需要一个联合的ESB策略以便能将正确的功能放在正确的地方—— 如跨平台的设备和核心事务的ESB系统。
● 满足企业需求的全局转换—— 对于许多业务，在不同服务间映射数据并转换数据格式是ESB的首要需求。毕竟，如果企业的SOA需要灵活地连接应用，并且数据的格式并非制定格式，转换就必须在应用中发生。但是这样不但增加了复杂性，而且降低了重用应用的许多性能。因此，企业如果不想被ESB限制，就必须重视转换。
高效的SOA必须能够将数据从一种格式转换到其他任何一种格式—— 不管这种格式简单还是复杂，是高度专用的还是基于核心行业标准的。然而，对于真正的SOA部署而言，数据是否能被转换，以及转换应该产生在哪里，这两个问题同等重要。企业需要在两个本地应用或服务之间进行转换，但是又不想将消息路由到远程hub去作转换；企业需要可以在任何地方—— 甚至在第三方的整合产品中—— 运行的映射功能，但是又不希望增加应用的复杂程度，或使得运行环境不稳定。这意味着企业不仅需要任何数据格式之间的转换，更需要发生在ESB中任何地方的转换。转换功能被认为是ESB的核心功能，它能够被部署到企业中的任何地方，并可以通过ESB获取。
● 动态扩展和监管ESB的服务注册中心—— 前面我们讨论了业务服务注册中心和存储库的关键作用。ESB的选择不仅仅需要进行简单的连接；还需要动态寻找和访问注册中心和存储库中的资源。服务注册中心需要通过企业政策进行管理。它可以进行动态服务定义和定位，并基于策略来定义对资产进行使用和重用。
● 服务整合的端到端可见的服务监控—— 如果所有的事情都是通过企业的ESB运行，那么企业必须确保拥有高效的工具，能够追踪和管理ESB中流动的资产。
假设企业做了一份很好的SOA计划，并且已经成功地在所有平台、应用和服务之间建立了连接，包括在应用与整个ESB的业务流程之间建立了好的连接。但是现在，当系统启动并开始运行的时候，每件事情似乎都脱离了控制。企业如何才能知道哪些事情正在发生？能否跟踪系统中正在发生的事情？是否已被局限在ESB所提供的信息？在高度互联和互相依赖的SOA环境中，企业对所有定义的情形保持警惕，提高业务活动的自动化并增强对其的了解，这是非常关键的—— 如果做不到这些，将会导致企业发展的瓶颈或失败。
在不受限制的ESB中，企业需要能够发现问题并尽快解决问题，通过表面征兆找到真正的问题所在。这一点需要贯穿整个生命周期—— 不仅仅只是在单一环境中，而是要贯穿整个SOA，跨越多个平台。理论上，任何事情都应该可见，并通过单一的功能强大的控制台进行管理，确保不会丢失任何东西。企业的ESB需要得到有效监控和管理，其中包括对可能部署在SOA中的其他供应商生产的中间件产品的监控。
● 无缝扩展ESB，从而包含业务流程的服务编制—— 如前面所提到的，流程是SOA中的关键部分。为了获得能够提供真正SOA且不受限制的ESB，必须对业务流程进行高度整合。企业必须解决连通性问题，这一点要和流程计划一起执行，或者列入到流程计划之中。企业如果正在努力通过高效的和优化的流程来使业务流畅，那么就必须确保企业流程是经过有效编制的，而且确保流程与底层应用和服务之间存在高效连接。为了实现这一目标，企业不应该使用互联接口使流程更加复杂。企业需要确保ESB与流程层之间的无缝协作，同时确保流程和连通性之间的高效解耦。企业还需要确保不受限制的ESB能够提供强大的、可伸缩的环境，对部署流程的各种方式进行整合。
总而言之，复杂的事务处理流程会帮助企业业务对更多形势(可能一直很难发现，而一旦发现又已经太晚的形势)作出更快速的反应。未雨绸缪可以为企业节省很多资金。
5.3.3 支撑业务的企业ESB
如果企业的ESB能够很好地处理前面内容所提出的问题，那么企业业务的灵活性、敏捷性和创新性都会明显提高。所有技术的复杂程度以及相互依赖度都被抽象出来，因此业务可以看作是一组定义良好的服务，能够被编制到更高级别的业务流程。随后，业务就可以要求建立和分类新的服务，从而获得独立于技术改变的可靠知识。供应商、产品和应用都可能随着时间的推移发生改变甚至取缔，但是业务流程与其相适应的业务可以长久稳定地存在。这是SOA真正区别于以往各种整合形式的原因所在—— 区分了“需要做什么”和“如何使之实现”这两个关键问题。

案例分析
Standard Llife集团公司
总部位于美国爱丁堡的Standard Life集团公司PIc，已经成为世界上主要的金融服务公司。Standard Life集团公司的主要业务和收入来自独立财务顾问(IFA)，帮助顾客从不同的保险公司选择金融和保险产品。很多IFA利用门户网站来获得产品信息，比较多个不同提供商提供的价格，为客户提供客户财产的统一视图。
Standard Life集团公司意识到，为了保存竞争力，需要为它的IFA提供更方便、更灵活和更快捷的在线访问金融信息的途径。Standard Life集团公司使用了多个业务渠道，因此需要降低业务成本。降低成本不仅可以带来利润增长，还可以巩固竞争基础，改善与公司IFA们的关系；自动化带来了更多的自服务和更快捷的流程，这些都可以帮助IFA提高利润。Standard Life集团公司想在传统渠道提供优质服务的同时，再通过门户网站和公司本身的在线渠道为IFA提供所需的数据，从而帮助他们超越其他的竞争对手。他们想构建一种更灵活的新的信息技术(IT)架构。通过这一架构，他们能够利用门户网站和其他新渠道中可重用的Web服务，快速、便捷地部署新服务。新的IT平台同样需要灵活利用和重用企业已有的流程和技术资产。他们想要实现SOA，这可以使IT功能和相关的业务流程组件化，成为自包含的、模块化的应用软件，且不用依赖定制代码的连接就能协同工作。到那时，这些模块化组件可以被重用，以满足IFA以及新的战略分布式合作伙伴的不断变化的业务需求，并缩短开发周期，降低成本。
SOA使得IFA、代理商和客户可以获得550多种业务服务。其中包括提供退休金评估、生成客户对账单、维持客户信息等。
SOA使得Standard Life集团公司能够结合Web服务，便捷地部署新服务，从而简化其各个业务渠道中的工作流程。Standard Life集团公司可以通过各种操作对Web服务进行重用，这大大减少了开发定制应用的时间。由于重用了将近51%的Web服务，PIc已经节约了超过1千万英镑的开发成本。灵活的模块化的SOA设计使得Standard Life集团公司反应更加敏捷，能够面对新的商业契机，以最快的速度作出反应。
自从PIc实现了新的SOA，Standard Life集团公司使用SOA处理事务的速率一年年增长。目前，在PIc每日8百万的主机事务中，超过50%是通过SOA中的应用生成的。这并不需要增加IT人员的数目。实际上相反，在SOA实现期间，IT人员的数量减少了三分之一。如今，SOA的生产力和交付能力已经达到了可以同时运行150多个应用。PIc通过允许业务合作伙伴访问公司的Web服务，确保了客户信息的一致性。不管数据是来自IFA门户、公司网站还是客服代表，IFA、代理商以及客户收到的都是同样的信息。通过提供简单、一致地访问数据的方式，Standard Life集团公司在竞争对手中脱颖而出，并为公司、IFA以及客户获得了竞争优势。在过去7年中，PIc有6年被U.K.IFA评为“年度最佳公司”，并且凭借其高质量服务受到一致好评。
5.4 协调工作：企业ESB的服务、连通性
以及BSRR
通过Web服务、ESB和BSRR技术，我们已经了解了重用和连通性的概念，现在让我们看一下它们是如何在一起共同工作的。
在图5-3中，首先一个服务被某个应用调用，随即发送一个消息，消息将被ESB接收，并遵照ESB运作。然后，访问BSRR，从而决定哪些服务将被监控，以及哪些服务收到了监控请求，如过滤器的使用。例如，如果订单是由外部的合作伙伴提交的，那么就对订单的提交进行监控。这种行为使得对于不同的服务—— 比如说，来自外部的一个新用户的服务—— 的监控(对比于监控已建立的用户)是不一样的。


图5-3 可操作的监控交互
然后服务管理工具捕获并评估业务服务性能和操作性能目标。这一信息将与BSRR中的服务描述相关联，并在运行时被仲裁层评估，以影响动态路由、过滤和其他决策，同时随需应变地提供可操作的灵活性。
正如上述例子所描述的那样，这些关键技术及其使用对于成功的部署和实现是十分关键的。
5.5 SOA生命周期驱动灵活性
本节提出了一个关于这些领域如何协同工作的观点。从生命周期的角度考虑SOA，能够最透彻地进行分析。请综合考虑这个生命周期，战略性地接触它，并关注对于企业最有价值的部分(参见图5-4)。

图5-4 SOA服务生命周期
我们的客户已经告诉我们，他们采取了生命周期的方法来处理SOA。从建模阶段开始，收集业务需求，设计、模拟和优化所需的业务流程。通过这种方式，他们可以确保在未来行动开始之前就已经设定好正确的运行步骤。当优化完业务流程之后，组合新建的和已有的服务来构成复合应用，最终实现这些流程。这就是组装阶段。然后利用那些为整合人员、流程和信息提供支持的专门服务，将这些资源部署到了一个安全的整合环境中。这种级别的整合有助于确保公司所有的关键元素都被连接，并能够协同工作。一旦部署了复合应用，客户就可以从IT和业务的角度来管理和监控应用以及底层的资源。在管理阶段收集的信息被用于获得对于业务流程的实时观测，使得企业能够更好地进行业务决策，并将信息反馈到流程不断改善的生命周期中。巩固所有这些生命周期的基础就是管理，它为SOA项目提供了指导和监督。
上述SOA服务生命周期表明了一种SOA融入业务且不断改进的方法。关注于业务服务，并且为了更好地重用最佳实践，连接业务间的这些服务，将再次提高整个公司的适应性，推动公司的创新。




5.6 本章小结
要开始将业务向灵活应对转变的旅程，需要关注SOA生命周期和技术的关键要素。业务的灵活性需要灵活的IT—— 事实上，今天所有的业务都依赖于IT。面向服务架构是灵活的IT的关键。财富500强的公司平均拥有多于48个不同的财务系统和3个企业资源规划系统，所以要想获得今天的成功， IT就必须灵活高效地使用企业环境中现有的所有资源。面向服务架构是建立在使企业高效使用其所有资源的重用价值观之上的。
企业必须仔细思考以下最佳实践：
● 策略和服务(Web服务)
● 怎样存储和高效利用服务的重用性(BSSR)
● 连接企业机构所有级别的服务的策略(ESB)
● 如何高效利用SOA生命周期，作为实现最大价值的战略手段
这些IT最佳实践是企业成功的基础，但是让我们用业务主管的眼光来探索SOA以业务为中心的一面吧。