作者：[美]ThomasErlBenjaminCarlyleCesarePautassoRajBalasubramanian著
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
SOA与REST：用REST构建企业级SOA解决方案试读：
其他
版权声明
Authorized translation from the English language edition,entitled:SOA with REST:Principles,Patterns&Constraints for Building Enterprise Solutions with REST,9780137012510 by Thomas Erl,Benjamin Carlyle,Cesare Pautasso,and Raj Balasubramanian,published by Pearson Education,Inc.,publishing as Prentice Hall,Copyright © 2013 Pearson Education,Inc.
All rights reserved.No part of this book may be reproduced or transmitted in any form or by any means,electronic or mechanical,including photocopying,recording or by any information storage retrieval system,without permission from Pearson Education,Inc.
CHINESE SIMPLIFIED language edition published by PEARSON EDUCATION ASIA LTD.and POSTS & TELECOM PRESS Copyright © 2013.
本书中文简体字版由Pearson Education Asia Ltd.授权人民邮电出版社独家出版。未经出版者书面许可，不得以任何方式复制或抄袭本书内容。
本书封面贴有Pearson Education（培生教育出版集团）激光防伪标签，无标签者不得销售。
版权所有，侵权必究。
谨以此书献给 ChristophSchittko，他毫无顾忌的审阅评注使我们在本书书稿已经提交印刷之后仍然决定改变内容结构，而后续的变化极大地提升了书稿的质量。——Thomas Erl
献给亲爱的妻子Michelle，献给我的父母Rob和Sue，献给我的孩子Genevieve和Matthew。感谢你们多年来的支持与鼓励！——Benjamin Carlyle
献给我的家人及我的Esperanza。——Cesare Pautasso
向父母的牺牲与支持致敬！——Raj Balasubramanian
对本书的赞誉
“本书通过具体且实用的方式，阐释了SOA和REST领域之间的联系，简明地将其运用到日常遇到的架构挑战上。太棒了！”——Ryan Frazier，技术战略师，微软公司“SOA可以通过许多不同的方法实现，而REST则是潜在的实现框架中最闪亮的新方法。本书向架构师和开发人员介绍了实现RESTful SOA所需的知识，而最重要的是，它告诉人们一种通过REST实现SOA的风格：其核心是设计服务生态系统，在其中向客户提供简单的使用资源的方式，并通过服务将资源连接起来。本书无疑将有助于使SOA从Web架构的主要价值主张（分散、松耦合、连通性、自描述服务、独立于实现的服务接口）中获益。”——Erik Wilde博士，架构师，EMC公司“这是一部杰作，它将REST原则优雅地运用到该丛书中的工业标准SOA框架上。书中为实践者提供了有用的指导，并且在形式和精神上都与Roy Fielding论文中定义的REST约束保持一致。有关RESTful契约设计的章节使本书物有所值。本书对于任何开发REST服务的人来说都是必读的。”——Dave Slotnick，企业架构师，Rackspace Hosting“面向服务模式的精彩大作，它将有效地解决现实世界里的问题。REST观点和原则将完全地覆盖现代Web 2.0风格的方法。强烈推荐。”——Sid Sanyal，IT架构师，苏黎世金融服务公司“REST不仅仅是接口的另一种实现方法。本书为我们展示了服务组合生态系统如何随着服务组合架构设计的新机遇而变化。对于任何正在考虑REST风格服务构建应用程序架构的认真的IT架构师来说，这都是一本全面指南和必读之作。”——Roger Stoffers，解决方案架构师，惠普公司“面向服务和REST这两种架构风格都是现代应用程序和云计算的基石。它们都致力于交付可伸缩的、可互操作的解决方案，但是它们的不同根基使得它们并不能天然地互相配合。本书阐述了如何在企业环境中使二者协调工作。书中讨论了一组设计流程，它们使服务集合在满足SOA目标的同时又符合现有的REST约束。此外，为使REST风格满足企业级需求，它还务实地在必要之处放松了约束。”——Christoph Schittko，云战略总监，微软公司“这是一本鼓舞人心的书，它为下一代基于REST的面向服务的系统的设计与开发带来了深刻见解。本书务实地阐述了SOA与REST的融合，解决了工作中常见的实际问题。对于软件设计师、架构师和顾问来说，是必要的‘现代服务实现的工具’和‘强大的知识体系’。”——Pethuru Raj博士，企业架构师顾问，Wipro顾问服务公司“Thomas Erl的服务技术丛书一贯地使用简单的例子说明复杂的概念。在该丛书中的最新著作《SOA与REST》中，作者通过常见的SOA语言来讨论REST。《SOA与REST》对企业架构师和开发人员来说都是极好的资源！”——Kevin P.Davis，博士，软件架构师“不同于其他相似内容的书籍，《SOA与REST》一书中的叙述做到了完善、易读，包含了现实世界的案例研究，可同时满足开发人员和分析师的需要。对于SOA实践者及任何计划启动SOA项目的执行者来说，这都是不可或缺的资料。”——Theodore T.Morrison，认证的SOA分析师，CSM，Geocent，LLC“任何将REST应用程序构建为面向服务架构的IT架构师或软件工程师，要想深入理解其中原则、模式和实现概念的话，就都需要读一读这本书。它不仅包含了基本的话题，还探讨了REST与各种特定的SOA原则及模式之间的关系。”——Sanjay Singh，认证的SOA分析师，开发经理，NorthgateArinso“一本面向企业架构师、分析师、开发人员的权威的上乘参考书。本书不仅展示了REST的优雅、简单性和通用性，还使我们清楚地理解了REST是如何增强SOA和面向服务的，REST如何能够影响SOA设计目标，我们如何来设计和开发REST服务，我们如何解决REST集成到面向服务时所面临的独特挑战。任何以REST来构建面向服务架构的人，想要掌握这门技术，都有必要阅读本书。”——Philip Wik，MSS Technology“这是一本理解如何在面向服务架构中采用REST的基础而全面的书。对于任何对面向服务感兴趣的实践者来说，书中提供的许多示例和模式将是非常宝贵的资源。”——Gustavo Alonso，计算机科学系，苏黎世联邦理工学院“SOA和REST是分布式计算中两种非常重要的架构风格。SOA成功地在大多数企业中得到采用，而研究者和工业用户越来越多地关注REST风格。《SOA与REST》一书介绍了一种新的架构风格，巧妙地结合了SOA和REST风格，清晰地揭示了两者的协同工作，通过REST来产生成功的企业 SOA 策略，以及对架构设计决策提出指导。本书是使用 REST 来设计和实现SOA架构的最佳实践的圣经。这是一本IT实践者和研究人员的必读书籍。”——Longji Tang，联邦快递IT高级技术顾问，CSSE博士“REST和SOA是过去十年间在软件工业中被误解最多的两个术语。然而REST架构风格加上现代RESTful框架实现，提供了可伸缩和可靠的SOA方式。本书涵盖了关于如何将REST原则应用到小型和大型SOA开发中的全面阐述。如果你已经熟悉REST并在考虑SOA，那么你需要本书。如果你还没有在你的 SOA 工作中考虑 REST，那么本书同样适合你。它囊括了REST和SOA的概念，还包含了设计模式与使用的时机，本书是架构师和工程师的精彩指南和优秀工具。”——Mark Little博士，JBoss首席技术官，红帽公司“本书精彩地介绍了如何将SOA方法论与RESTful架构风格的服务结合起来。对于SOA架构师如何更好地理解将REST集成到面向服务架构流程的含义和要求，Thomas Erl及其合著者们提供了很大的帮助。”——Gerald Beuchelt，MITRE译者序
如今，在企业级解决方案领域，SOA这一词汇已不再陌生。几十年来，为了打通不同时期使用不同技术建设的信息孤岛之间的连接，人们一直在改进软件工程方法，也尝试过很多不同的技术手段，比如点对点（P2P）的集成、基于消息的集成（Messaging）、企业应用集成（EAI）等，它们在各自的历史舞台上发挥了重要的作用。然而，直到面向服务思想和面向服务架构的诞生，这一问题才真正得到有效解决。
与SOA不同，REST是在互联网环境中成长起来的，根据Fielding博士的论文，REST是为了解决互联网规模的软件架构所面临的问题而诞生的。尤其，当REST与HTTP标准结合起来，通过RESTful Web服务本身的优势，如无状态性和幂等性，为提高系统的可伸缩性起到重要作用。REST 以其简洁性、更低的资源占用，统一接口抽象、代理服务器支持、缓存服务器支持等诸多方面的优势深受众多架构师和开发者的喜爱。
作为两种优秀的架构风格，它们都不缺乏推崇者。自然地，二者之间的论战逐渐成了技术圈的热点话题。网络上关于 SOA与 REST的论战非常之多，但是，它们大多聚焦于二者之间的差异，有的SOA的拥护者称REST不适合企业级应用，而REST的拥护者则把对SOAP协议的抱怨转嫁到SOA的身上。
Thomas Erl站了出来。他说，两种架构风格的目标有诸多相同之处，即便在企业级解决方案中，SOA 和 REST 也能够相得益彰，通过“战术性”的 REST 媒介实现“战略性”的 SOA的战略目标。Thomas Erl是SOA领域的大师级人物，他在SOA方面的诸多著作，尤其是其“SOA系列著作”，为架构师和开发者们提供了丰富的理论知识和实践指引。
本书全面介绍了面向服务概念、REST 约束及目标，并且针对企业应用所面临的问题提出了用REST来实现SOA的设计目标和架构原则。作者提出了在分析和建模过程中的注意事项，并启发出一些新的SOA设计模式。
作为本书的译者，我们为能够翻译这样一本优秀的著作而感到荣幸。尽管我们各自都有许多工作和事情要处理，但是我们尽量利用下班后和周末的时间，兢兢业业地翻译这本书，不敢有一丝疏忽和怠慢，生怕由于自己的失误而未能准确地表达作者们的原意。
我们从2012年9月开始翻译此书，翻译分工如下。
马国耀负责翻译第4、6、7、14、15、16章及附录E，这些章节的内容包括：SOA术语和概念，REST服务契约，REST与面向服务的关系，受REST启发的设计模式，REST服务版本控制，统一契约介绍，SOA设计模式概要等。
申健负责翻译第2、5、11、12、13章及部分附录，这些章节的内容包括：案例研究背景，REST约束与目标，REST服务组合，REST高级服务组合及案例研究等。
刘蕊负责翻译第1、3、8、9、10章及部分附录，这些章节的内容包括：内容导读，服务基础知识，主流SOA方法论及REST技术，REST服务的分析与建模，REST面向服务的设计等。
在翻译过程中，我们采用迭代方法，每人各翻译完一个章节之后就进行一次审校迭代。我们采取A审校B，B审校C，C审校A（或相反顺序）的方式进行审校，所有意见不一致的地方由定期会议仲裁解决。全书最后由马国耀进行统一修订和审校。
由于译者的能力水平有限，难免存在疏忽与差错，在此恳请读者见谅，并给予批评指正。
翻译是个痛苦而辛苦的过程，翻译《云计算与SOA》的经历让我感触很深。另外，由于自己工作上进入一个新的平台以及刚出生的女儿的缘故，根本没有太多空余时间来翻译。所以，我本不打算翻译这本书的。但是，在人民邮电出版社杨海玲女士的邀请和李锟先生的鼓励之下，我快速阅读完了本书，在此之后我就再无丝毫犹豫。因为，不将本书呈现给国内的读者和广大 SOA从业者，我觉得是一个遗憾。于是，就有了连续一年翻译历程。在这个过程中，我结识了申健、刘蕊两位认真而专业的译者，这一年来的沟通与交流是难忘而深刻的，感谢你们。最后，感谢家人对我一贯的支持，特别感谢我的妻子和女儿，因为翻译这本书所用的时间正是原本应该用来陪伴你们的时间。——马国耀
回首过去忙碌的一年，看到自己在企业内完成了手机银行解决方案的重要演进，辅导了更多的敏捷团队，在企业外结识了更多的朋友，锻炼了更多的技能，并在而立之年迈出了职业生涯中新的一步。同时，看到天津软件社区变得热闹起来，南京大学天津校友会愈发壮大，女儿的轮滑也练得有模有样了。最重要的，就是有幸与马国耀、刘蕊两位战友共同完成了这本书的翻译。三个人素未谋面，仅凭着互相信任和彼此认同工作在一起，每个人都投入了大量业余时间，字斟句酌，反复推敲。还记得每天下班后虽然已经很累，却仍在夜深人静时翻译几页；还记得每次迭代互相审校之后，即使事先邮件沟通过多次，大家还是会在Skype上讨论到深夜；还记得百会工作表中数百条待定意见逐一关掉后获得的满足感。当然，我们应该可以做得更好，比如在每次迭代后都尽快拿到出版社的反馈意见，尽早做出翻译风格的调整。无论如何，这是一段存在我深深的脑海里的难忘经历，因为能与志同道合的朋友共事的机会是奢侈的。我也从两位合作者的精神和专业知识中学到了很多，感谢有你们。另外，也要感谢家人的支持和照顾，使我能够安心地投入工作。——申健
2012年对我而言是特殊的一年，在大洋彼岸开始了一段新的生活。因为怀孕，准备生老二，赋闲在家，怕自己跟技术脱节，作为一个SOA实践者，我对REST结合SOA这一论题很感兴趣，于是加入了这段长达一年的翻译历程。我同另外两位译者并不熟悉，与申健之前不认识，国耀虽然是以前的老同事，但也仅限于邮件打过交道。一开始我对这种远程合作的模式的想象是非常松散的。但是实际上，国耀很快把翻译的工作组织的井井有条，利用百会表格交互分工安排，词汇勘误；相互进行审校；使用Skype进行定期交流，讨论所有翻译中有争议的部分；利用REST技术QQ群与潜在读者进行相关技术讨论。这种工作模式让我在忙碌的家庭琐事之余感觉到自己是个有追求的IT Professional！终于，书籍翻译完成时，我家的Max呱呱坠地，定稿前，我刚好开始了在澳洲的第一份工作，有幸参与一个大型的SOA项目，而我也有机会将阅读本书过程中得到的新知识加以运用，尤其是服务的筛选，事务的处理等相关知识。感谢本书，充实了我在澳洲的第一年，让我认识了两位朋友，拓展了REST相关的SOA知识，这段翻译历程，将会成为我的一段珍贵的回忆。——刘蕊序
2002年初我第一次听到REST时，我就坚信新兴的Web服务规范和标准即将带来的价值。起初，我只是对这一方法充满好奇，尤其“统一接口”的理念，但是很快我便得出结论，虽然REST很有吸引力，但是它却几乎无法适用于企业环境。
一两年之后，我便开始欣赏REST风格的优雅和简洁性了。而且，我还认为在某些场景下REST是更好的选择，虽然一些高级的场景仍然需要使用SOAP、WSDL和WS-*。又过了一年之后，我开始发现自己在大多数情况下都更倾向于REST风格的HTTP，而非SOAP风格的Web Service，并且我已经说服了自己，并决定自称为“REST盲从者”。我开始坚信，现在仍然坚信，遵守REST架构风格的约束不仅能使公共Web上的系统变得更好，而且还适用于各种企业环境。
今天，REST 已经成为主流—连同它对别的技术所产生的正面及负面的影响。我们现在向人们介绍REST方法时是相当轻松的，即便在大企业里也不例外，人们不再对此不屑一顾了。此外，让我惊讶的是，很多时候人们甚至将其视为默认选择。
所以，REST社区应该感到高兴和满足，并对我们在公共Web上及企业内构建出各种优秀的系统开发及集成充满期待。但是，这里仍然存留着两个问题：一是，并非所有声称 RESTful的架构都是名符其实的；二是，SOA常常被看成由WS-*风格的Web Service组成的架构，因此与REST不相容。“REST”名称的误用
遵循REST原则，应用Web技术（如HTTP和URI），使用超媒体格式（如HTML），就能使系统变得可演进、动态且稳定，并且可以通过新的未预见的方式连接系统。可是，真正称作“RESTful”的构建系统或集成系统的方式需要一种全新的设计方法，它不同于大多数开发人员过去所使用的方法。若选择 REST 方法而非分布式对象、RPC 或 WS-*时，需要通过资源、媒体类型、超媒体及统一接口来表述整个接口域。你将发现，对这些概念理解得越深入，就越能轻松地坚持REST的内在约束，越容易挖掘REST的价值。
因为WSDL/SOAP/WS-*架构的一个根本设计决定是“传输独立性”，所以通过它们构建的系统很难成为RESTful的，几乎无人反对这一说法。但是，即便没有出现XML或SOAP，Web的底层理念也很容易遭到违反。互联网上充斥这样的例子：通过HTTP GET或POST实现的管道（Tunnel）方法调用，忽视缓存和超媒体，将构成 URI 的字符串当作开发用的 API。使用JSON、HTTP和“简洁”的URI不一定意味着系统就是RESTful的。不要想当然地把任何宣称为“RESTful API”的东西都当作典范。
评判SOA“SOA”这个标签已经被完全炒作殆尽了。在我看来，这主要由于很多人将它与Web Service技术（最初它是支持SOA的流行方法）紧密关联的缘故，而且此现象仍然在继续。网络上许多有关SOA与REST的比较大多将它们强行地变成类似于苹果与橘子之间的比较。所以，我们有必要回过头来看看SOA最初的动机。
在任何公司里，整体IT环境都是由许多单独的系统构成的。这些系统运行在不同技术之上，最初通过不同的工具建设而成。有些来自与商业厂商，有些是企业内建的。一段时间后，你会想把它们连接起来，因为这么做的价值是显而易见的。你可以采用点对点的集成方式，通过文件、共享数据库或其他集成解决方案，从某个系统中导出一些数据，定期地导入到另一个系统中。这么做的结果是，你将得到一个脆弱的、不易于管理的IT环境。
因为系统集成的工作非常困难，所以你（或为你服务的厂商）会使其变得越来越臃肿，直到你不得不付出巨大的代价来改变。尽管引入集中式的集成中间件起初看起来非常诱人，但它却不是个好办法。你将依赖于一家厂商，它有可能被另一家收购，或者破产，或在你与竞争对手（它采用的是另一家产品，而且更时新）合并之后变成遗留系统。
那么，你该怎么做呢？你应该合理地解决这一问题，通过在接口层限制不同技术的数量来减少集成系统所需的工作。为实现这一目标，你可以选择一种较好的接口抽象方法，将大型应用系统分解成更细粒度的功能模块。这样，你就无需依赖于单个厂商，不论它是中间件厂商还是应用系统厂商，你期望功能便于使用（及重用）。应该不会有人否认这是一个合理的方法。
对我而言，这就是SOA的本质：它是一个运用于企业内一组应用而非单个应用的系统软件架构；它重点关注网络和系统间的接口，而非实现；它进行一切必要的标准化，确保流畅的交互和偶尔的重用；别无其他。几年前，我们发表SOA宣言时，重点关注的是内在互操作性，我认为，这才是真正象征着SOA和面向服务的特性，也正是它促使了SOA与REST原则的对齐。
在我看来，面向服务是非常值得追求的一个目标，而RESTful HTTP是当前看到的实现这一目标的最佳方法。任何其他架构都不具备如此广泛的支持，便利地支持重用，以及相同的对持续演变的支持。然而，在SOA环境中使用REST仍然处于初级阶段，到目前为止，尚很难找到成熟的最佳实践与模式。
本书的贡献
本书的作者们对于什么是 REST，什么不是 REST 具有非常清晰的理解，所以，本书给你带来的知识，可以帮助你区分哪些是真正的RESTful，哪些又只是自我标榜。你将学习SOA与REST的基础知识，还会了解若干结合了SOA与REST的设计模式。你还会学到如何构建服务及服务消费者。
构建RESTful系统和集成场景的工作非常需要指引，而且该指引不应该只满足于短期的成效，而应更加注重于长期的收益。我坚信本书的作者们是你能够找到的最佳指引。我非常肯定，你也将会相信REST与SOA非但不冲突，反而是完美的搭档。——Stefan Tilkov,innoQ
致谢
Gustavo Alonso，苏黎世联邦理工学院（ETH Zurich）计算机科学系
Gerald Beuchelt，MITRE
Kevin Davis
Jean-Paul De Baets，比利时政府
Roy Fielding
Ryan Frazier，微软公司
Michael Grube，诺德斯特姆公司（Nordstrom）
Dolly Kandpal，Qamlo信息服务
Jana Koehler
Ivana Lee，Arcitura教育
Mark Little，红帽公司
Damian Maschek，德国铁路公司
Theodore Morrison，Geocent公司
Pethuru Raj博士，Wipro咨询服务公司
Ian Robinson
Sid Sanyal，苏黎世金融服务集团
Al Scherer，佛莱特高等教育集团
Christoph Schittko，微软公司
Sanjay Singh，NorthgateArinso
Dave Slotnick，Rackspace
Roger Stoffers，惠普公司
Longji Tang博士，联邦快递公司
Clemens Utschig-Utschig，勃林格殷格翰公司（Boehringer Ingelheim Pharma）
Philip Wik，MSS
Erik Wilde，EMC第1章介绍
1.1 关于本书
1.2 推荐阅读
1.3 本书的组织方式
1.4 约定
1.5 附加信息
万维网基于IT历史上最成功的技术架构，它改变了我们看待、获取及交换信息的方式。伴随着REST约束的形成，它还会为我们带来更引人瞩目的构建和改进自动化解决方案的新方式。
然而，如何充分利用 REST 与生俱来的灵活性和简单性却取决于读者。REST 在架构方面提供了大量的指导原则，其自动化逻辑技术也非常健全，但是在支持特定的业务需求和目标时，REST并不能提供相应的指导来确保所建立的方案可以真正地持续产生价值。
针对要实现的一个特定目标状态，面向服务已经建立了行之有效的方法。这一目标状态为很多组织机构实现了有效的业务战略价值。为了实现这一目标状态，我们需要将面向服务的方法应用于合适的分布式计算媒介。本书不仅展示了REST是一种适合于构建面向服务解决方案的媒介，同时也展示了面向服务的架构模型是（能够充分发挥商业潜力的）REST 风格的技术架构的坚实（通常也是必要的）基础。1.1 关于本书
本书旨在讲述REST如何与面向服务的架构、面向服务的设计原则及相关的设计模式相关联并配合使用。1.1.1 本书的目标读者
设计服务和分布式方案架构的架构师。
对使用REST技术构建面向服务解决方案感兴趣的开发人员。
需要理解使用REST作为SOA服务实现媒介所带来的益处的企业架构师。
需要对最终确定使用REST方式实现的服务进行建模的分析师。
希望理解REST如何支持SOA和面向服务的REST专家。
希望理解融合REST架构和SOA架构利弊的SOA专家。1.1.2 本书不会覆盖的内容
本书既不是REST教程，也不是学习SOA或面向服务的全面指南。尽管前面的章节讲述了一些基础知识，但本书大量的内容致力于探讨如何在REST服务设计时运用面向服务的思想，以及REST架构对面向服务解决方案设计和面向服务技术架构所产生的影响。
本书的重点在与建模、设计及架构设计相关的原则、模式及约束上。本书并不会深入探索基于REST服务架构动手实施的任何具体细节，也不会讲述像代理（proxy）及网关（gateway）这样的中间件及中间件组件。
如果你刚刚接触REST和（或）SOA，那么在阅读本书之前，建议你首先学习后面的“推荐阅读”一节中所列出的资料。1.2 推荐阅读
为了进一步确保清晰理解后续章节中使用和引用的关键术语，你可以访问www.soaglossary.com网站，它提供了针对本系列书的在线主词汇表。
详细阐述本标题涵盖的关键主题的系列书籍包括下面两本。
SOA Principles of Service Design——全面记录了面向服务设计范例，针对本书提到的所有原则，该书均提供了全面地描述。这些原则在 www.soaprinciples.com 网站和附录 D中也有相应解释。
SOA Design Pattern——该书是官方的SOA设计模式目录，包含了本书所提到的大部分模式的描述及例子。你可以在www.soapatterns.org网站及附录E中查询这些模式的简要说明。
从支持面向服务角度，进一步关于 REST 服务的技术和设计的例子可参考以下书籍：SOA with.NET&Windows Azure、SOA with Java、Service-Oriented Infrastructure:On Premise and in the Cloud。
如果你对REST服务设计和Web服务设计之间的对比感兴趣，Web Service Contract Design&Versioning for SOA丛书提供了大量相应的说明，内容涉及WSDL、SOAP、XML Schema、WS-Policy和WS-Addressing。
对于那些刚接触REST的读者，推荐阅读以下书籍。
Building Hypermedia APIs with HTML5 and Node（作者Mike Amundsen，出版社O’Reilly Media，2011）
RESTful Web Services:Web Services for the Real World（作者Leonard Richardson和Sam Ruby，出版社O’Reilly Media，2007）
HTTP:The Definitive Guide（作者David Gourley，出版社O’Reilly Media，2002）
REST in Practice:Hypermedia and Systems Architecture（作者 SavasParastatidis,IanRobinson,Jim Webber,出版社O’Reilly Media,2010）
Restlet in Action:Developing RESTful Web APIs in Java（作者 Jerome Louvel,ThierryTemplier,Thierry Boileau,出版社O’Reilly Media,2009）
RESTful.NET（作者Jon Flanders，出版社O’Reilly Media，2008）
附录H中也推荐了一些关于REST的阅读资源，包括本文作者编写的书籍、论文和文章。1.3 本书的组织方式
本书从第1章和第2章开始，分别包含了介绍性内容和案例研究的背景。这里对后续章节进行简要概览。1.3.1 第一部分：基础知识
第3章：服务简介
在REST和SOA语境下，服务相关的术语和概念将有所不同。该章对服务进行了简单介绍，并为避免后续章节出现混乱而做了必要的解释。
第4章：SOA术语和概念
该章是与SOA、面向服务及服务组合等主题相关的关键术语和概念的概览。
第5章：REST约束和目标
该章对REST约束和架构设计目标进行了简要介绍。对于已经熟悉REST的读者，请务必至少通读接口约束相关的描述，以便理解本书如何使用术语“统一契约”来代替该约束。1.3.2 第二部分：REST风格的面向服务
第6章：REST服务契约
基于第3、4、5章的介绍，该章描述了REST服务契约的基础知识，并将它们的特征及用法与非REST类型的服务契约进行了比较。该章还介绍了表示REST服务契约和服务能力的特定图标符号。
第7章：用REST实现面向服务
该章内容将面向服务的设计原则映射到REST约束和架构属性之上，进而探索REST如何影响面向服务计算的目标。1.3.3 第三部分：REST环境下面向服务的分析与设计
第8章：主流SOA方法论和REST
对SOA项目交付的各个阶段进行了简单介绍，同时包含了REST相关的关键阶段的内容。
第9章：REST服务分析与服务建模
对完整的面向服务的分析流程进行了探讨，包含案例研究示例，并扩展至对基于REST的候选服务、候选服务能力和候选服务组合进行建模。
第10章：面向服务的设计和REST
该章包含了与设计相关的各种主题的变种，从而为创建定制的基于REST的服务契约提供指引。1.3.4 第四部分：REST服务组合
第11章：REST基础服务组合
该章通过一系列主题来阐述，构建由REST服务构成的服务组合引入的独特的设计考虑，从而解决诸如服务建模、服务分层、幂等等领域的问题。该章通过一步一步的示例场景来总结上述内容。
第12章：REST高级服务组合
该章内容庞杂，覆盖了基于REST的服务组合的若干更具挑战的议题，包括跨服务的事务、事件驱动的消息机制、动态绑定以及跨服务目录的交互。贯穿于该章的主题是无状态约束下的合规问题。
第13章：REST服务组合之案例研究
第9章和第10章的案例研究中建模和设计出的服务在该章中汇总成为基于REST的服务组合架构。在这一章的案例研究深入遍历了两个运行时场景，并将自动化活动映射到了原始的业务流程步骤上。1.3.5 第五部分：补充
第14章：SOA与REST的设计模式
该重要章节对7个受REST启发的新SOA设计模式进行了平实的描述，这些设计模式已经加入了SOA设计模式目录。每个模式都在附录E中通过概要表的方式进行了正式描述。
第15章：REST服务版本控制
该章使用了“Web ServiceContract Design & Versioning for SOA”系列书中的一些基础的版本控制的内容，并使用关于REST服务版本控制的主题和例子对之做了补充。
第16章：统一契约概要
该章介绍了统一契约概要模板，并对扩充记录了REST服务特性的服务概要表的变体做了描述。
该章通过案例研究进行总结，在案例中记录了一个统一契约概要的样例。1.3.6 第六部分：附录
附录A：案例研究结论
该附录总结了案例研究故事。
附录B：支持Web的工业标准
该附录对REST相关的行业标准组织及已发布的规范进行了概览介绍。
附录C：REST约束参考
该附录提供了本书所引用的REST设计约束的概要表格。
附录D：面向服务原则参考
该附录提供了本书引用的面向服务设计原则的概要表格（源自SOA原则与服务设计）。
附录E：SOA设计模式参考
该附录提供了本书引用的SOA设计模式的概要表格，包括7个受REST启发的新设计模式。
附录F：状态的概念和类型
该附录包含了第11章引入的与服务设计的SOA原则相关的基本术语和概念，主要用于支持本书第四部分的内容。
附录G：带注解的SOA宣言
该附录提供了SOA宣言声明的注释版本，该声明版本也发布在www.soa-manifesto.com网站上。
附录H：其他资源
在最后这个附录中提供了相关网站及补充资源列表，还包括一些额外出版物。1.4 约定1.4.1 灰色的使用
本书中，文字和代码片段偶尔使用灰色标识。灰色的文字谨慎用于普通章节内容中，帮助突出关键语句。在代码样例中，当它与之前的样例章节中的描述相关时，代码片段一般使用灰色标识。1.4.2 设计约束、原则和模式：页码参考
本书中讨论的每一个设计约束、原则和模式都有对应的概要表。概要就是总结了关键设计环节和注意事项的简明定义。本书主要重复的主题就是探讨约束、原则和模式如何相互关联和影响。因此，鼓励读者任何时候在上下文中遇到一个不清楚的约束、原则或模式时，反复地参考相关概要表。
为了帮助快速参考概要表，本书采用了一个特殊的约定。每个原则、模式和约束的名字后面跟着指向概要页面的页码数字。这项约定由设计模式社区设定并在本书中进一步用于本书中的设计原则和设计约束。
附录中包含所有概要表的内容。约束的概要表在附录C中，原则和模式的概要表分别在附录D和附录E中。
为了保持本书中的约束、原则和模式之间能够迅速区分，它们名字后面的页码分别使用了不同的分隔符。每个约束对应的页码采用花括号，每个原则对应的页码使用圆括号，每个模式对应的页码使用方括号，如下：
约束名｛页码｝
原则名（页码）
模式名［页码］
例如，下列陈述首先引用的是一个面向服务的设计原则，然后是一个SOA设计模式，最后是一个REST约束：“……通过运用解耦的契约［302］模式和无状态｛279｝约束来支持服务松耦合（413）原则……”
在这段陈述中，每个引用都明确限定为原则、模式或是约束。为简洁起见，本书中的大部分引用（尤其是后面的章节中）忽略这些限定。
例如，对前面陈述的更为常见的措辞如下：“……通过运用解耦的契约［302］和无状态｛279｝来支持服务松耦合（413）……”
这种措辞约定仍旧来源于设计模式社区。如前所述，如果读者碰到一个没有特定限定词的引用，则使用其页码分隔符（圆括号、方括号、花括号）来识别它的类型（原则、模式或是约束）。1.4.3 设计目标
REST 架构设计目标和面向服务计算的战略目标同设计约束、原则和模式不同，设计目标没有概要。第5章介绍了REST架构设计目标，第4章介绍了面向服务计算的设计目标。1.4.4 符号图例
本书包含一系列的图表，称之为图。所有图中使用的主要符号在本书插页的符号图例中有分别的描述。1.5 附加信息
以下章节针对Thomas Erl的Prentice Hall服务技术丛书（Prentice Hall Service Technology Series）提供了补充信息和资源。1.5.1 更新、勘误和资源
关于其他系列标题和各种配套资源的信息可以在 www.servicetechbooks.com 网站上找到。鼓励读者经常访问该网站查看内容变化和勘误。1.5.2 主词汇表
为了避免内容重复和确保内容稳定，本系列丛书不包含词汇表，而是使用了专门的www.soaglossary.com网站来为整个系列书提供主词汇表。该网站随着新系列书籍的发布持续增加和扩展新的词汇定义。1.5.3 面向服务
网站www.serviceorientation.com提供了论文、书籍摘录及各种内容，用于专门描述和定义面向服务的范例、相关原则及面向服务技术架构模型。1.5.4 什么是REST
网站www.whatisrest.com包含了对本书的摘录及相关内容，用于对REST架构和约束提供简洁的概览。1.5.5 引用的规范
贯穿本书的各个章节引用了各种业界规范和标准。www.servicetechspecs.com网站提供了一个集中的门户网站，用于访问主要标准组织创建和维护的原始规范文件。1.5.6 服务技术杂志
服务技术杂志（原名SOA杂志）由Arcitura Education Inc.and Prentice Hall公司定期出版，并同Thomas Erl的Prentice Hall服务技术丛书（Prentice Hall Service Technology Series）相关。服务技术杂志（www.servicetechmag.com）致力于发表业界专家的专业文章、案例研究及论文。®1.5.7 SOASchool.comSOA认证专家（SOACP）
SOA认证专家课程致力于面向服务的架构及面向服务的专业领域，包括分析、架构、治理、安全、.NET开发、Java开发以及质量保证。
更多信息，参见www.soaschool.com网站。1.5.8 CloudSchool.com™云认证（CCP）专家
云认证专家课程致力于云计算专业领域，包括技术、架构、治理、安全和存储。
更多信息，参见www.cloudschool.com网站。1.5.9 通知服务
如果读者想得到关于本系列书新书出版信息、新补充内容或者是前述网站的关键更新的自动通知，请使用www.servicetechbooks.com网站的通知功能。第2章案例研究背景
2.1 如何使用案例研究
2.2 案例研究背景之一：中西部大学联盟（MUA）
2.3 案例研究背景之二：KioskEtc有限公司2.1 如何使用案例研究
案例研究示例是在现实场景中探索抽象话题的有效手段。这一简短的章节根据背景资料建立起一个持续的故事情节。后续一些章节将以与本章中所描述场景相关的案例研究示例作为结束，为了更容易地识别这些部分，使用了浅灰色背景。
案例研究调查了两个组织的 IT 和业务环境。中西部大学联盟（MUA）是一个大型学术机构，而KioskEtc有限公司是一个中型公司。2.2 案例研究背景之一：中西部大学联盟（MUA）
中西部大学联盟是美国大陆密西西比州西部最古老的教育机构之一。它在工程和研究领域的大学中排名前十，除了主校区之外，还有6个远程校区（见图2-1），雇佣了6000多名教职员工。图2-1 MUA的主校区和卫星校园在地理上是分散的2.2.1 历史
随着美国大陆的扩张，MUA成立于19世纪中叶，最初是为了培养下一代艺术和科学学者而创立的。在过去的一个世纪，它发展成为一流的工程和研究机构，同时也保留了已有的学术项目。在过去的10年中，它与其他欧洲和亚洲学校建立了关系。这些伙伴关系使MUA除了推出在线课程和扩展认证程序之外，还在其他国家提供学位项目。2.2.2 IT环境
过去30年，为适应远程校园、在线学习以及国外机构合作的定制化B2B系统的出现，技术基础设施以指数方式增长。所有校园都支持有线和无线方式接入大学网络。各种类型的支撑服务器和网络设备跨越了不同类型的操作系统。
大学内的每个程序都有单独的IT人员和预算来支持系统管理。远程校区也有自己的IT部门。独立而集中的企业架构组管理着与国外机构的协作。
常见的业务流程，例如学生入学、课程编目、会计、财务以及评分和报表，都有相应的自动化解决方案。主记录存储系统是一台IBM大型机，每天晚上协调运行来自各个远程校区的批处理。不同学校自行采用各种技术和平台，但其中一些具有如下共同特征：
许多课程目录和交易系统都是在线可用的，数据库运行在IBM DB2和Oracle上。一些更新的课程目录实例已经迁移到了MySQL和Microsoft SQL Server上。
最流行的Web应用程序虚拟主机技术是PHP和J2EE，另一些则基于.NET技术。
大部分处理学生信息（入学、学习成绩、助学金等）的工作人员使用3270仿真器来访问大型机。
学生访问课程目录、选课及查看考试状态时，使用PHP编写的基于Web的应用程序。出于安全考虑，其中有一些功能要求使用者身处校园之内。学费支付（如果不通过学生援助或贷款处理的话）要求学生亲自到主校区的会计办公室进行办理。
校园内有一些终端，学生刷卡可以立即了解课程信息。
MUA之IT组织的高层视图，如图2-2所示。图2-2 组成MUA IT生态系统的多种IT资源全图2.2.3 业务目标和障碍
随着入学人数的增多，MUA 看到了将所有事务处理系统转为在线系统的需求，这样学生就可以通过Web进行远程访问。学校进一步注意到，兼职学生和住在校外的通勤者人数增多。其中很多在打工，需要及时地从任何地点访问学校的信息。这样的情况已经导致了学校从学费中获得的收入部分发生了变化，同时，学校也出现了呼吁“少花钱多办事”的声音。此外，最近的经济因素迫使大学减少IT人员并考虑整合系统以方便集中管理。为此，MUA制定了以下目标。
建立单一的IT部门，实现所有MUA校园和合作学校的系统管理和IT支持。虽然系统管理和核心服务开发将集中化，但是各个学校仍需要自己的应用程序开发人员，以处理本校的特殊需求。
走向“信息随需应变”，学生可以从任何位置访问相关的信息并实时进行交易。
在对支持人员影响最小的情况下，为学生提供个性化的教育体验，从而帮助新的在线系统提高使用成功率。
经过仔细评估现有基础设施，MUA决定重新设计IT系统，使之成为基于面向服务架构的系统，从而保留遗留资产，简化各种内外部系统间的集成，改善学生和员工的渠道体验。MUA的企业架构组建议分阶段采纳以下步骤。（1）构建可重用的业务服务。通过构建一层能够被不同平台消费的可重用服务，减少渠道应用程序与后端系统、学校自有系统之间的紧密耦合。这些服务必须满足跨不同学校访问和远程访问的需要，服务定义必须满足实现方式与具体技术无关。（2）整合系统和信息。提供学生、课程和员工信息的整合视图。可以根据情况合并后端应用程序，也可以通过联合后端数据实现。无论学生属于哪个学校，教员都可以根据每个学生的通用视图，做出适当的建议。同样，学生们可以跨校园查看课程和教员信息，选择加入或退出课程，或者与他校教员一起工作。（3）改善渠道体验。建立高响应度的 Web 门户，从而利用常见的可重用服务为学生和员工提供个性化体验。这些服务也允许用户在移动设备上访问，并可根据情况调用提供相应功能的外部服务。（4）构建服务基础设施。增强现有的基于Web和中间件的基础设施，从而实现服务托管，同时满足学校的所有“服务质量”政策要求。此外，万一发生紧急或重要事件，基础设施必须满足广播消息的要求。2.3 案例研究背景之二：KioskEtc有限公司
KioskEtc 公司是一家中型咖啡特许经营商，最初在美国中西部地区的校园内及周边开设商店。除了各种烘焙食品之外，KioskEtc还出售一系列特色咖啡和茶。2.3.1 历史
KioskEtc由中西部大学联盟主校区的学生会创立于20世纪90年代早期。它最终被一家私企收购，现已扩张到中西部地区的其他校园，目前有超过200家分店，超过60%的收入来自校园内店铺。最初的店铺扩张由原始KioskEtc管理团队开展，他们采取租用廉价的校园建筑的策略，建立了第一批咖啡店。然而在过去的两年里，扩张战略已经转为收购当地咖啡店和使用特许经营模式。2.3.2 IT环境
与中西部大学联盟相比，KioskEtc的IT人员非常少。IT人员仍然集中在距中西部大学联盟主校园几英里之外的总部进行运营。每个商店都有自己的系统来处理交易。这些系统与总部的主系统定期进行同步。所有的通用功能，如业务报表、财务、主机托管、供应链管理和人力资源，都在中央IT部门之外执行。大部分定制化解决方案是使用开源软件构建的，并随着时间推移进行了升级，同时采用了一些特定供应商提供的产品，用于运行关键的后台业务应用程序。
KioskEtc还构建了商店管理组合（SMP），它由几个系统组成，涵盖了库存管理、订单处理和时间表管理。出于可伸缩性原因，SMP Web前端最近迁移到了JEE平台，运行在开源Servlet容器中。本地客户端是带有嵌入式系统的Windows桌面应用。SMP的大部分功能使用异步消息机制实现商店和总部之间的通信，只有有限的功能依赖于Web接口实现实时同步通信。异步消息机制基于各种消息队列协议实现，主要使用微软MS MQ和IBM WebSphere MQ。新近他们还使用了JMS，用于抽象化底层特定厂商的消息队列产品。当前环境的简化视图如图2-3所示。图2-3 KioskEtc的SMP环境2.3.3 业务目标和障碍
KioskEtc在过去的几年里一直高速增长。当地多数商店已转为KioskEtc特许经营模式，推迟了对KioskEtc自动化系统的采用。KioskEtc的管理团队想建立一种增强的特许经营模式，使得新店由独立企业主管理和拥有。KioskEtc 负责出借名称、业务模型和产品，而特许经营人保留商店的全部所有权。这是预计中达到100家新店的最快方式。特许经营人可以选择在他们的商店运行任何系统，只要支持（或可以集成）SMP即可。
在引入新的特许经营模式同时，KioskEtc 还扩展了菜单，从而引入热早餐食品。他们希望这样做可以大幅增加收入，但引起的必要变更会增加现有信息系统的复杂性，包括SMP。热早餐菜单需要额外的采购才能支持新品种，因此，KioskEtc 还需对接新的供应商和销售商。KioskEtc 的IT总监要给出一个分阶段的方式，来适应特许经营模式，同时支持扩展菜单项。为达到这个效果，KioskEtc的首席架构师致力于完成服务目录蓝图，从而在已经兼容SOA的SMP系统上建立一系列服务。第一部分 基础知识
第3章 服务简介
第4章 SOA术语和概念
第5章 REST约束和目标第3章 服务简介
3.1 服务术语
3.2 服务术语上下文
术语“服务”根据上下文的不同有多种不同的含义。本章作为后面章节的序幕，阐明与“服务”相关的各种术语之间的基本区别。
我们从以下术语开始：
服务（Service）
服务契约（Service Contract）
服务能力（Service Capability）
服务消费者（Service Consumer）
服务代理（Service Agent）
服务组合（Service Composition）
本章以“服务术语上下文”一节结束，该节说明，在REST和SOA的环境中这些术语的上下文意义可能有所不同。3.1 服务术语
3.1.1 服务
一般来说，服务是一个软件程序，通过发布的技术接口（又叫服务契约）实现其功能。描述服务的符号（不带有任何与服务契约相关的细节）如图3-1所示。图3-1 表示抽象服务的图标
3.1.2 服务契约
表示服务契约的图标如图3-2所示。注意，REST 类型的服务契约具有独特的标识（第6章会对它作详细介绍）。图3-2展示的视图将用于服务建模和设计服务契约。如果需要服务的架构视图，那么服务契约表示为在服务实现中互相嵌套的工件，如图3-3所示。图3-2 用加弦的圆形图标表示一个单据服务契约（左侧），这个图标加以变化就可用于指定一个REST类型的服务（右侧）图3-3 服务架构图中的服务契约（上图）；基于REST的服务契约的架构变种（下图）
3.1.3 服务能力
一个服务契约可以向下分解为一组服务能力，每一个服务能力体现了该服务为其他软件程序提供的功能。图3-4描述了包含一组服务能力的服务契约的图标。图3-4 包含4个服务能力的购买订单（Purchase Order）服务契约
3.1.4 服务消费者
服务消费者是一个运行时角色。其定义是，当一个软件程序访问或者调用一个服务时，或者更具体地说，当软件程序向一个服务契约中的特定服务能力发送消息的时候，该软件程序就成为了服务消费者。一旦收到请求，服务就开始处理请求，然后返回相应的结果消息给服务消费者，或无需返回。图 3-5 展示了各种程序如何作为某个特定服务的消费者，这些程序也包括其他服务。图3-5 购买订单（Purchase Order）服务可以被各种服务消费者访问
3.1.5 服务代理
服务代理是一段不公开技术接口的事件驱动的程序（常常被称作拦截器、监听器或者过滤器）。服务代理用于在运行时截获消息，从而起到中介的作用。当截获一个消息时，服务代理可以实现主动或被动的消息处理。若代理的消息处理逻辑修改消息的内容，则称其为主动方式，否则称为被动方式。例如，截获消息后更新单独的日志文件来跟踪消息，就属于被动处理逻辑。
服务代理在REST和Web Service架构下都扮演了非常重要的角色。这种类型的软件程序被正式记录为服务代理［318］设计模式。本书封内页上的图标示例展现了在图表中表示服务代理的独特图标。
3.1.6 服务组装图3-6 表示服务组合的通用图标
不同的服务常常需要相互配合一起完成任务。服务组合就是将一组服务组装在一起，从而自动地执行常见任务。图3-6展示了抽象服务组合的图标。图3-7从服务契约的角度描述了服务组合，强调在这种场景下服务能力按照特定的顺序被调用。注意
围绕着服务组合还有另外几个术语和主题，相关内容将在第11章的11.1节中介绍。
试读结束[说明：试读内容隐藏了图片]