作者：顾春红
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
面向服务的企业应用架构——SOA架构特色与全息视角试读：
内容简介
目前，国内的单一IT系统技术已相对成熟，IT逐步靠近业务，如何提高系统的协同整合能力成为IT主管的关心重点，其关键所在就是有别于传统系统的灵活扩展考量因素及架构方法。
本书采用面向服务的架构（SOA）与企业架构相结合的方式，基于企业应用整合的最佳实践模式，结合SOA成功案例，阐述企业级应用系统的特色及架构方法，并全方位地展示SOA信息系统的架构建模过程。
本书具体阐述的内容包括：架构不是单纯解决问题，而是为设计活动建立一套清晰框架及思维方式；SOA是全方位的架构体系，包括企业架构、业务架构与应用架构；SOA的协同整合形成无边界的信息流，以此改善占据企业80%整体业务的运转性能；SOA是沟通业务与技术的语言，其架构的关注点是系统的适变性；完善的SOA架构设计具有一套完整而关联一致的、反映全息视角（视点）的模型系统。
本书适合SOA架构师、对SOA感兴趣的企业架构负责人、业务人员、IT技术设计人员学习。未经许可，不得以任何方式复制或抄袭本书之部分或全部内容。版权所有，侵权必究。图书在版编目（CIP）数据面向服务的企业应用架构：SOA架构特色与全息视角/顾春红，于万钦著.—北京：电子工业出版社，2013.2ISBN 978-7-121-19316-3Ⅰ.①面… Ⅱ.①顾… ②于… Ⅲ.①互联网络—网络服务器 Ⅳ.①TP368.5中国版本图书馆CIP数据核字（2012）第309772号策划编辑：许存权责任编辑：许存权 特约编辑：刘丽丽 刘海霞印 刷：三河市鑫金马印装有限公司装 订：三河市鑫金马印装有限公司出版发行：电子工业出版社 北京市海淀区万寿路173信箱 邮编 100036开 本：787×980 1/16 印张：20.75 字数：400千字印 次：2013年2月第1次印刷定 价：49.80元
凡所购买电子工业出版社图书有缺损问题，请向购买书店调换。若书店售缺，请与本社发行部联系，联系及邮购电话：（010）88254888。
质量投诉请发邮件至zlts@phei.com.cn，盗版侵权举报请发邮件至dbqq@phei.com.cn。
服务热线：（010）88258888。专家热评 SOA的点睛之作
SOA流行了好几年，概念炒了好几年，但都停留在概念炒作阶段，很难见到成功落地的案例；没有看到过一本能够把整个SOA前前后后、方方面面说得非常清楚，能够实际落地操作的文章和书籍。以前有关SOA的书籍基本上是纯技术层面和理论层面的，定位于对一些产品技术标准的讨论，即把SOA定位于一个具体的技术，没有相应的案例佐证，难懂、易读性差，看完之后总有点盲人摸象的感觉。
正如《面向服务的企业应用架构——架构特色及全息视角》一书中所谈到的一样，SOA架构是一种实体模型构建方法，与采用什么具体的技术和产品没有直接关系，普遍方法才有通用的指导意义。该书结合企业架构、业务架构，深入地剖析了企业应用架构涉及的项目需求、方案架构、服务架构、架构实现、接口规约等几大方面，剖析了与业务结合紧密的BPM流程管理服务、用户交互服务、数据访问服务等服务组件的实现架构方式和策略。书中提供了大量的视图图例和表格，参考性和可操作性强，既有方法原理、步骤描述，又有实战案例参考，是一本难得的构建面向业务的企业应用架构的好工具书。
书中提到的“上层中间件”的概念，在国内还是第一个提出的。在国外，几大软件公司及大学已经有人在研究，英文名称叫做“Upper Middleware”。中文名称还没有一个标准的称谓，“上层中间件”这个词很贴近其原意。上层中间件是未来企业级应用软件发展的趋势之一，作者在这方面的思考和实践都走在了前面。该方向的软件平台产品更贴近“云计算”，“云服务”的实现，是未来企业级应用云计算能够落地的一个有力保障，也是中国软件业的一个机会。作者给中国的软件业指明了一条与国际软件巨头看齐的机会。本书中的一些见解无疑具有启迪智慧、开拓未来的价值，即为我国企业开发出具备自主应对变革需求的“上层中间件”工具平台，这其中的革命性意义值得关注和期待，定会成为我国IT界一件重要的里程碑事件。
本书对业务咨询师、IT架构师、软件从业人员、软件学院学生全面学习和掌握SOA架构实践的方法有极大的帮助，我在此郑重地向大家推荐。电子科技大学软件学院院长电子科技大学教授 博士生导师李建平2012年10月序 言“十二五”期间，中国政府进一步鼓励科技创新，其中在医疗、电信、金融、制造、能源等行业将会加大投资力度，用于扶持产业的发展。面对如此难得的历史机遇，各行各业同时也经历着一场严峻的考验，如何让企业的业务能够在激烈的市场竞争中保持灵活性，实现不断创新，成为各企业CxO们最为关注和时刻思考的问题。
在构建行业解决方案过程中，如何能够正确有效地使用企业IT基础架构，使其紧密而灵活地配合企业的业务需求，是企业成功的关键之一。SOA，即面向服务的架构（Service-oriented Architecture），已经成为公认的企业级IT应用架构的发展趋势。作为一种软件系统应用架构的方法，SOA把业务组件分成基本的构建模块，就像通过标准化软件接口实现IT基础设施的模块化，从而使灵活的业务流程与灵活的IT流程相匹配。通过SOA能构建的行业解决方案，以及企业应用架构能够快速适应变化，实现业务创新和IT增值。
本书从企业应用整合的角度，运用SOA架构思维方法，结合作者多年来SOA的实战经验，详细阐述了SOA的整体框架以及全息多视点的建模过程。书中论述的面向服务的企业应用架构同时考虑了企业架构和应用架构，提供了一种全方位的架构模式。为了帮助读者进一步理解面向服务的架构设计过程，作者具体例举了SOA的架构特色及架构模式，分享了项目中归纳总结出来的部分最佳经验和研究成果，相信这些具体的示范指导对读者在企业应用架构中有所借鉴作用。
书中涉及的上层中间件是未来软件发展的三大重要趋势之一，其中包括：客户可控云和多核并发程序。面向服务的上层中间件所奉行的业务实体架构方法，能够建立起企业的有效运作模式，该运作模式是通过一系列的信息、规则、流程、交互模版、分析组件等构建企业应用和整合应用，使得企业通过驱动这些流程而驱动应用，从而在不改变现有应用系统的情况下带来一个创新的平台，强化业务人员掌控IT灵活性的能力。“读万卷书，行万里路”，衷心希望各位读者能够从阅读本书中获益，并将您学到的知识转化为实践，构建更加“智慧”化的行业解决方案服务化的企业应用架构。胡晓专IBM中国开发中心服务及行业解决方案总经理2012年11月前 言
面向服务的架构（SOA）推广应用已有多年。如今在IT行业，SOA几乎是尽人皆知。目前市场上有大量的SOA书籍，从方方面面阐述其原理、方法及技术实现。因此，本书不再赘述SOA的基本概念及技术（包括Web服务），而是基于具体项目经验，专注于SOA的特色，以及整体架构方法的实践运用。
SOA的字面意义是“面向服务的架构”，首先是“面向服务”的概念。什么是“面向服务”呢？“服务”的对象是各种各样的需求，“面向服务”就是需要什么样的服务就能提供什么样的服务，就像一栋建筑中我们需要两层的“商场”、一层的餐厅、5层的宾馆、一层的KTV、一层的电影院等，这栋建筑物都能够随时满足需求，那么，我们就说这栋建筑的结构是一个“面向服务的架构”。一栋建筑物如果按照“面向服务的架构”模式，即用“混凝土框架结构”来设计、建造这栋大厦，那么这栋大厦就能够在将来使用的时候灵活地满足功能上的需求而不必大动干戈地改动该大厦的基础设施。既然建筑上存在这样的一种灵活的“架构”模式，在应用软件系统的开发构建上有没有类似建筑业的一种“混凝土框架结构”的架构模式呢，基于这样的一种架构模式建立起来的系统能像“框架结构”的建筑一样灵活地满足业务需求的变化吗？答案是肯定的，这就是本书要阐述的“面向服务的应用架构”。
本书着重阐述以下几个方面：（1）全方位的面向服务架构设计——其中包括企业架构、业务架构与应用架构设计；（2）架构服务定义——如何定义具有意义的服务或服务组件，特别是逻辑服务与应用服务的关联；（3）SOA协同整合的架构方式及特色——甄别SOA架构设计时主要的关注点，并通过利用这些特色来满足业务灵活应变的需求；（4）全息架构视角的建模方法及实践运用——理清SOA应用系统设计中承上启下、互相依赖的关联过程；（5）SOA与其他架构形式的差异之处，例如，ERP和云计算/服务等。简言之，本书以具体实例表明，SOA企业应用架构是沟通业务与IT之间的桥梁，是满足用户关注点及业务灵活性、运用全息架构视角构造应用服务体系的建模过程。
自从作者参与架构起初的IBM SOA企业应用/业务协同试验（Bakeoff）项目，距今已近十年。其间，架构设计及咨询了无数的国内外SOA项目。本书主要是针对一些国内项目的经验回顾。在起草本书稿的过程中，特别邀请了国内一位在系统整合开发领域敢于吃螃蟹的SOA实施专家，斯欧（SOA）信息技术公司的总经理于万钦先生，一起完成本书的撰写工作。于先生帮助完成了第4章SOA端到端案例章节中的项目内容，并对本书成稿提供了具体的意见。值得称道的是，斯欧公司在制造业具有“旗舰”作用的SOA成功实施落地项目，并在国内外享有声誉。
本书基于公开标准及规范，以通俗的语言来描述面向服务的架构设计方法，尽量避免SOA具体的IT细节。使用的方法及工件主要从实际的SOA项目角度考虑，而非理论或SOA技术规范。本书将让读者认识一种构建灵活应用系统的架构方法和框架原则、架构的全息视图和元素，以便全面了解SOA架构的最佳实践。本书将一步一步地引领读者去熟悉SOA架构的步骤、原则、视角，从而掌握SOA架构的技能，因为只有掌握了SOA架构的技能和方法，才能构建灵活的应用系统模型，才能实现随需应变的业务需求。本书将以大量翔实的架构视图和表格来详解SOA架构的方法和元素，部分内容以开拓思路、相互切磋为重心。顾春红2012年8月于上海第1章 面向服务的企业应用架构概要SOA的“服务”是IT架构现在及未来的核心
也许你会发现，在不少SOA项目中，一般所指的架构设计，要么是架构总览层面，要么是设计文档层面，应用架构部分往往不充分，或欠缺系统化的架构产出件。这是导致SOA项目不了了之的主要原因。从实践中得知，重视企业应用架构的企业，SOA相对容易落实。面向服务的企业应用，其成功与否，就目前而言，与其具体所采用的技术并非密切关联，既使一个项目全部采用SOA产品，技术或Web服务标准，如果架构不当，其效果甚微或导致失败。
在从事SOA项目时，我们常会听到一些对现有架构或技术的疑惑。例如，SOA的主要架构原则与ERP有何不同？简单地说，ERP的核心思想是把企业的生产组织模式固定化。但当企业的管理水平达不到ERP核心思想所倡导的业务模式时，企业就变得水土不服、消化不良。比较而言，SOA架构的核心是把企业的业务模式看成是动态的，随时可以调整的，SOA的目标就是要解决这种动态灵活的需求性。
再如，面向服务的企业应用与中间件（Middleware）是何等关系？回答这个问题，我们可以使用汽车架构设计来作一个大致的比喻：中间件能较快地为客户创建和管理各种服务功能组件（零部件），但这种平台缺乏快速装配这些组件、形成最终产品的能力，相当于汽车的底盘和发动机，没有行业性限制。而面向服务的上层中间件（Upper Middleware）则提供构建各种功能车的组件、装配工具和装配方法，让用户可以在底盘上DIY（自己动手做）定制功能车，并且可以随时更换功能部件，从而满足随需应变的环境需求。
那么，为何要使用SOA服务呢？在企业应用架构中，我们有太多的专用术语，但使用者所关心的仅仅是服务而已，无论是业务服务或技术服务。同时，企业应用架构不能单靠实体概念（如组件）描绘清楚，所以服务好比是企业应用的通用语言，有了服务这一语言，受众之间的沟通交流才能变得顺畅。显然，SOA的现实意义并不局限于IT本身，它是提高企业适变能力的必然步骤。无论是使用中间件或是上层中间件，无论是云计算或是“宇”计算，服务始终是考虑的核心部分。
虽然安妮（Anne Thomas Manes）曾发博客文指出，SOA已死，引起业界轰动，但不可否认的是，她也同时表示，对于面向服务架构的需求会日趋强烈，SOA服务万岁。所谓的SOA已死，是指无谓的SOA技术辩论，例如，什么是最好的ESB（企业服务总线），WS-*与Rest何者为优，JAX-RS（JSR311）/微软. NET Web API/Restful Objects何为规范等。
本书主要侧重于面向服务的架构设计和架构方法的阐述，不对面向服务的实现技术加以详细描述，也不针对某些SOA产品技术。1.1 面向服务架构的必然性
面向服务这一概念源于1996年Gartner所涉及的SOA，这里也包括SOI（Service-oriented Integration）。顾名思义，SOA是面向服务架构，而SOI是面向服务的整合。一般而言，在现有企业级应用中，SOA与SOI同时共存。面向服务的关键是建立一套标准的架构体系，而这一体系不受制于某一特定的技术或业务模式。当信息技术的交互变得日益普及化、标准化及产品化时，面向服务的架构风格显得尤为重要。简言之，SOA是一种架构风格或架构模式。那么，企业应用为何要如此强调SOA架构呢？1.1.1 阿凡提的兔子汤
在阿凡提的故事中，他和猎人朋友一起打了只兔子，美餐一顿后还有所剩。一天以后，有人来说，他是朋友的朋友，阿凡提于是请他喝了剩下的兔子汤。过了几天，又有人跑来，说他是朋友的朋友的朋友，于是阿凡提就请那人喝了一碗水，说这是“兔子的汤的汤的汤”。这个故事说明，凡事是有层级化的，不可能充分扁平化，就如部队里连长也许能关心全体战士，同他们交流感情，而营长就很难与全营战士沟通了。同样道理，当一个企业的系统发展到一定层面后，更新管理终将遭遇力所不能及的地步，从而思考如何进行架构转型。
从信息技术的发展历史来看，我们从四十多年前CICS（Customer Information Control System）系统包罗展现（Map操作）、逻辑（Program操作）及数据（VSAM/文件/缓存）的一体机，到如今以业务为导向的企业应用。我们从单层系统到二层、多层系统，到分布式系统，再到系统整合。我们从小到大，从基本到高层，从简单到复杂，从单一到聚合。我们从面向程序过程到面向对象，到基于组件、基于业务应用（ERP），再到面向服务化及框架化（如图1-1所示）。这是一个必然的发展趋势，其原因如下。（1）应用技术上，编程模式、语言、技术及工具不断变化更新及趋于多样化。（2）业务上，各个行业、部门、组织间，直接或间接地日益关联协作。（3）用户体验上，简便的操作、随需而生的应用及可以定制化的界面不再局限于单一的应用。（4）信息获取方式上，全球化、网络化的格局成为主流，等等。
SOA的应运而生正是满足了这种趋势：换位思考扁平化的孤岛系统，将日趋复杂的IT应用，经由组件化、服务化/框架化的整合，变得相对简单易用。图1-1 信息技术应用架构的抽象进程
目前，SOA还处于发展阶段（根据Gartner Hype Cycle 2012，SOA已经处于实用阶段，在技术上处于浪潮平原期），企业对SOA必须具有前瞻性。在企业IT的初级阶段，应用SOA或不应用SOA往往感觉不出太大效益。只有在企业IT规模发展到相当程度时，竖井式应用的弊端造成应用拓展维护困难，SOA的价值才会凸显出来。反过来说，SOA能够帮助企业未雨绸缪未来的业务整合，同时顺应IT应用网络化、商业化的趋势。许多大型企业或网站的IT架构发展进程充分说明了这一点。所以说，层级化的SOA现在是将来也将是应对这一变化趋势的一贴良方。1.1.2 秦始皇的度量“衡”
提到SOA的通用性及标准性，我们常会引用秦始皇统一度量衡的故事。在企业IT应用层面，我们自然会想到应用组件的通用性。在相对独立的应用中，一般不需要设计使用SOA服务。当某一应用或组件需要对外使用或重复使用时，或需要屏蔽特定的实现技术时，SOA服务才具有意义。通用性是采用SOA的必要原因之一，而SOA的重用性区别于组件的通用性在于其广泛接受的统一接口标准。这也是秦始皇统一度量衡的意义所在。
SOA的通用性还体现在其架构设计。SOA的架构重在网络化、客户化及整合化。其考量的重点不在于某一个应用，而是应用的对外使用或是应用间的关联。对于相当规模的某种行业或某种交互形式，往往可以设计出具有相当通用性的SOA架构。虽然基于组件的架构同样可以具有通用性，但它局限于某一特定的技术，而且范围也较小。相对而言，SOA架构层次较高，其通用性包含服务化与标准化，通过业务组件分解，较易与业务对齐。
另外，SOA的通用性体现在不局限于某一厂商产品框架技术。SOA以独立于技术的架构为主导，在此基础上，可以利用具体厂商的产品技术或应用框架。例如，微软（Microsoft）的BizTalk、WCF或Dynamics；甲骨文（Oracle）的Fusion中间件或SOA套件；IBM的中间件系列；普元的EOS等。当然，每个厂商的SOA侧重点不同。例如，微软主要侧重于Web服务集成或开发端的SOA，并在特定的平台上运行这些服务；IBM侧重于中间件的应用整合；SAP则重于应用管理集成套件等。
本书主要从架构的角度考虑SOA，这与设计或产品技术是不同的思维方式。SOA的真正意义不在于技术，而是架构优先的SOA构建部署方法。通用性的架构设计才是企业级应用整合的关键所在，同时企业应用产品化的通用设计也便于SOA的推广与价值实现。1.1.3 达尔文的“适变”理论
达尔文曾说过：“能够生存下来的不是最强的，也不是最聪明的，而是最能适应变化的”。同样，对于企业应用系统，其生命力在于其适应变化的能力。也就是说，不依赖于代码改变而由整体架构形成的系统适变性（Adaptability）或灵活性（Flexibility）。适变性是SOA的首要目标，其很大程度取决于其架构设计，关键表现在业务服务模块的设计、服务的依赖关系，服务粒度及服务接口的定义、业务及流程服务的定制化等在本书所强调的架构设计要素。相对于面向组件的灵活性要求，SOA的灵活性更强调企业级业务的灵活性，例如，跨域系统间接口调用的灵活性，或易于最终用户配置的灵活性，而这种灵活性是通过应用的服务层来实现的，而非下层的应用组件。但是，服务层也取决于组件层。一个完善的SOA架构是服务层与组件层灵活性的有机结合。
同时，SOA以业务为导向，其成功与否，很大程度上取决于最终用户对应用或系统的使用便捷程度，也就是易用性。易用性表现在容易上手、个性化配置、触摸或拖拉式操作、信息接口无缝转换等。当然，易用性与灵活性具有相当程度的关联。SOA的易用性不仅取决于可视化服务的界面设计，而且取决于服务视图及接口的关系配置。SOA易用性的受益者包括应用架构设计人员。1.1.4 高尔的成功系统定律
高尔定律（Gall’ s Law）表明：任何一个成功的复杂系统永远是源于一个成功的简单系统（A complex system that works is invariably found to have evolved from a simple system that worked）。
同样，对于企业应用系统的集成，永远是由简单的系统衍生而来。没有基本的应用系统模块，也就无所谓系统集成。由于SOA并非是一种技术或技术框架，并非适用于所有的信息系统应用。对于某一层面的IT架构或场景，例如，如果系统不是以整合为目的，而强调性能、安全、业务逻辑应用化等，SOA可能会是一个错误的选择。值得注意的是，SOA是基于传统应用之上的应用整合架构，其成功意义在于服务化、虚拟化的架构设计，而非SOA技术本身。所以，只有企业的IT发展到一定层面，SOA才有意义。例如下面所示。当企业已经进入ERP阶段，并使用服务化的方式来整合梳理系统及业务，粗粒度的服务能带来规范和效益。当企业将其应用或系统作为服务对外暴露时，实现网络化或产品化的战略。当企业具有一定规模的复杂系统，并且处于异构环境，或者在与异构环境交互时，必须使用SOA标准。当SOA的服务层给系统性能带来负面影响时，企业的财力或技术资源能够补偿这种一定程度的性能耗损。当企业IT负责人员具有一定的SOA的思维方式及掌握基本的SOA技能时。当企业领导足够重视应用整合，优先规范IT系统应用的灵活性及重用性，并付诸于长期规划时。
参见 "When Not to Use an SOA"，Jason Bloomberg
总之，企业在具有一定的应用系统规模前，或在考虑或采用ERP系统前，虽然可以使用服务模块的方式或暴露使用服务，但须依循高尔定律，逐渐过渡到SOA，不能一蹴而就。在设计或整合复杂系统时，必然要大量地使用现有的、逐渐积累起来的系统组件及资产，并且，所构建的系统越复杂，限制条件越多，就越有SOA的必要。而只有当SOA的标准、分布环境进入成熟阶段，SOA价值才能充分体现。无论如何，SOA企业应用整合的架构方法是企业最终走向成熟的不二之选。1.2 软件工程与SOA成熟度
不少软件从业者都熟悉CMMI（Capability Maturity Model Integration 能力成熟度集成模型）。CMMI主要包括软件工程、项目管理、过程管理等几个大的过程，是应用于软件业项目的管理方法。其共有六个能力度等级（0－不完整级；1－执行级；2－管理级；3－定义级；4－量化管理级；5－最佳化级），每个能力度等级对应一个一般目标以及一组一般执行方法和特定方法，评定级别越高，成熟度越高。与CMM相类似的有EAMM（Enterprise Architecture Maturity Model 企业架构成熟度模型）。
同样，SOA也有其成熟度模型：SIMM（Service Integration Maturity Model 服务集成成熟度模型）或 OSIMM（Open Group SIMM）。从SOA成熟度而言，企业对SOA的采纳是帮助企业从一个成熟度迁移到另外一个成熟度，每个层次的迁移需要不同的条件，也带来不同的价值。SOA的实施可小可大，小到Web服务，大到整个企业服务模型及集成架构。SOA也是多层次的概念，有业务层次，将业务活动描述为服务；有IT层次，将应用暴露成服务接口；有架构层次，使组织架构元素具有弹性。因此，SOA的成熟度模型可以帮助描述SOA涉及的主要方面和各个采纳阶段。如图1-2所示，SIMM可以表明企业SOA的当前成熟度（圆形）及目标成熟度（三角形）。
与传统软件工程管理的CMMI不同的是，SIMM反映出企业业务灵活性的目标状态。SIMM的目标不是一定要达到最高级别，而是确定适当的目标级别作为行动路线图，对现有企业进行改进，从当前成熟度提升到目标成熟度。何为适当的目标级别？业务的ROI （Return on Investment 投资回报率）是考虑的重点。另外，与CMMI不同的是，SIMM虽然也有方法或指导原则，但不一定是所有的SOA项目都得刻板执行，关键是要符合企业的业务目标，以选定的KPI（关键性能指标）及KAI（关键敏捷指标）来衡量。本书的侧重点在于应用架构方法，所以，我们主要关心SIMM中的方法、应用及架构层次有关面向服务的部分（图1-2框格部分）。
目前国内的信息化建设与国外发达国家相比，在硬件方面已平分秋色，但在信息化管理方面，特别是在企业级的面向服务架构方面，还有相当的差距。根据权威机构对于IT成熟度的四个阶段（启动阶段、扩张阶段、控制阶段及整合阶段）分析，目前我国大多数企业处于扩张阶段。这一阶段的企业的特点是区域IT组织各自为政，对新系统和技术缺乏协调。这些企业的转型的重点在于采用规范的架构设计，进而过渡到应用系统和数据全面整合的阶段。简言之，SOA成熟度是个发展过程，有待时日。图1-2 服务集成成熟度模型1.3 什么是面向服务的架构
SOA取胜之道在于架构。没有规范的架构，即使是一个灵活的系统（简单地通过程序、组件或配置），也不一定能适应较大范围的业务变动需求。所以，架构为纲，纲举目张。那么，什么是面向服务的架构呢。1.3.1 SOA的架构定义
首先看一下何谓架构（Architecture）。架构是指对于某个特定的目标系统所做出的具有通用性、系统性的抽象意义的表现。根据定义[IEEE 1471]：架构是组件，彼此间和与环境间的关系，引导设计发展原则中体现的系统的基本结构（原文：Architecture is the fundamental organization of a system embodied in its components，their relationships to each other，and to the environment，and the principles guiding its design and evolution）。通俗地说，架构包括：（1）组件/结构；（2）关系/环境；（3）指导原则。
顺便说明，古汉语中架构（Architecture）一词通常意译为“营造法式”，而其中的“法”，意即方法、风格，反映出了架构的深层含义。另外，架构也有被翻译为“体系结构”的，但体系结构似乎是局限于系统的组织结构及各相关元素的关联，而未包含重要的架构方法、指导原则等。
通俗地讲，“架构”是一种模型实体怎么建立的方法和框架原则、基本准则规范等。借用建筑业的一个名词，“框架结构”，作为公用知识我们都了解，一般建筑分为“砖混结构”、“混凝土框架结构”、“全钢架结构”等建筑类型。“砖混结构”的建筑与“混凝土框架结构”和“全钢架结构”的建筑最大的区别在于“砖混结构”的墙体是要承重的，我们俗称承重墙，墙体与柱子、地基是密不可分的一个整体，当这种结构的建筑修好之后，是不能随便拆除墙体的，拆除任何一个墙体对整个建筑的安全性都有影响。因此，砖混结构的房屋在进行二次装修时不能随意移动或拆除房间内的墙体。而“混凝土框架结构”的建筑重量完全承载于建筑的几根柱子和基础上，建筑的墙体不承受重量，只起到空间分隔的作用，因此，框架结构的建筑可以任意改变每个楼层空间分割和用途而不影响建筑的整体风格和安全性，每个楼层可以二次装修为商场、写字间、餐厅、KTV等，这种结构的建筑风格体现了随需应变的功能需求。因此，我们说“混凝土框架结构”就是一种构建满足灵活功能需求的建筑实体的“架构”模式。
SOA架构是业务架构与技术应用架构的综合体现。从1996年Gartner提出的多层计算体系共享企业应用逻辑的架构风格，到OASIS定义强调的分布式统一管控能力，分别反映了面向服务架构的主要目的。SOA架构依循架构框架模式，凸显关注点（参见后面章节），以灵活而重用的架构形式，简化业务各部分之间的互操作，获取业务的敏捷性及最终用户体验。值得注意的是，满足单一应用的项目需求实为易事，快速架构设计开发可以实现项目的业务需求，而SOA架构是为了“长治久安”，迈入更高层面的企业级灵活多变的业务需求。SOA倡导的是全方位架构，以正确的方法做正确的事，而正确的方法基于架构框架模式、架构指导原则及架构管控等。
区别架构与设计是SOA的重要一环。一般来说，架构包含设计，但设计并不一定是架构（Grady Booch:“All architecture is design but not all design is architecture”）。通俗地说，架构源于设计，而高于设计。架构体现的是黑盒子（Blackbox）效应，而非具体的白盒子细节。可以同样地说，SOA架构关心的是服务或组件的接口及关联（Context），而非其内容。如果关心具体的信息操作，或者是程序代码或配置文档，那是具体的技术设计。架构与设计之分主要是看其内涵。如果使用设计一词，或者说总体设计，那么，如图1-3所示，主要包括方案设计（Solution Outline）、概要设计及宏观设计（Macro Design）。
简言之，较之传统实体形式的应用设计架构，SOA架构具有更高层面的抽象性，反映在其对服务的定义。服务是对具体操作层面的组件或元素进行的封装。SOA架构起源于企业业务架构，注重客户需求，主要关心服务及服务接口。SOA应用架构侧重于整合，而非传统的软件架构设计。SOA架构强调企业架构的关联性，并更加注重于架构模式。SOA架构既包含技术成分，也包含艺术/抽象成分，虽然架构设计的艺术性相对比例较小。架构的目的是为了更好地指导设计与服务重用，而非设计细节。SOA架构的具体展现是全息视角的架构视图，同时考虑企业架构、业务架构与IT应用架构。图1-4反映出核心应用架构的定义范围，SOA应用架构是本书的重点，主要关注灵活重用的架构设计。图1-3 SOA架构设计过程范围图1-4 SOA核心应用架构的定义范围
什么样的“企业应用”才是灵活重用的架构呢？从图1-5可以看出，一个复杂的应用一定源自一系列的简单应用（称为服务组件），通过这些简单应用服务组件的逐级组装、流程编排形成一个复合的、多功能的应用系统。因此，只要我们按照这种以小积大的积木搭建方式来构建应用系统，该系统就是灵活的架构，也就是我们讲的“面向服务的架构”。因此，我们可以说“软件即组装”，应用系统是装配出来的，而不是代码写出来的（虽然最小的零件是由代码执行的）。换句话说，SOA的架构本身相对稳定，因而是推崇的架构。本书第2、3章将对复杂应用结构中涉及的“门户交互”、“业务流程”、“服务中介”等架构层面进行详细的阐述和分析。图1-5 复杂应用系统的组装结构1.3.2 SOA架构师的技能
传统上，架构师（Architect）专注于项目应用设计，而SOA架构师则更侧重于企业应用整合、纵观业务技术、横对一定层面的整体系统。鉴于SOA架构集业务架构与技术应用架构于一身的特点，SOA架构师应该同时具有业务与技术的能力，也就是我们通常所说的T字型或π型人才，并具有一定的IT激情。SOA架构师对于SOA项目起着关键的领导作用。一个良好的企业架构或业务架构落地到技术应用架构，其间的应用架构决定着系统的灵活重用层面。构建有效的SOA系统，首先得具有SOA的架构思维方式，以及兼顾IT/业务的能力。SOA架构师的角色非常全面，他往往身兼企业架构师、业务架构师及方案架构师，能够同时读懂业务语言及技术语言，起着翻译的作用。
在不少项目中，架构师一般偏于技术，技术与业务较为分离。程序员出身的“牛人”架构师往往重设计、轻架构、轻整合。缺乏经验的架构师往往把遗留应用系统看作是需要替代的东西。这往往是SOA架构沦为组件应用架构的主要原因之一。所以，一方面，SOA架构师应该尽可能多与业务人员沟通，并了解整个企业的战略规划；另一方面，SOA架构师应该加强自身的架构能力，而架构能力的提升得益于方法。
SOA架构师应该掌握以下五项架构技巧或技能（如图1-6所示）。（1）将用户需求与架构技术全面而客观地映射，寻找出用户蕴涵的主要关注点。（2）依循架构模式，包括架构原则及最佳实践，融入SOA架构关注点。（3）架构建模，将构建的系统经过一定的抽象，完善模型。主要架构模型包括服务组件模型、服务部署模型等。（4）从不同的架构视角，体现用户的关注点，反映出全息（Holistic）的架构模型。（5）迭代递增，循环校验，由粗及细，逐步完善架构设计。图1-6 SOA架构师应该掌握的五项架构技巧
本书所述的SOA架构方法，目的在于帮助SOA架构师以全方位IT系统的思维方式和以正确的方法指导架构设计。1.4 面向服务的全方位架构域
相对于SOA企业应用架构，大多数应用系统是单向、局部思维的。如果把这些应用系统比喻为交通工具，那么，SOA架构好比是交通调度系统。交通工具各具形态，如果规划不当，随着其规模的扩大，必然出现种种弊端：布局失调、交通拥堵、事故频繁。所以，SOA的架构过程是一个具有前瞻意识、循序渐进的过程，需要有全方位的架构体系。1.4.1 架构域的划分及关联
现在，我们看一下全方位架构（Panoramic Architecture）的主要内涵，它包括企业架构、业务架构及应用架构。图1-7为全方位架构域的划分。
企业架构划分为两个区域：业务企业架构及IT企业架构。业务企业架构对业务架构具有指导意义，而IT企业架构对应用架构具有指导意义。业务架构与应用架构通过服务建模架构进行关联，并且，业务架构对应用架构具有指导意义。
SOA的目的是提供或暴露出一系列服务供其他外部用户或系统使用，所以，服务仓库成为与外部世界连接的窗口。云端架构可以通过服务仓库形成独立于应用系统的客户应用，而情景架构（Situational Architecture）则是用户可以通过即用的服务接口及时生成的服务应用。情景架构是随需生成而能获取全面信息的灵活架构。通过服务仓库，情景架构形成独立于应用系统的客户应用，不依赖于特定系统或特定提供商。情景架构是未来的一种架构模式，它遵循一定的架构原则，由客户自己定义所需的应用，所生成的应用服务可取源于多种渠道，可随时替换。实现完全可视化的操作包括接入远程可视化服务组件，同时同一应用的界面及信息可来自不同的提供商，形成粗粒度但具灵活性的架构应用。情景架构是面向用户（User-oriented）的架构，因而无需架构技能，服务具有可操作性及易用性的特点。图1-7 面向服务的全方位架构
从SOA架构的角度，我们主要考虑的是企业架构的总体规划、企业的业务架构及架构设计核心部分的应用架构。在SOA架构时，以集成系统为核心，使用全息视图（Holistic View）的方法（以后章节详述）反映出完整一致的系统模型元素。1.4.2 企业架构
企业架构是SOA建设的基础。企业架构（Enterprise Architecture）从整个企业的角度审视与信息化有关的业务、信息、技术和应用之间的相互关系，以及这种关系对企业业务流所产生的影响。企业的业务架构以企业的业务战略为顶点，以企业各主营业务为主线，以企业各辅助业务为支撑，以人流、物流、资金流、信息流等联络各业务线，构成贯彻企业业务战略的企业基本业务运作模式。企业的IT架构涉及信息架构、应用架构和基础设施。简言之，企业架构包括业务与IT两个重要方面，对于应用方案架构，起着规范性约束的作用。
企业架构的最早应用是在美国的政府一些机构。1996年美国的Clinger-Cohen 法案（以前被称为信息技术管理改革法案）导致了术语“IT架构”（现在被解释为IT企业架构）的产生，要求每个政府机构都要具有企业架构框架，并符合一定标准来分析、跟踪和评估IT系统大规模投资的风险及成效。我们常用的企业架构方法有TOGAF、DoDAF/MODAF、FEAF、Zachman等。每个企业架构方法有其特定用途，例如，政府机构可以参考FEAF，通用框架可以参考Zachman或TOGAF。目前常用的企业架构建模语言有开放群组（Open Group或有翻译为公开组织、开放组、开放组织）的ArchiMate，常用的企业架构工具有Telelogic System Architect等。
我们先来看一下企业架构市场占有率过半的TOGAF。TOGAF支持开放标准的SOA架构，TOGAF 9更是注重与业务对齐。图1-8所示的是TOGAF的ADM（Architecture Development Method）方法的基本结构。ADM方法可以用10个圈的内容形象说明以此表明顺序及相互依赖关系。每个阶段（Phase）需不断地与原先期望值进行校验，是一个迭代过程。每个阶段又进一步分成步骤（详细参阅：http://www.opengroup.org/togaf/）。ADM用于大型复杂的系统，通常是采用自上而下的方法形成通用的参考架构。不过，ADM也有用于非企业架构目的的，例如，通用项目管理方法。图1-8 TOGAF的ADM方法
作为企业架构框架的鼻祖，IBM的Zachman早在1987年就指出了信息系统架构的重要性，并随之产生了著名的Zachman框架（如表1-1所述）。Zachman框架是一个6×6矩阵：纵向划分为规划者、业务所有者、设计者、构建者、分包者和最终用户六个视角，建立目标/范围、业务模型、系统模型、技术模型、详细表达、运行功能等模型；横向划分为数据（What）、功能（How）、网络（Where）、人员（Who）、时间（When）、动机（Why）等六个方面的模型，以此来表明架构视图与视角的关联。表1-1 Zachman框架
DoDAF常用于复杂的系统（System of Systems）架构，适用于实际的项目，而非规划层面。从不同的视角，通过不同的视图，反映某个涉众所关注的系统结构。图1-9为DoDAF的主要高层视图关联。通过不同视角与视图关联，形成矩阵，以此勾画出整个架构。该方法具有独到之处的是操作视图，详细描述开发系统所依赖的外部用户系统的操作环境。图1-9 DoDAF的主要高层视图关联
企业架构与SOA架构在不少方面不谋而合，因为两者都是针对大规模的复杂系统，而且架构思维模式有相近之处。比较而言，SOA侧重于业务建模及服务层面的应用架构。在SOA项目中，借鉴企业架构的指导，通过应用架构，将业务技术进一步细化落地。
实际上，各个企业的企业架构产出件详细程度不尽相同，有企业蓝图层面的，也有具体指导企业系统落地的。对于SOA而言，企业架构往往作为指导原则的依据，业务梳理主要通过业务架构进行。在国内的实际工作中，我们见到的有些企业架构，也许是距离地面很高的企业架构规划（Enterprise Architecture Strategic Plan，EASP）不一定完全依照企业架构方法。一般情况下，如果一个企业没有规范的企业架构，SOA架构的力度就会加大。不过，SOA架构从一定层面，也可以弥补或增进企业架构。下面，我们看一个侧重于信息化的企业架构规划提纲示例（如表1-2所述）。表1-2 企业信息架构规划提纲
由此可见，这里所指的EA（企业架构）是高层次的企业战略架构规划，与SOA密切关联。一般来说，企业架构主要由业务架构与IT架构两大部分。从业务架构的角度，主要关心的SOA问题在于：需要什么服务？如何管控？从IT架构的角度，主要关心的SOA问题在于：什么是设计、构建、操作服务的最佳途径？图1-10是基于企业架构（TOGAF）的业务服务所折射出的高层SOA服务视图，从中可以看出，左侧的技术人员所描述的服务与右侧的业务人员所描述的服务相差径庭。图1-10 基于TOGAF的高层SOA服务视图
从架构域来看，EA与SOA具有许多相同之处及不同的重点所在（如表1-3所述）。所以，在从事SOA架构项目时，要同时考虑企业架构，以免忽视企业IT的总体需求，但也要避免重复架构、明确重点。例如，SOA并不强调内容管理架构（EA的重点之一）。表1-3 EA与SOA重点比较
本书作为实际SOA项目经验的概括总结，借鉴以上企业架构的思维方式，从业务与技术两个侧面，偏重于架构技术，进行SOA架构设计，将企业架构规划所制定的指导思想、策略、标准、应用框架等作为SOA项目的重要关键输入。由于SOA架构与企业架构互为作用，SOA架构实际上跨越连接企业架构、局部架构及解决方案架构（如图1-11所示）。图1-11 SOA架构的作用范围
本书采用的相关企业架构产出件包括企业规划、差距分析、应用架构、企业环境、架构原则及组织结构等，并体现与SOA相关联的企业架构主要的方法及步骤。简言之，本书的SOA架构设计方法起着连接企业架构与应用架构的桥梁作用，形成独到的端到端的企业应用架构方法体系。如果将企业架构规划比喻为城市规划，传统应用比喻为建筑物，那么SOA则是促使城市规划落地生效并持续性发展的、具有规范性约束的主导性构建体系。1.4.3 业务架构
SOA项目把EA业务架构作为驱动点，选择动态的价值分析和静态的业务模型分析。实现人、过程、信息几个方面信息的集成和整合。业务架构和信息架构相互匹配，通过对业务流程的分析和梳理、IT现状能力的分析和评估，寻找出差距和机会点。同时，业务架构也是企业架构规划的重要组成部分或入手点。
值得注意的是，业务架构可分为两个层次：上层的企业架构与下层的项目方案（Solution Layer）。从SOA项目的角度来说，业务架构更加偏向于方案层面。所以本书所使用的业务架构指的是项目方案层面的业务架构。
SOA以业务为导向的指导原则决定了业务架构的必要性及重要性，业务架构的成效决定了整个SOA项目的结果。业务架构一般包括业务组件模型（CBM–Component Business Model，参见第3章的业务模型视图），但CBM并非一定意味着采用SOA。
服务建模是业务架构连接应用架构的重要桥梁，服务建模成为业务架构的一部分。本书所述及的业务架构主要强调服务建模。服务建模关系到SOA架构是否松散耦合，也成为SOA项目成功与否的关键。当然，服务建模还得经由应用架构细化验证，才具有可行性。
也许有人要问，现在各行各业都有其ERP业务系统，那么，有了ERP是否还需要SOA业务架构呢？我们在第5章对ERP与SOA做了比较分析。简单而言，ERP、PDM等现有系统注重的是规范办事流程、减少完成单项任务的时间，这对于提高单项任务的质量、效率、缩短单项任务的处理时间十分重要。但在业务处理过程中，用于单元业务处理的时间只占20%；其余80%的时间则花费在单元业务的等待、排队，跟踪或衔接等过程，这类过程并不能为企业创造价值。尽管企业的信息化建设改进了单元业务的处理效率，但常常不能真正提高整体效率，因而如何完善梳理业务架构，改善整体业务运转的性能就成为提升企业效率和竞争力提升的关键。1.4.4 应用架构
对于架构师，应用架构应该是最为熟悉的，因为传统上，架构师的主要职责是应用架构设计。在SOA项目中，应用架构与业务更加关联，主要表现在架构的业务流程以及服务层面。SOA需要全方位的架构思考方式，自上而下，浑然一体，使IT与业务加大重叠。
由于与业务关联密切，SOA的应用架构区别于传统的应用架构。本书侧重于SOA应用架构，其包含传统的应用架构、信息架构及技术架构（如图1-12所示），并且辅之于流程及服务。书中所提及的应用架构一般是指SOA应用架构、应用方案架构或SOA解决方案架构（SOA Solution Architecture），而非传统的应用设计层面。图1-12 SOA应用架构与传统应用架构1.5 面向服务的框架模式
无论是哪个行业或哪个应用领域，SOA企业架构都有其共同特点。SOA依据一定的框架，有其一定的规范。通常情况下，参考架构、设计模式、行业框架、应用框架起着指导SOA企业应用架构的作用，同时也是资产重用的一个表现形式。面向服务的框架模式包括：SOA参考架构、SOA设计模式、行业框架和企业级的应用框架等。
框架模式具有通用性和重用性，不针对某一个SOA项目。在SOA项目时，除了框架模式的指导外，还要依据现有企业业务架构以及现有企业架构、现有系统架构等现有IT环境通盘考虑SOA架构设计。
参考架构、设计模式及框架的概念容易混淆。那么，它们是如何定义区分的呢？我们可以参见OMG（Object Management Group）组织所制定的重用资产规约（Reusable Asset Specification）。如图1-13所示，重用资产的划分基于三个维度：集合性（Granularity）、可变性（Variability）以及具体性（Articulation）。集合性是指某一资产可以解决多少问题的能力，例如，单一解决方案（Single）或是集成方案（Collection）。可变性是指某一资产可以修改或定制的能力，例如，基本不能修改（Little）或完全可以定制（Complete）。具体性是指某一资产可以落地的程度，例如，规约层面（Specification）或执行层面（Implementation）。图1-13 重用资产划分的三个维度
据此，我们可以看到，设计模式较为可变，参考架构较为集成，应用框架较为具体。当然，在具体使用这些名称时，要看其内容含义。例如，人们通常所说的行业框架有时实际上只是行业参考架构而已。1.5.1 参考方案架构模式
SOA参考方案架构是每个SOA项目必须遵循的。图1-14所示深色部分为SOA五个切入点整合层面。其中，关键的是业务流程层以及服务层。业务服务或复合业务服务是传统应用架构所不具有的。图1-14中其他部分是基础或辅助层面，其中，着重于AOP模式的横切面服务包括如下。信息架构：主要是衔接传统信息架构，提供共享模型。集成服务或企业服务总线（Enterprise Service Bus，ESB）：主要是作为消息流、信息流的连接转换，转换通常由中介服务模块来完成。服务质量管理：针对SOA架构所必须的服务质量管理产品、技术或平台。服务监管：包括服务注册、服务的生命周期管理等。图1-14 SOA参考方案架构
值得注意的是，参考方案架构模式并非只是从项目方案层面考虑SOA架构设计，而应反映出企业架构的作用关系。如果SOA项目只是注重在项目层面，很有可能不能满足整个企业的业务技术需求或长远规划。所以，在SOA项目中，参考方案必须满足企业架构及业务架构的要求或同时迭代进行。表1-4为SOA与EA架构层面重点的映射关系。表1-4 SOA与EA架构域映射关系
另外，我们可以依循OASIS制定的SOA参考模型（OASIS SOA Reference Model），对于SOA架构进一步规范指导。1.5.2 SOA设计模式
设计模式起源于建筑设计大师Christopher Alexander的著作“建筑的永恒之道”（ The Timeless Way of Building ）。“永恒之道”意味着按照特定模式系统化、条理化的渐进式架构设计过程SOA企业应用架构广泛采用设计模式。这里来看一个“服务分解”设计模式的描述样例，如下所示。
具体细节可参见 Thomas Erl编写的“SOA Design Pattern”（SOA设计模式/样式）。不过，值得提醒的是，不要太追究于设计模式的细节。如果读者熟悉组件或面向对象的设计模式，其很多方面可以借鉴。同时，应注意不要将简单问题复杂化。SOA架构设计模式的特点主要是服务的分层、粒度及接口设计。接口的考虑重点无非是服务消费者（Consumer）、服务提供者（Provider）、服务查询者（Service Locator），以及服务中介者（Service Broker/Agent）。
如表1-5所示，架构设计模式具有多种形式。在SOA架构设计中，主要使用架构模式而非设计模式。SOA常使用的架构模式包括面向服务的模型框架SOMF（Service-oriented Modeling Framework）
试读结束[说明：试读内容隐藏了图片]