作者：叶树江、耿生玲、谢锟、郭炳宇、姜善永
出版社：人民邮电出版社有限公司
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
数据共享与数据整合技术试读：
前言
在这样一个数据信息时代，以云计算、大数据、物联网为代表的新一代信息技术受到空前的关注。教育战略服务国家战略，相关的职业教育急需升级以顺应和助推产业发展。从学校到企业，从企业到学校，华晟经世已经为中国职业教育产教融合这项事业奋斗了15年。从最早做通信技术的课程培训到如今提供以移动互联、物联网、云计算、大数据、人工智能等新兴专业为代表的ICT专业群人才培养的全流程服务，我们深知课程是人才培养的依托，而教材则是呈现课程理念的基础。如何将行业最新的技术通过合理的逻辑设计和内容表达呈现给学习者，并达到理想的学习效果，是我们开发教材时一直追求的终极目标。
在这本教材的编写中，我们在内容上贯穿以“学习者”为中心的设计理念——教学目标以任务驱动，教材内容以“学”和“导学”交织呈现，项目引入以情景化的职业元素构成，学习足迹借图谱得以可视化，学习效果通过最终的创新项目得以校验，具体解释如下。
1.教材内容的组织强调以学习行为为主线，构建了“学”与“导学”的内容逻辑。“学”是主体内容，包括项目描述、任务解决及项目总结；“导学”是引导学生自主学习、独立实践的部分，包括项目引入、交互窗口、思考练习、拓展训练及双创项目。
2.情景化、情景剧式的项目引入。模拟一个完整的项目团队，采用情景剧作为项目开篇，并融入职业元素，让内容更加接近于行业、企业和生产实际。项目引入更多地还原工作场景，展示项目进程，嵌入岗位、行业认知，融入工作的方法和技巧，更多地传递一种解决问题的思路和理念。
3.篇章以项目为核心载体，强调知识输入，经过任务的解决与训练，再到技能输出。采用“两点（知识点、技能点）”“两图（知识图谱、技能图谱）”的方式梳理知识、技能，在项目开篇清晰地描绘出该项目所覆盖的和需要的知识点，在项目最后总结出经过任务训练所能获得的技能图谱。
4.强调动手和实操，以解决任务为驱动，做中学、学中做。任务驱动式的学习，可以让我们遵循一般的学习规律，由简到难、循环往复、融会贯通；加强实践、动手训练，在实操中获得的学习经验将更加直观和深刻；融入最新技术应用，结合真实应用场景来解决现实性客户需求。
5.具有创新特色的双创项目设计。教材结尾设计双创项目与其他教材形成呼应，体现了项目的完整性、创新性和挑战性，既能培养学生面对困难勇于挑战的创业意识，又能培养学生使用新技术解决问题的创新精神。
本教材一共6个项目，项目1为SOA基础知识导入，主要介绍了SOA的基本概念、发展历程，与企业IT战略之间的关系；项目2介绍了Web服务的相关基础知识，包括Web服务的体系结构特性、服务规范、SOAP、WSDL、UDDI等；项目3介绍了ESB的相关知识，明确了ESB与EAI之间的关系，介绍了SOA思想针对实际问题的具体实现思路，重点讲解了iESB引擎和iESB设计器的安装配置方法；项目4至项目6比较了REST和SOAP两种WebService方式的差别，并通过模拟校园中常见的多个信息系统整合开发应用场景，介绍了iESB暴露出来的服务在多系统的整合当中是如何被调用的以及不同的系统之间如何通过iESB实现数据共享，从而加深了对数据共享与数据整合技术在实际应用中的解读。
本教材由叶树江、耿生玲、谢锟、郭炳宇、姜善永老师主编。主编除了参与编写外，还负责拟定大纲和总纂。本教材执笔人依次是：项目1叶树江，项目2耿生玲，项目3谢锟，项目4杨慧东，项目5刘静，项目6李慧蕾。本教材初稿完结后，由郭炳宇、姜善永、王田甜、苏尚停、刘静、张瑞元、朱胜、李慧蕾、杨慧东、唐斌、何勇、李文强、范雪梅、冉芬、曹利洁、张静、蒋平新、赵艳慧、杨晓蕊、刘红申、黎正林、李想组成的编审委员会相关成员进行审核和内容修订。
整本教材从开发总体设计到每个细节都饱含了我们团队的协作和细心打磨，我们希望以专业的精神尽量克服知识和经验的不足，终以此书飨慰读者。
本教材提供配套代码和PPT，如需相关资源，请发送邮件至renyoujiaocaiweihu@huatec.com。编者2018年7月项目1 SOA基本概念初探
项目引入
我叫Alphonse，是一名非资深Java程序员，刚刚入职软件公司，就职IT业务部。刚来公司，我就听主管Edward说，公司的信息化建设相对滞后，CIO决定实施SOA（面向服务的架构）改造，对现有种类繁多的信息服务系统进行重新治理。
Edward仿佛从我的眼神中看出了一丝慌乱，告诉我不用着急：“这个新闻你先看一看，了解一下SOA的重要性，然后咱们再慢慢熟悉SOA的基本概念。”
银行业反思：如果用SOA就不会发生金融危机
2009年09月02日 13:15 中国计算机报
21世纪初，在全球金融崩溃前的那段平静的日子里，我遇到了一位曾在花旗集团任职的朋友——斯克普·斯诺。他虽身任花旗集团企业架构部高级副总裁，但并不高兴。
在花旗集团的时候，他一直在企业内全力推行SOA，但最终却在这场战争中输了。斯克普说，假如他或者其他金融巨头的IT系统架构师最终取得胜利的话，这场金融危机将不会发生。他表示，SOA的应用能够很容易地对即将发生的金融风险进行预警。但可惜的是，企业的各个部门并不愿意在SOA的应用方面花费太多的精力。
IT系统架构师看到了其中的好处，但是公司内各个部门由此能够得到什么好处呢？当时，这些部门可以很容易地赚到大把的钞票，因此，这些部门的领导人对SOA并没有太多的热情。事实上，公司采用的是相对固定的薪酬模型，即使在采用了SOA之后，也不会为员工带来额外的利益。
他说：“无论是IBM、Oracle还是HP，都希望保住自己在企业中已经占有的领地。如果应用SOA，他们固有的利益怎么办呢？因此，他们对此并不感兴趣。”
这些大的供应商都想将你锁定在他们的私有体系内，而像花旗这样的大公司，其内部的多个系统也只能在有限的情况下互联互通。
这种缺乏整合的情形很具有讽刺意味。1999年颁布的Gramm-Leach-Bliley法案消除了大萧条时期对于禁止同一家金融机构同时承担银行业务、投资银行业务以及保险服务。该法案使得抵押担保债券这一综合性的业务成为可能，但正是此种债券使全球的金融系统崩溃，因此该法案饱受谴责。因为原有的三大业务系统始终保持相对独立，很难整合到一起，因此产生了很多未知的风险。而这些新的必然都逃出了“监控雷达”的范围。
根据斯克普所说，花旗集团有多个未整合的风险管理系统，以及多种格式并不统一的账簿，管理人员无法将各种格式的数据统一到一张表格中。斯克普推测，如果公司的高层意识到了他们在抵押贷款的价值方面正处于急速下降的趋势，他们可能就会在崩溃之前摆脱这类资产。
看完这则新闻，我惊呆了，SOA竟然这么重要，影响这么深远，那我可得打起百倍精神努力打好基础。
Edward接着解释道：“SOA战略(包括业务流程管理和软件服务方法)作为一种技术创新可以有效助力企业调整业务流程和削减经营开支。当企业需要减少经营成本时，必须要查看业务流程，也许有一些集成，也许有一些人工活动，我们也许会在那些不必要的业务流程中损失许多收入。目前软件行业也不像以前那样遍地黄金了，未来只有勇于变革、精细经营的企业才能渡过难关，而SOA在经济衰退期间能发挥非常重要的作用。从历史上看，强大的公司在这种动荡的时期将会变得更加强大，能够处于更有利的地位迎接下一次的经济繁荣。”
他列举了麦肯锡（Mckinsey）从1982年至1999年研究的1000多家公司的例子。通过对麦肯锡的研究，他发现，当行业领导者在经济衰退中退出的同时，新崛起的公司是那些在经济衰退期间在基础设施方面投资最多的公司。“所以，这些公司不是仅守着现金和削减成本，实际上是在基础设施方面进行了技术创新，让自己等待着繁荣时期到来。”Edward语重心长地说。
Edward的话让我深深意识到SOA的重要性。嗯，接下来我要元气满满地投入到SOA基本概念的学习中去了，小伙伴们，一起加油哦！
知识图谱
项目1知识图谱如图1-1所示。图1-1 项目1知识图谱1.1 任务一：什么是SOA【任务描述】
刚来公司就可以接触改造SOA这么大的项目，我既兴奋又感到时间的紧迫，领导说了，对于我这个SOA新人来说，第一步，就是先熟悉SOA的基本概念。这就是我们要完成的第一个任务：了解什么是SOA。1.1.1 SOA的基本概念
SOA的英文全称是“Service Oriented Architecture”，翻译成中文有很多种意思：“面向服务的体系结构”“以服务为中心的体系结构”和“面向服务的架构”，一般我们将其翻译成“面向服务的架构”。SOA基本上可以分为两类，SOA主要是一种架构风格；SOA是包含运行环境、编程模型、架构方法和相关方法论等在内的一整套新的分布式软件系统方法和环境。第二类概括的范围更大，它涵盖服务的整个生命周期，即建模—开发—整合—部署—运行—管理，着眼于未来的发展，SOA是分布式软件系统架构方法和环境的新发展阶段，所以我们更倾向于后者。
在SOA风格中，最核心的抽象手段是服务，业务被划分为一系列粗粒度的业务服务和业务流程。业务服务具有相对独立、自包含、可重用的特点，由一个或多个分布的系统实现，而业务流程则是由服务组装而来。一个“服务”定义了一个与业务功能或业务数据相关的接口，以及约束这个接口的契约，如服务质量要求、业务规则、安全性要求、法律法规的遵循、关键业绩指标（Key Performance Indicator，KPI）等。接口和契约采用中立、基于标准的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同系统中的服务可以以统一和通用的方式进行交互。除了这种不依赖于特定技术的中立特性，我们还可以通过服务注册库（Service Registry）加上企业服务总线（Enterprise Service Bus，ESB）来让系统支持动态查询、定位、路由和中介的能力，这样就使得服务之间的交互是动态的，位置是透明的。
技术和位置的透明性，这使得服务的请求者和提供者之间高度解耦。这种松耦合系统的好处有两点：一点是它适应变化的灵活性；另一点是当某个服务的内部结构和实现逐渐发生改变时，不会影响其他服务。而紧耦合则是指应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当人们对应用程序的功能需求发生变化时，某一部分的调整会随着各种紧耦合的关系引起其他部分甚至整个应用程序的更改，这样的系统架构就很脆弱了。
例如，某学校需要开发一个移动办公系统，需要全校老师的用户信息，如果在系统中一一添加，不仅工作量巨大，还可能出现信息与学校人事管理系统中的信息不一致的现象。解决办法就是直接从人事管理系统中调用和读取用户信息。
从人事管理系统中提供用户信息，这就是一个服务，即人事管理系统的一个功能单元。那么通过什么方式把服务提供出来呢？这就涉及接口的概念，所谓接口就是服务方和使用方都能够识别的对接方式，采用标准的接口协议，例如Socket协议、WebService协议等。
这种应用程序之间交互的方式采用的是接口，而不是直接调用程序，因此对于程序内部的业务逻辑变化，只要接口不变，就不会影响使用方的系统，这个就是松耦合的概念。
任何企业、组织都有各种各样的应用，应用之间都会有交互，如果应用之间直接调用对方的接口，就会形成蜘蛛网状。ESB就是把各个应用提供的接口统一管理并将其暴露出来，所有的应用接口都通过SOA平台交互，避免了业务之间的干扰。SOA对服务接口的统一管理如图1-2所示。图1-2 SOA对服务接口的统一管理
SOA带来的另一个重要观点是业务驱动IT，即IT和业务更加紧密地对齐。以粗粒度的业务服务为基础来对业务建模会产生更加简洁的业务和系统视图；以服务为基础来实现的IT系统更灵活、更易于重用、能更好（也更快）地应对变化；以服务为基础，通过显式地定义、描述、实现和管理业务层次的粗粒度服务（包括业务流程），提供了业务模型和相关IT实现之间更好的“可追溯性”，减小了它们之间的差距，使得业务的变化更容易传递到IT。因此，我们可以将SOA的主要优点概括为IT能够更好更快地提供业务价值、快速应变能力、资产重用。
从演变的历程来看，SOA在很多年前就被提出来了，现在SOA的再现和流行是若干因素的结合。一方面是多年软件工程的发展和实践所积累的经验、方法和各种设计/架构模式，包括EAI和中间件；另一方面是互联网的多年发展带来前所未有的分布式系统的交互能力和标准化基础。与此同时，企业越来越重视业务模型本身的组件化，以支持高度灵活的业务战略。但是现有的企业软件架构不够灵活，难以适应日益复杂的企业整合，难以满足随需应变的商务需要，因此与业务对齐、以业务的敏捷应变能力为首要目标、松散耦合、支持重用的SOA方法得到世界众多企业的青睐。
SOA容易混淆的几个基本问题如下。
第一，SOA是架构风格、方法，而不是具体架构、具体实现技术（如WebService）、具体架构元素（如ESB）。
经常有人认为只要用了WebService，就是SOA，这个观念是不对的，WebService只是实现服务的一种具体技术表现形式；同样，认为建设SOA，就是购买软件，建个ESB，这也是不对的，ESB只是SOA风格中的一部分。首先，ESB是一种从实践中总结出来的架构风格元素，即BUS（总线模式）；其次，ESB的主要功能是负责连通性和服务中介（Service Mediation），解耦服务的请求者和服务的提供者。
第二，SOA的首要目标是IT与业务对齐，支持业务的快速变化；其次是重用IT架构的灵活性和IT资产的重复利用。
业务对敏捷性的需要，是SOA最大的驱动力。一方面是业务在这方面的要求越来越高；另一方面是目前的IT技术还不够灵活，很难适应业务快速变化的需求。不仅仅是因为IT架构不灵活，更重要的是业务模型中的元素和IT系统的元素之间存在很大的差距，这种不对齐，导致业务人员和IT人员之间的沟通差异，业务的变化需要花费很大的代价传递到IT系统。这种业务和IT的对齐，需要在IT系统中实现更高阶的抽象元素，就是业务模型中的元素（服务、流程、业绩管理），并且需要满足业务需要的水平整合（将人、信息、应用和流程端到端地动态整合起来）。这样就形成了一个以服务为中心的、端到端整合的环境，首先使得业务变化可以在业务元素的层面上沟通得更加更容易、更准确地从业务传递到IT。其次，这种变化被隔离在需要变化的局部，而不扩散到系统的其他部分。这就需要整个IT架构本身是松散耦合的，一个服务的变化（功能、数据、过程、技术环境等）不影响其他服务。最后，我们希望这些反映业务元素的服务，是相对稳定、可以重用的，这对快速适应变化、减少成本是非常重要的。
第三，在工程上，SOA的重点是服务建模和基于SOA的设计原则进行架构决策和设计。
经常碰到客户提出这样的问题：SOA挺好，为什么好？怎么做才是SOA的方法？与过去的方法相比，和其他（如OO/CBD）有什么不同？有时候用一个J2EE服务器就好了，为什么那么复杂地建设SOA？
从建模和设计的角度来说，SOA更多地侧重在业务层次上，也就是通过服务建模将业务组件化为服务模型，它是业务架构的底层，是技术架构的顶层，它负责承上启下，是灵活的业务模型和IT之间的桥梁，保证二者之间的“可追溯性”。从技术架构的顶层往下的具体设计，是基于已有的方法，比如从OO/CBD来进行的。从架构的层次上看， SOA更多地侧重于如何将企业范围内多个分布的系统（包括已有系统/遗留系统）连接起来（ESB、Adapter/Connector），比如如何将它们的功能、数据转化为服务？如何通过服务中介机制（ESB、Service Registry）保证服务之间以松散耦合的方式交互？如何组装（集成）服务为流程？如何管理服务和流程等？从不同的服务之间的交互往下是对于实现各个服务的一个具体应用，它的架构、设计和实现可以基于已有的实践和方法应用，比如J2EE或.NET。
有时，由于业务需求比较简单，所有这些东西都在一个J2EE的应用服务器上，有些要素不是那么突出，不过随着系统规模的扩大，要解决的业务问题更复杂、涉及范围更大时，SOA的各种架构要素就会变得越来越重要。1.1.2 SOA发展的驱动力
SOA技术在IT界掀起巨大的狂潮，然而它不同于以前的模块化编程，它面向对象、Web技术等技术变革，它们不论多难理解，总是能很快被大家接受，SOA之所以让很多人觉得难以理解，是因为它不再单纯地从IT从业人员的角度理解IT系统，而是从业务人员的角度分析IT业务系统。
有两种现象相继呈现：一方面是企业SOA改造，精简企业业务流程，提升企业市场竞争与创新的能力，企业IT部门成为了企业管理的核心链条——“神经系统”；另一方面是很多企业觉得无从下手，SOA太空无实，业务部门人员不愿支持，业务流程改造单靠IT部门难以完成，而企业内非IT部门，尤其是管理层对SOA了解得还很少。
1.业务驱动
SOA的概念早在20世纪就已提出，近两年在许多大公司相关产品与业绩推动下，它才进入了实际应用的黄金阶段。
SOA的出发点是从业务角度重用应用系统的开发元素，最大限度地降低IT系统开发与维护的成本。很多企业的CIO都面临一个共同的问题：随着网络建设的浪潮，各种业务系统的开发如雨后春笋，一些大型企业，需要维护成百上千个业务系统是很常见的事，从机房配置、服务器管理、各种支撑系统的维护都让IT部门难以应付，更不用说被病毒攻击过后的清理系统与恢复业务工作，仅仅是查看各个业务系统的状态，就需要工作人员花很长时间，对于保障业务的持续性，更是繁复之至。业务系统的繁多与各自孤立，为新业务的上马带来更大困难，重复开发造成极大的浪费，信息不互通让每个系统都“麻雀虽小，五脏倶全”，企业失去了市场竞争的灵活性，这些弊端都极大地触动了企业管理者的神经。
很多大型公司开始推广ERP之类的大型企业软件系统，希望在一个庞大系统架构中，可以融合更多的业务流程，各个业务的信息可以交流，避免各个“业务孤岛”带来的管理弊端与效率低下。然而随着单个系统的庞大，开发的难度呈指数般提升，要考虑的因素太多了，客户业务又千差万别，企业的管理成为极大瓶颈；另外“同制化”的设计模式恰恰抹杀了企业的创造力，而失去了“特点”的企业等于选择“自杀”。考虑到IT基础架构如何适应企业的“创造化”需求、新业务的开发如何快捷、如何降低IT支撑系统的管理成本并提供持续性的服务保障等需求，CIO们重新选择了SOA。
在这种情况下，SOA重新被提出来，SOA是一种IT技术框架，是一种最佳实践，而不是一种具体的技术，能实现SOA的技术很多，如何选择的关键是能否达到SOA提出的业务灵活度的目标。
对于SOA的思路，其实IT开发人员中有过类似的想法，我们回顾一下编程人员走过的历程：模块化编程提炼可重用的程序，方便调用，提高软件的结构性；后来发展到面向对象，把数据与程序封装在一起，让软件设计人员的思路逐渐接近现实的人类思维方式；B/S架构的推广将客户端的维护变得简单化，业务更适合于网络方式；Web2.0的发展解决了B/S体系的交互问题；中间件技术让跨平台、跨语言的业务开发变得容易，IT开发人员一直在探索、提炼可以重用的、优秀的软件模块，以便使我们的业务系统开发如搭积木一样容易。
虽然SOA是IT开发人员的思路，但推动SOA的是企业管理层，SOA是业务驱动发展的，而不是由技术驱动发展的。从新的视觉角度看，并非所有的企业CIO们对SOA都得心应手。
我们不再从IT开发人员的眼光看待要开发的业务系统，而是从业务的使用者角度看待要开发的系统，面向服务就是面向系统的实际使用者，“谁干谁说了算”，系统应该具备什么功能，应该做成什么样子，要看用户使用的效果。简单地说，就是用“敏捷”的开发思路，代替“闭门造车”的开发方式。所谓敏捷就是用户的参与，用户不懂你的专业“语言”，就需要快速的模型与界面展现，快速展现不重用是不现实的，而用户理解不从业务流程入手，是与用户没有共同语言的。
2.计算环境的演变（1）计算环境
计算环境由一组计算机、软件平台和相互联通的网络组成，这个环境能够处理和交换数字信息，允许外界访问其内信息资源。不同的计算环境有不同的计算风格和编程模型，由一些特定于该计算环境的技术来支撑。如何在一个计算环境中分割和部署计算能力、数据资源，如何让各个部分相互通信和协作，如何在概念上对问题域进行建模，然后映射到该计算环境，都会受到计算环境的影响和制约。因此，了解计算环境的历史，会帮助我们理解面向服务的计算环境是如何演变而来的。（2）计算环境的演变历程
计算环境的演变经历了若干个阶段，在早期的主机时代，绝大多数的计算功能和系统的组成部分，都在一台机器里。在二十世纪八十年代，随着PC的繁荣发展，计算环境发生了很大的变化。通过局域网相互连接的计算设备构成客户/服务器计算环境，计算资源和数据资源被适当地分割，客户和服务器通过网络协议、远程调用或消息等方式相互协作，完成计算。
为了满足更高的可伸缩性需求出现了多层架构，计算资源和数据资源的分布多样化，集成企业中原来已经存在的计算环境、尤其是主机及其遗留系统之间的集成也变得越来越重要。中间件迅速发展，开始出现分布式对象、组件和接口等概念，用于在计算环境中更好地分割运算逻辑和数据资源。计算环境中不同部分之间的交互，也从原有相对底层的网络协议、远程调用和消息机制的基础上，发展到支持分布式对象、组件和接口之间的交互，这种交互在名字服务（Naming Service）等的支持下，通常是位置透明的。但由于缺乏普遍的标准化支持，很难做到技术透明，系统是紧耦合的。
随着互联网的发展，开放和标准的网络协议被普遍支持，所有底层计算平台都开始支持这些标准和协议，这导致一个计算环境内部和各个计算环境之间交互的屏障被打破。数据和功能的表示与交互在XML、Web服务（WebService）技术与标准的基础上，保证了通用性和最大的交互能力，这使得计算环境发展到一个全新的阶段——基于标准、开放的互联网技术的计算环境。在这样的计算环境中，各个部分可以采用异构的底层技术，它们使用XML来描述和表示自己的数据和功能，采用开放的网络协议（如Http）来握手，在此之上，基于Web服务来进行互操作和交换数据。在这里，一个很重要的新概念是服务，它是一个自包含的功能，使用者通过明确定义的接口（契约）来与一个服务交互，这个接口的描述基于WSDL（WebService Description Language，网络服务描述语言）的开放标准。对象和组件重在表示一个事物本身的组成部分和相互关联（也就是WHAT“THINGS”ARE的问题），而服务则表示一个事物做什么（也就是WHAT“THINGS”DO的问题）。Web服务是实现服务的技术手段，就如同各种编程语言中的对象是实现对象的技术手段，J2EE中的EJB是实现组件的技术手段一样。这种基于标准、开放的互联网技术，以服务为中心的计算环境，我们称之为“面向服务的计算环境”。（3）面向服务的计算环境
在面向服务的计算环境中，系统可以是高度分布、异构的。它一般包括服务运行时环境、企业服务总线、服务网关、服务注册库和服务组装引擎等，如图1-3所示。图1-3 SOA计算环境的组成要素
服务运行时环境提供服务（和服务组件）的部署、运行和管理能力，支持服务编程模型，保证系统的安全和性能等质量要素；服务总线提供服务中介的能力，使得服务使用者能够以技术透明和位置透明的方式访问服务；服务注册库支持存储和访问服务的描述信息，是实现服务中介、管理服务的重要基础；而服务组装引擎则将服务组装为服务流程，完成一个业务过程；服务网关用于在不同服务计算环境的边界进行服务翻译，比如安全。
面向服务的计算环境是开放的、标准的，由图1-4所示的技术标准协议栈所定义和支持的。例如，Transport层的Http、Service Description层的WSDL、Business Process层的WS-CDL，以及与Policy相关的WS-Policy。本书后面的项目将讨论所有统称为WS-*的标准和协议。图1-4 SOA计算环境的标准协议栈
面向服务的计算环境为我们所定义的随需应变的计算环境奠定了现实基础。随需应变的计算环境应具备以下特点，如图1-5所示。图1-5 随需应变的计算环境应该具备的特点
①整合：将人、过程、应用和数据全面整合起来。
②虚拟化：将分布、异构的物理资源（服务器、存储设备等）整合起来，呈现为统一的逻辑对象，以安全和可管理的方式使用。
③自主化：如同生物体一样，系统具备一些高级生物系统的能力，包括自我诊断和修复问题、自动配置和调整以适应环境的变化、自动优化资源的使用效率、增强工作负荷和处理能力、自我保护数据和信息的安全。
④开放标准：整个环境建立在开放的标准之上，保证系统的交互性。
3.软件体系结构的演变和面向服务的设计原则
软件开发一直是一件很难的事情，因为我们要处理的问题越来越复杂，人们处理这种复杂性问题最主要的手段就是抽象。回顾历史，我们的抽象层次越来越高，反映在各个方面，从编程语言、平台、开发过程、工具到模式。尤其是模式，大量出现在结构设计很好的软件系统中，无论是微观层次上（对象、组件）稳定出现的结构范式，还是在宏观层面上出现的架构模式。使用哪些抽象手段来为问题域建模？如何定义组成部分之间的协作和结构关系？如何定义从外界所看到的系统结构和行为？是什么设计原则在指导我们的架构决策？有什么最佳实践和模式可供借鉴？所有这些，形成了不同设计风格和体系结构范式（Architecture Paradigm）。
通常，一种体系结构范式包括设计原则、来自实践的结构式样、组成要素和关系，以及在整个开发生命周期中它们是如何被识别、描述和控制的。体系结构从过去单个应用包罗一切的客户/服务器的模式，逐渐演变到三层和多层结构的各种分布式计算模式。今天，人们开始谈论和实践面向服务、分布化的架构范式。
从抽象手段而言，SOA在原有方法的基础上，增加了服务、流程等元素。这些抽象手段之间的关系如图1-6所示。图1-6 SOA中的重要抽象手段
SOA继承了来自对象和组件设计的各种原则，如封装、自我包含等。这些保证服务的灵活性、松散耦合和重用能力的设计原则，对SOA来说同样是非常重要的。
结构上，服务总线是SOA的架构模式之一。关于服务，一些常见和讨论的设计原则如下。
①无状态：避免服务请求者依赖于服务提供者的状态。
②单一实例：避免功能冗余。
③明确定义的接口：服务的接口由WSDL定义，用于指明服务的公共接口与其内部专用实现之间的界线。WS-Policy用于描述服务规约，XML模式（Schema）用于定义所交换的消息格式（即服务的公共数据）。使用者依赖服务规约来调用服务，所以服务的定义必须长时间稳定，一旦公布，不随意更改；服务的定义应尽可能明确，以减少使用者的不适当使用；不要让使用者看到服务内部的私有数据。
④自包含和模块化：服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，能独立进行部署、版本控制、自我管理和恢复。
⑤粗粒度：服务数量不应该太大，彼此依靠消息交互而不是远程过程调用（RPC）。通常情况下，消息量比较大，但是服务之间的交互频度较低。
⑥服务之间的松耦合性：服务使用者看到的是服务的接口，其位置、实现技术、当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
⑦重用能力：服务应该是可以重用的。
⑧互操作性、兼容和策略声明：为了确保服务规则的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，比如一个服务对安全性方面的要求；也可以是与业务有关的语义方面的内容，比如需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。WS- Policy用于定义可配置的互操作语义，这些语义描述了特定服务的期望，并控制其行为。在设计时，我们应该利用策略声明确保服务期望和语义兼容性方面的完整和明确。
软件工程的方法和过程随着软件实践的不断发展，在软件危机发生之后，从瀑布模型、原型方法等讲究过程、文档密集、控制较多的方法，逐渐发展到轻量级、敏捷和迭代的方法。这些方法更加人性化，避免因为过重的过程而抑制其主动性和创造性。
SOA和当前软件工程过程的一个共同交叉点就是业务价值驱动（Business Centric），它强调速度。SOA从软件的灵活性和重用能力入手，而敏捷过程则从软件交付效率出发。
SOA的架构特性，使得敏捷过程非常适合SOA项目的实施。在SOA中，服务的独立性使得每个服务可以被单独地开发、测试和集成。一个企业中的IT系统，如果是基于SOA的计算环境，那么这个环境就是一个服务的生态系统，每开发一个服务，马上就可以独立部署一个服务，成为这个生态系统中的一部分。这样既很好地支持了持续集成并保证质量，又很好地使得这个服务马上产生业务价值，而不是苦等其他服务。服务的特性使得敏捷过程和SOA可以有一个很好的结合，让两者相得益彰。通过我们与不同客户合作的实践，我们能够充分体会到这两者在实现过程中的风险控制与业务需求改变的适应能力方面相互配合的好处，这种灵活性带来的随时开发、随时部署、随时集成和测试对于采用敏捷过程是非常有利的。1.1.3 任务回顾
知识点总结
1.SOA的定义，松耦合系统的好处，业务服务的特点及定义，业务流程由服务组装而来。
2.采用接口进行应用程序之间交互的好处；SOA的主要优点。
3.SOA是由业务驱动的；计算环境的演变历程；面向服务的计算环境；服务的设计原则。
学习足迹
项目1任务一的学习足迹如图1-7所示。图1-7 项目1任务一学习足迹
思考与练习
1.松耦合系统的好处有______和______。
2.SOA的英文全称是什么？
3.计算环境由______、______和______组成，这个环境能够处理和交换数字信息，允许外界访问其内部的信息资源。
4.业务服务常见的设计原则有哪些？1.2 任务二：SOA技术概览与企业IT战略【任务描述】
SOA其实不能算作一门纯粹的新技术，而是分布式软件系统构造方法和环境所发展到的一个新阶段。在上面的任务中，我们了解了SOA的起源和演化进程，接下来我们将继续学习SOA的主要组件和技术标准，在正确理解SOA的基础上，分析SOA与企业IT战略的关系及实施思路。
这就是我们完成的第二个任务：了解SOA技术标准与企业IT战略。1.2.1 SOA的主要组件和技术标准
1.SOA主要组件和WebService相关标准
在前面关于计算环境的讨论里，我们已经提到SOA计算环境的主要组件包括服务运行时的环境、服务总线、服务注册库、服务网关和服务组装引擎。通常，其还包括服务管理、业务活动监控（Business Activity Monitoring，BAM）和业务绩效管理（Business Performance Management，BPM）。另外，我们需要相应的工具来支持服务建模、开发和编排服务等方面的工作。在分析、设计方面，我们需要基于服务的分析、设计方法，就是我们通常说的服务建模，包括服务的识别、定义和实现策略，其输出是一个服务模型（Service Model）。
Web服务作为实现SOA中服务的最主要手段，我们首先需要了解与WebService相关的标准，它们大多以“WS-”作为名字的前缀，所以统称为WS-*。 Web服务最基本的协议包括UDDI、WSDL和SOAP，通过它们，我们可以提供直接而又简单的WebService支持，如图1-8所示。图1-8 基本Web服务协议
但是基本协议无法保证企业计算需要的安全性和可靠性，所以我们需要增加这方面的协议，比如WS-Security、WS-Reliability和WS-Reliable Messaging；对于复杂的业务场景，我们需要WS-BPEL和WS-CDL这样的语言来将多个服务编排成为业务流程，我们还需要管理服务的协议如WS-Manageability、WSDM等。与Web服务相关的标准还在快速发展当中。目前在SOA产品和实践中，除了基本协议外，比较重要的还包括BPEL、WSSecurity、WS-Policy，表1-1给出了一个基本的总结。表1-1 当前Web服务协议栈（续表）
目前，Web的标准和技术还在演变当中，对不同的技术环境的支持力度也不同，但是前面提到的基本核心协议，都可以很好地支持不同的技术环境中的开发。关于Web服务协议的接受和支持程度，如图1-9所示。图1-9 当前Web服务的接受情况
2.SOA应用系统
完整的SOA 应用系统包括SOA 基础技术平台、辅助工具、资源、应用服务、使用SOA系统的人，如图1-10所示。SOA 技术参考架构主要描述了SOA 基础技术平台与辅助工具，同时还描述了这两部分与其他外围相关元素之间的关系。
①资源：SOA系统中被集成的对象，这些对象一般已经存在。在SOA系统中，资源通过适配器接入基础技术平台，以服务形式对外提供服务或使用其他服务。资源具有统一的服务接口，使用统一的接入方式。图1-10 SOA 技术参考架构
②应用资源：特指已有的应用系统，是能够完成特定业务处理的现有系统的总称。应用资源通过开放接口，以适配器为桥梁接入SOA的基础技术平台中。
③数据资源：主要针对无法开放操作接口的应用系统，或只需对外提供数据服务的特定场景而设立的，它可以是格式化数据和非格式化数据，例如数据库和各种文件就是典型的数据资源。数据资源主要供SOA系统中的各种服务进行加工处理，并进行深度的应用。
④新开发服务：均可使用已有的服务。服务描述信息通过资源管理服务进行存储和管理，服务运行信息由运行管理服务进行存储和管理。
使用SOA系统的主要角色如下。
a.设计人员：进行业务分析和建模，使用业务分析和建模工具。
b.开发人员：实现具体SOA系统，包括流程定义、服务编码、资源集成等。
c.管理人员：对SOA系统运行进行监控管理，使用运行管理工具。
d.操作人员：对SOA系统进行业务操作，通过交互服务使用SOA系统中的服务，或进行数据和业务的处理。
⑤其他平台：在一个所有者控制域下（如一个组织内部），我们可以通过基础技术平台实现互操作；在所有者控制域之间（如多个组织之间），有可能使用不同的基础技术平台实现平台之间的互操作。平台之间的互操作一般通过协作服务实现。
⑥适配器：解决已有资源面向SOA的服务封装，实现已有资源的可重用性。通过适配器，已有资源仅需要与SOA 基础技术平台中的连通服务相连接，而不需要与每个服务直接相连就可以实现服务之间的互操作。
⑦连通服务：SOA基础技术平台中的一个重要的核心服务，典型的连通服务就是ESB。连通服务主要解决服务之间高效通信的问题，是服务之间互相通信和交互的骨干。为实现两个实体之间的有效通信，通常需要一个通信代理。同样，服务之间的有效通信也需要通信代理。该通信代理主要实现连通服务，其需要支持的主要功能包括：实现通信代理与服务之间的双向交互，包括紧耦合方式（即通过代码之间调用）和松耦合方式（即通过网络通信）；实现代理之间的通信；保证代理之间的通信质量，包括效率、可靠性、安全性，并提供其他服务（如事务管理）；提供服务运行管理。
⑧协作服务：既可以满足组织之间（如供应链的合作伙伴之间）的交互通信需求，也可以满足组织内部（如跨地域的分支机构之间，并有防火墙进行保护的情况）必须使用WebService方式进行交互通信的需求。
⑨流程服务：为业务流程的运行提供的一组标准服务。业务流程是一组服务的集合，可以按照特定的顺序并使用一组特定的规则进行调用。业务流程可以由不同粗粒度的服务组成，其本身可视为服务。
⑩ 业务服务：在此处指为新建服务提供的特定运行支持环境。
⑪ 交互服务：实现人与服务之间的交互功能的总称。
⑫ 信息服务：特指为上层应用系统、同层的其他服务等提供数据访问及资源访问服务。其目标是使应用系统能够统一、透明、高效地访问和操作位于网络环境中的各种分布、异构的数据资源，为实现全局数据访问、加快应用开发、增强网络应用和方便系统管理提供支持。
⑬ 运行管理服务：运行管理工具的代理，完成SOA基础技术平台中各种运行信息的收集，以及执行运行管理工具的具体管理操作。运行管理工具提供界面友好的图形化方式并对各种资源和服务对象进行管理。用户通过该工具，可以远程连接运行管理服务，简单、方便地操作运行管理服务提供的各种功能。
⑭ 资源管理服务：各种辅助工具对资源进行管理操作的代理，它负责对SOA系统中各种资源的具体管理操作。
⑮ 业务分析和建模工具：一组辅助工具，帮助用户进行业务分析和业务建模。
⑯ 集成开发工具：一组辅助工具，在此工具中可以实现系统建模、服务编码、运行调试和系统部署等管理功能。
⑰ 运行管理工具：应用系统的管理工具，它通过使用资源管理服务可以将基础技术平台中的资源与应用相集成，实现统一管理。
⑱ 安全服务：对于SOA系统是一项非常重要的服务，尤其是像SOA这样强调松耦合的分布式集成系统，安全性显得更为重要。因此，安全有时被称为是一种“事关全局的考虑”，是全方位的问题，跨越了SOA参考模型的各个部分。安全服务向SOA参考模型中其他服务提供基本的安全服务功能，包括：身份验证、访问控制、数据加密、数据完整性、抗抵赖性。1.2.2 SOA与企业IT战略
随着知识经济时代的到来，企业和公共事业机构面临着全球化、扁平化的快速巨变。信息技术在其中的战略性作用和影响越来越显著。作为企业整体战略的重要组成，企业IT战略是基于企业发展目标和业务战略而制订的企业信息技术应用与发展的整体框架和指导体系。其中，企业架构（Enterprise Architecture，EA）是最核心的组成部分。
IT战略的制订没有一成不变的方法和过程，因不同企业、不同阶段而异。虽然只有一部分企业进行了很正式的IT战略制订工作，而且大多数都是在一些关键性的因素（比如IT已经严重地制约着业务的进一步发展，或被竞争所迫）推动下，借助外来咨询服务进行的。但是越来越多的企业已经意识到IT战略对短期和长期的IT建设所具有的重大指导意义，已经开始正式或者非正式地制订自己的IT战略，尤其是企业架构。
IT战略着眼于企业长远目标和经营战略的实现，所以面临诸多难题，包括：如何正视企业面临的各种挑战，对内外环境进行准确、全面地分析，从而确定需要满足的业务目标；如何制订优秀的企业架构来支持业务流程，监控业务活动，管理业务绩效，适应不断变化的业务需求和信息技术，确立具有一定预见性的企业信息化的路径，建立监管体系、标准和执行过程来确保战略得到恰当的理解和执行。克服这些困难，制订成功的IT战略，其中最重要的原则是让IT与业务紧密互动，确保业务目标顺利地映射到技术世界。在企业当中，现实情况又是怎样的呢？
业务上，企业需要端到端的水平整合。每个企业在业务上都要求其人员要有越来越快的反应能力，整个企业内部能够跨部门快速协作，在外部可以更好地同合作伙伴、客户互动。可是，原来积累下来的业务运作模式是部门导向的，IT系统也主要支持以部门为导向的业务过程，我们称之为垂直整合。大多数企业在这个层面上做得不错，但是，需要更有效率，以提升整个企业的生产效能，更快地满足客户需求和响应外界变化。这种将各个部门的业务贯穿起来的业务流程，我们称之为水平整合。而这个整合的过程，给企业带来了以下几方面的巨大的压力。
1.来自业务本身的转型
如何从战略远景出发，制订自己的业务整合目标，这些目标由哪些水平整合的业务流程来支撑，怎样监控、管理和优化这些流程，如何保证业务流程遵循法律法规的要求等，对于一个企业来说，这些都是非常有挑战性的事情。因为其本身具有复杂性，且这种调整可能会改变企业的结构，影响到一些既得利益者，员工们通常也不愿意改变已经习惯和熟练的工作过程。所以，这种转型通常以渐进的方式实现，即企业制订一个长远的转型目标，一步一步地实施目标。
2.来自IT的转型
业务的全面整合，需要IT在整个企业范围内各个层次上的全面整合：数据、应用、流程、人机交互和安全等。但是，IT的现状给这种转型带来极大的压力。
首先，连通性是一个大问题。原来那些面向垂直整合的业务流程的IT系统，不但不互联互通，还非常异构，使用迥然不同的硬件环境、软件平台、开发语言、架构范式、设计原则。整个IT界几十年发展中的每个环节的东西，几乎都可以在一个企业，尤其是大型企业的IT环境中找到，这给水平整合带来了巨大的麻烦：首先，我们如何将这些完全不同的东西连通起来？如何让它们在交互的时候使用一种程序语言以便相互理解；其次，这些已有系统如何重用也是一个大问题，企业不希望扔掉它们再重来，重来的代价太高了，也显得很不高明。可是，大多数的已有系统在构造的时候，并没有与其他系统整合的需求，因此它没有提供编程接口给外界；即使有，也是面向特定的垂直整合范围内的系统，大家采用特定的协议和技术，清楚彼此的细节，紧密耦合。这些系统的数据，在这个垂直整合范围内来说，是完整的、有意义的，可是对于全企业范围内的水平整合而言，很多时候并非如此。在这样的情况下，企业要进行水平整合，就得根据不同系统的情况，开发不同的整合方式，最好是“非侵入”的方式，将这些系统中的数据和功能包装出来，以供水平整合使用。最后，IT和业务之间的互动需要改善。
今天，IT和业务之间存在很大的差距，需要更好地对齐。我们很难看到企业中的IT人员可以用业务术语来描述IT系统中的元素，反之亦然。这个断层导致了业务需求不能很准确地反映在IT系统中，同时，业务发生变化时，这种变化也不能很好地被传递到IT系统中去。我们需要提高IT系统的抽象手段，提供业务人员和IT人员可以共同使用的概念体系，比如业务流程（Business Process）、业务服务（Business Service）、业务数据对象（Business Object）、业务事件（Business Event）等，用来描述和交流业务模型和业务需求。
IT人员在这个基础上理解业务需求，同时将这些高阶元素在IT系统中实现出来。在过去的IT系统中，这些元素由一系列低阶的技术实体（如代码、对象、组件等）以私有技术、不明确的声明、紧耦合的方式，通过代码、脚本、消息与事件组合在一起来构成，我们能够看到的是纷繁的技术世界的低阶实体，高阶的元素湮灭在这些细节中。在新方法中，这些高阶的元素被独立出来，单独建模，被清楚明确地描述，并以独立存在的实体在IT系统中实现。这样，业务和IT之间的互动就有了更好的基础：一方面，业务在走向水平整合的过程中，有了更好的方式来形式化地描述业务模型和需求，改善业务和IT部门之间的沟通质量和效率；另一方面，这些元素被直接地映射到IT系统中，使得业务的变化可以容易、清楚地传递到IT系统中。
所以，我们的IT战略需要面对这些挑战，企业需制订出一个合理的企业架构来完成几个关键的任务：企业范围内的水平整合，IT与业务的对齐，业务的敏捷性，IT的灵活性与重用能力。
企业架构通常描述了一个组织的目标如何通过业务流程来实现，以及这些流程如何通过信息和技术来支持。制订企业架构是一件很有挑战性的事情，它复杂、耗时耗力，需要应付不断的变化。在实践中，企业架构通常会包括业务架构、应用架构、数据架构、安全架构、基础设施架构和集成架构。
SOA具有来自最佳实践的设计原则、架构模式、集成能力、基于标准的开放性和交互能力，能够很好地帮助企业架构面对前面提到的挑战。首先，SOA以业务为中心，提供了服务、流程等高阶建模元素，通过SOA的分析和设计方法，改善了IT和业务的交流与对齐；其次，SOA基于标准的交互能力和ESB架构模式，可以简化分布式系统之间的整合，将各种异构的系统连接在一起。通过ESB、适配器和连接器，用户一般可以用“非侵入”的方式来重用已有系统。SOA所激活的以服务为中心的企业整合（Service Oriented Integration，SOI），将企业整合带入了一个新时代。总之，SOA真正可以帮助企业获得业务敏捷性、IT架构的灵活性和IT资产的重用能力，进而影响企业架构的方方面面，发展为SOA风格的企业架构（Service-Oriented Enterprise Architecture）。
大家已经了解了SOA是企业IT发展的方向，那么企业该如何运用呢？
首先，SOA是一个长途旅程，不要试图一蹴而就。我们应该选择快步小跑，在实施中积累经验，培养队伍，快速体验和展示SOA的价值，不断地评估SOA实施的效果，调整实施范围和策略，通过这种迭代的过程不断地螺旋上升。如果有资金实力，企业还可借助咨询服务，建立一个向SOA转型的IT战略规划和SOA风格的企业架构，这对整个旅程的成功是非常有帮助的。不过这里有一个善意的提醒，业务本身可能异常复杂，制订这样的规划和企业架构需要一定的时间和相当大的投资；同时，业务也充满了变化，制订出来的规划和架构要随时保持更新。
其次，确保实在的业务价值和动机。一些客户了解SOA是未来的方向，决定启动SOA项目，但是没有思考清楚应从哪里入手，为做SOA而做SOA，最后会面临SOA价值评估的困境。做SOA项目应该有清楚的业务需求，比如人员的协作、数据整合、应用和流程整合、系统间的连通性和已有系统的重用等。
再次，实践出真知，万事开头难。大多数客户虽然了解SOA的概念，但是没有做过，也不清楚如何做。一个行之有效的方法是先不要试图考虑所有的业务流程和场景，相反，要将它们划分为小的集合，挑选两个端到端的业务流程。它们贯穿了数据、业务逻辑和服务消费的所有层次，牵涉数据、应用和流程的整合以及人机交互。这样的项目，会帮助我们理清SOA的概念、技术和产品，让我们实实在在体验SOA的好处。
最后，建立和完善SOA治理体系（Governance）。公司治理（Corporate Governance）是一个体系。其中，IT治理（IT Governance）是面向IT的，确保IT服务于业务目标，好的投资回报（ROI）和好的IT服务给业务部门，包括不同的方面，如需求、项目开发、IT资产、投入和产生价值及其评估、IT运作等。SOA治理建立在IT治理的基础上，包括一系列角色、过程和方法，用于管理服务和流程的整个生命周期，即建模、开发与组装、部署、管理和优化，确保SOA持续提供业务价值。1.2.3 任务回顾
知识点总结
1.SOA计算环境的主要组件，基本Web服务协议，SOA 应用系统的组成。
2.使用SOA系统的主要角色，适配器，连通服务，SOA的安全性。
3.SOA与企业IT战略的关系，企业IT系统的垂直整合与水平整合，SOA风格的企业架构的优势。
学习足迹
项目1任务二的学习足迹如图1-11所示。图1-11 项目1任务二学习足迹
思考与练习
1.Web服务最基本的协议包括______、______和______，通过它们，我们可以提供直接而又简单的WebService支持。
2.完整的SOA 应用系统包括：______、______、资源、应用服务、______。
3.使用SOA系统的主要角色包括______、______、管理人员和操作人员。
4.SOA风格的企业架构能够为企业带来什么好处？
试读结束[说明：试读内容隐藏了图片]