![服务设计模式：SOAP/WSDL与RESTful Web服务设计解决方案[图书]](http://images.china-pub.com/ebook3765001-3770000/3768786/zcover.jpg)
（已有3条评价）
基本信息
- 原书名：Service Design Patterns：Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services
- 原出版社： Addison-Wesley Professional
- 作者： (美)Robert Daigneau
- 译者： 姚军
- 丛书名： 华章程序员书库
- 出版社：机械工业出版社
- ISBN：9787111443056
- 上架时间：2013-10-30
- 出版日期：2013 年11月
- 开本：16开
- 页码：237
- 版次：1-1
- 所属分类：计算机 > 计算机网络 > Web Server > 综合
【插图】
编辑推荐
Web服务设计领城的经典著作，Amazon五星圾幅销书，Web服务领域资深专家撰写，Martin Fowler和Ian Robinson等大师级人物亲自作序推荐
详细讲解SOAP、WSDL、RESTful 3种Web服务API的风格和20多种常用的Web服务设计模式，深入阐述每一种模式的原理、适用场景，以及针对各种具体问题的解决方案
内容简介
书籍
计算机书籍
《服务设计模式：SOAPWSDL与RESTful Web服务设计解决方案》是Web服务设计领域的经典著作，Amazon五星级畅销书，Web服务领域资深专家撰写，Maritn Fowler和Ian Robinson等大师级人物亲自作序推荐。本书不仅详细讲解了SOAP、WSDL、RESTful 3种Web服务API的风格和20多种常用Web服务设计模式，而且还深入阐述了每一种模式的原理，以及这些模式的适用场景、可以解决的问题、采用之后的影响、详细的解决方案、需要考虑的因素，以及相应的示例，是Web服务设计开发人员、企业架构师和解决方案架构师必读的一本书。
全书共7章：第1章概括了Web服务模式的作用以及实现方法，第2章主要探索Web服务使用的主要API风格，第3章介绍所有客户-服务交互的基础知识，第4章说明了用于管理Web请求和响应的常见服务层模式，第5章关注每种服务方法的实施结果，第6章讨论了与客户端和服务开发人员相关的基本的架构关注点，第7章研究导致中断的因素，并讨论两种常见的版本策略。
计算机书籍
《服务设计模式：SOAPWSDL与RESTful Web服务设计解决方案》是Web服务设计领域的经典著作，Amazon五星级畅销书，Web服务领域资深专家撰写，Maritn Fowler和Ian Robinson等大师级人物亲自作序推荐。本书不仅详细讲解了SOAP、WSDL、RESTful 3种Web服务API的风格和20多种常用Web服务设计模式，而且还深入阐述了每一种模式的原理，以及这些模式的适用场景、可以解决的问题、采用之后的影响、详细的解决方案、需要考虑的因素，以及相应的示例，是Web服务设计开发人员、企业架构师和解决方案架构师必读的一本书。
全书共7章：第1章概括了Web服务模式的作用以及实现方法，第2章主要探索Web服务使用的主要API风格，第3章介绍所有客户-服务交互的基础知识，第4章说明了用于管理Web请求和响应的常见服务层模式，第5章关注每种服务方法的实施结果，第6章讨论了与客户端和服务开发人员相关的基本的架构关注点，第7章研究导致中断的因素，并讨论两种常见的版本策略。
作译者
Robert Daigneau，资深Web技术专家，对Web服务和SOA有深入研究，拥有20多年从业经验。涉及行业很广，涵盖金融服务、制造业、零售业和旅游业等。曾经担任Monster．com的架构主管、Fidelity投资公司的应用开发经理等要职，还曾多次在技术会议上发表演讲。
目录
《服务设计模式：SOAPWSDL与RESTful Web服务设计解决方案》
译者序
Martin Fowler所作的序
Ian Robinson所作的序
前言
致谢
第1章 从对象到Web服务 / 1
1.1 Web服务是什么 / 2
1.2 从本地对象到分布式对象 / 3
1.3 为什么使用Web服务 / 5
1.4 Web服务的考虑因素和替代方案 / 6
1.5 服务和松散耦合的承诺 / 8
1.6 SOA是什么 / 9
1.7 总结 / 9
第2章 Web服务API风格 / 10
2.1 引言 / 10
2.2 设计Web服务API的考虑因素 / 11
2.3 RPC API / 13
2.4 消息API / 21
2.5 资源API / 30
译者序
Martin Fowler所作的序
Ian Robinson所作的序
前言
致谢
第1章 从对象到Web服务 / 1
1.1 Web服务是什么 / 2
1.2 从本地对象到分布式对象 / 3
1.3 为什么使用Web服务 / 5
1.4 Web服务的考虑因素和替代方案 / 6
1.5 服务和松散耦合的承诺 / 8
1.6 SOA是什么 / 9
1.7 总结 / 9
第2章 Web服务API风格 / 10
2.1 引言 / 10
2.2 设计Web服务API的考虑因素 / 11
2.3 RPC API / 13
2.4 消息API / 21
2.5 资源API / 30
译者序
互联网的出现使企业计算平台不再是孤岛，人们可以跨越地域进行数据交换、商业交易，所有主流企业纷纷推出大量的网上服务，客户可以通过传统的桌面电脑和时尚的平板电脑、灵活的智能手机等获得信息和服务，而实现这一切的核心就是Web服务。
Web服务的开发、设计与传统的程序设计有着很大的不同，由于互联网是个异构系统组成的网络，服务端和客户端不仅在地域上不同，在所属组织、使用平台上也往往不同，这就使两者之间的接口提供以及接口耦合度成为关键性问题。良好的接口使得不同组织可以自由开发客户端，而低耦合度则可使双方进行的更改的影响降到最低，从而使服务和客户端有更好的适应性。
为了达到上述目标，Web服务架构师和开发人员经过不懈努力，推出了不同的服务API风格和大量的服务设计模式，这些模式来源于设计开发实践并且经受了时间的检验。进入这一领域的新手们，无不热切地盼望有一本这方面的书籍——能够涵盖各种设计模式，详细地介绍它们的特点、适用场合以及实现方法，本书就是这样一个宝贵的资源。
作者Robert Daigneau在服务的设计和实现方面有着丰富的经验，在这本力作中，他收集了最为经典的3种Web服务API风格和20多种常用设计模式，并精心加以分类，从服务解决的问题、适用场合、优缺点，到详尽的示例均有涉及。本书既可以作为入门者的学习教材，也可以作为高级Web服务/客户端设计人员的案头参考，即使对于一般的软件开发和设计人员，书中介绍的思路也大有裨益。
在本书翻译期间，我们从书中获益良多，因此我们诚挚地将本书介绍给广大读者，希望它能成为读者手中通向优秀设计大门的钥匙。
本书的翻译工作主要由姚军完成，徐锋、陈绍继、郑端、吴兰陟、施游、林起浪、陈志勇、刘建林、宁懿等人也为本书的翻译工作做出了贡献，在此也要感谢华章公司的编辑们对翻译工作提出的许多中肯的意见，同时期待着广大读者朋友的批评指正。
译者
Web服务的开发、设计与传统的程序设计有着很大的不同，由于互联网是个异构系统组成的网络，服务端和客户端不仅在地域上不同，在所属组织、使用平台上也往往不同，这就使两者之间的接口提供以及接口耦合度成为关键性问题。良好的接口使得不同组织可以自由开发客户端，而低耦合度则可使双方进行的更改的影响降到最低，从而使服务和客户端有更好的适应性。
为了达到上述目标，Web服务架构师和开发人员经过不懈努力，推出了不同的服务API风格和大量的服务设计模式，这些模式来源于设计开发实践并且经受了时间的检验。进入这一领域的新手们，无不热切地盼望有一本这方面的书籍——能够涵盖各种设计模式，详细地介绍它们的特点、适用场合以及实现方法，本书就是这样一个宝贵的资源。
作者Robert Daigneau在服务的设计和实现方面有着丰富的经验，在这本力作中，他收集了最为经典的3种Web服务API风格和20多种常用设计模式，并精心加以分类，从服务解决的问题、适用场合、优缺点，到详尽的示例均有涉及。本书既可以作为入门者的学习教材，也可以作为高级Web服务/客户端设计人员的案头参考，即使对于一般的软件开发和设计人员，书中介绍的思路也大有裨益。
在本书翻译期间，我们从书中获益良多，因此我们诚挚地将本书介绍给广大读者，希望它能成为读者手中通向优秀设计大门的钥匙。
本书的翻译工作主要由姚军完成，徐锋、陈绍继、郑端、吴兰陟、施游、林起浪、陈志勇、刘建林、宁懿等人也为本书的翻译工作做出了贡献，在此也要感谢华章公司的编辑们对翻译工作提出的许多中肯的意见，同时期待着广大读者朋友的批评指正。
译者
前言
开始筹划本书时，我不能完全确定SOA和REST到底是什么。我知道自己不是唯一一个有这种感觉的人。大部分关于这些主题的讨论充斥着歧义、夸张、误导和倾向于感情而非理由的争论。作为曾经苦于分布式对象技术的开发人员，我仍然为Web服务深深着迷。我将它们看作是整合不同系统、重用公共业务逻辑的实用手段。
此后，REST的势头很猛，WS*服务已经建立了一个稳定的立足点，而SOA已经宣布消亡[Manes]。在此期间，我对Web服务的着迷始终没有改变。随着移动、云和软件即服务（SaaS）平台导致软件变得越来越分散，Web服务的重要性只会继续增大。我们确实生活在一个激动人心的时代！
本书的内容
本书是利用SOAP/WSDL或者遵循REST架构风格的Web服务设计解决方案的纵览，目标是提供一本简洁的参考书，将基本的Web服务设计概念收录其中。每种模式都描述了一种对于某个反复出现的设计问题已知的且经过证明的解决方案。但是，这些模式并不一定是可以仿效的秘诀。实际上，某些模式可能不会以完全相同的方式再次实现。这本纵览并没有发明新的解决方案，本书中的模式都是开发人员经过长期的努力识别出来的，这些开发人员注意到，某些问题可以使用类似的设计方法解决。本书总结并规范化了这些思路。
服务可以用许多不同的技术实现。例如，SOA从业人员往往认为，诸如CORBA、DCOM以及更新的用于REST和SOAP/WSDL开发的软件框架等不同的技术都可以用于创建服务。本书专注于Web服务。遗憾的是，这个术语已经有些使用过度了。有些人用它来表示任何使用WSDL的可调用函数。这一术语也用于描述REST风格的服务（参见[Richardson，Ruby]）。本书使用“Web服务”这一术语指软件功能，该软件功能需要利用HTTP作为简单数据传输手段（例如SOAP/WSDL服务）或者使用HTTP作为定义服务行为语义的完整应用协议（例如REST风格服务）。
本书的读者
本书针对的是目前使用Web服务或者正在考虑使用它们的专业企业架构师、解决方案架构师和开发人员。这些专业人员分为两种不同的类型：第一类人员创建软件产品（例如商业应用和开放源码SaaS应用）；第二类人员为企业IT部门创建企业级应用。这种分类对软件专业人员进行了调整，同样也可以用于学术领域。
阅读本书所需的背景知识
模式作者往往提供代码示例来阐述设计解决方案。大部分条目都不是针对特定平台的，但是作者仍然必须选择例子中使用的语言、框架和平台。虽然近年来出现许多新语言，但我仍然决定使用Java和C#，原因有二。首先，这两种语言有着很大的市场份额（也就是说，有很大的应用安装基础），并且相当成熟。其次，大部分读者可能使用或者曾经使用过这些语言，因此会很熟悉它们的语法。这里假定读者对这些语言和面向对象编程（OOP）的概念有中高级程度的了解。
本书中的模式大量使用在Java和C#开发人员中很常见的几种框架。这些框架封装了Web服务开发人员最常用的功能。本书不介绍在这些框架中使用的模式，而是说明开发人员利用这些框架构建Web服务时所用的模式。下面是本书中使用的框架：
SOAP/WSDL框架：
-用于XML Web服务的Java API（JAX-WS）
- Apache CXF
- Microsoft公司的Windows Communication Foundation（WCF）
REST框架
-用于REST风格Web服务的Java API（JAX-RS）
- Microsoft公司的WCF
数据绑定框架：
-用于XML绑定的Java体系结构（JAXB）
- Microsoft的DataContractSerializer和其他序列化器（如XmlSerializer）
此后，REST的势头很猛，WS*服务已经建立了一个稳定的立足点，而SOA已经宣布消亡[Manes]。在此期间，我对Web服务的着迷始终没有改变。随着移动、云和软件即服务（SaaS）平台导致软件变得越来越分散，Web服务的重要性只会继续增大。我们确实生活在一个激动人心的时代！
本书的内容
本书是利用SOAP/WSDL或者遵循REST架构风格的Web服务设计解决方案的纵览，目标是提供一本简洁的参考书，将基本的Web服务设计概念收录其中。每种模式都描述了一种对于某个反复出现的设计问题已知的且经过证明的解决方案。但是，这些模式并不一定是可以仿效的秘诀。实际上，某些模式可能不会以完全相同的方式再次实现。这本纵览并没有发明新的解决方案，本书中的模式都是开发人员经过长期的努力识别出来的，这些开发人员注意到，某些问题可以使用类似的设计方法解决。本书总结并规范化了这些思路。
服务可以用许多不同的技术实现。例如，SOA从业人员往往认为，诸如CORBA、DCOM以及更新的用于REST和SOAP/WSDL开发的软件框架等不同的技术都可以用于创建服务。本书专注于Web服务。遗憾的是，这个术语已经有些使用过度了。有些人用它来表示任何使用WSDL的可调用函数。这一术语也用于描述REST风格的服务（参见[Richardson，Ruby]）。本书使用“Web服务”这一术语指软件功能，该软件功能需要利用HTTP作为简单数据传输手段（例如SOAP/WSDL服务）或者使用HTTP作为定义服务行为语义的完整应用协议（例如REST风格服务）。
本书的读者
本书针对的是目前使用Web服务或者正在考虑使用它们的专业企业架构师、解决方案架构师和开发人员。这些专业人员分为两种不同的类型：第一类人员创建软件产品（例如商业应用和开放源码SaaS应用）；第二类人员为企业IT部门创建企业级应用。这种分类对软件专业人员进行了调整，同样也可以用于学术领域。
阅读本书所需的背景知识
模式作者往往提供代码示例来阐述设计解决方案。大部分条目都不是针对特定平台的，但是作者仍然必须选择例子中使用的语言、框架和平台。虽然近年来出现许多新语言，但我仍然决定使用Java和C#，原因有二。首先，这两种语言有着很大的市场份额（也就是说，有很大的应用安装基础），并且相当成熟。其次，大部分读者可能使用或者曾经使用过这些语言，因此会很熟悉它们的语法。这里假定读者对这些语言和面向对象编程（OOP）的概念有中高级程度的了解。
本书中的模式大量使用在Java和C#开发人员中很常见的几种框架。这些框架封装了Web服务开发人员最常用的功能。本书不介绍在这些框架中使用的模式，而是说明开发人员利用这些框架构建Web服务时所用的模式。下面是本书中使用的框架：
SOAP/WSDL框架：
-用于XML Web服务的Java API（JAX-WS）
- Apache CXF
- Microsoft公司的Windows Communication Foundation（WCF）
REST框架
-用于REST风格Web服务的Java API（JAX-RS）
- Microsoft公司的WCF
数据绑定框架：
-用于XML绑定的Java体系结构（JAXB）
- Microsoft的DataContractSerializer和其他序列化器（如XmlSerializer）
序言
Martin Fowler所作的序
企业应用中无法避免的一个事实是它们不是孤岛。你可能主要关注于解决特定的商业问题，但是为此你不能自己收集所有必需的数据，或者开发所有的处理过程。即使你有时间，数据和处理有可能在别处已经完成，重复进行就是一种浪费，而且会造成不一致的情况。因此，几乎所有企业应用都需要与其他应用通信。这些外部系统通常不在同一个机构里，而是由某些第三方机构提供。
许多年来，这类协作中最难的部分之一就是获得某种通信路径。这些应用往往在不同平台上由不同语言编写，在支持不同通信协议的不同操作系统上运行。但是在过去的10年中，Web已经成为这类连接问题的一种解决方案。几乎所有系统都打开80端口来交换文本信息。
但是，围绕Web的通信方式还遗留着许多问题。它们应该使用RPC风格的API、面向消息的API还是时尚的REST风格？应该直接在服务中嵌入逻辑还是将其委托给底层对象？我们如何在不破坏客户端的情况下修改正在使用的服务？
在我的系列丛书中，每本书都有特定的主题，这些主题在其他地方还没有太多介绍，但是关于Web服务的不同方面的书籍已经很多。因此，当我看到Robert的手稿时，我认为自己不会对此感兴趣。令我改变想法的是，在这样一本手册中集合了所有上述的关键问题，而且本书的风格正是我所喜欢的，我认为这样的技术书籍才是值得花费精力阅读的。
首先，Robert采用了将主题领域分解为不同模式的方法，这样我们就有了用来谈论这些主题的词汇表。然后，他转向每个模式，说明它们的工作原理和选择它们的方法。结果是，你能够看到Web服务设计的不同方法，并确定哪一种更适合于你的环境。他提供的代码示例能够帮助你看到这些模式在实践中的运用，而这些模式通常足以应用到许多技术架构之上。
本书收集了一些重要的设计决策点，从而帮助你用关注原则的风格使用Web服务，而这些原则即使在技术出现变化的情况下仍然是很宝贵的。
Martin Fowler
http://martinfowler.com
Ian Robinson所作的序
分布式应用开发往往开始得很顺利，但是结果却很糟糕。“指向、添加Web引用、点击”，这就是开发人员将加载的客户端指向你精心制作的服务接口时所做的。由于设计工具的更换，我们不知不觉地将松散耦合变成了不负责任的混乱；到发布的时候，我们都不得不加入因循守旧的一派。
在更加谨小慎微的时代，我们曾经说过：“不，不要分布”。在大部分情况下，这一建议仍然是正确的。逻辑上的层次（Layer）并不等同于物理上的层（Tier）。不管你采用多少种开放标准，将三层应用架构割裂为分布式的各个部分也显然是愚蠢的。
但是今天的应用程序很少成为孤岛。业务能力分散到机构的不同边界中，而实现这些业务自动化的系统也是如此。如果我们要支持现代供应链的分布式特性，在公司内部和不同公司之间，某种形式的服务导向是必要的。
Web及其基础技术已经充分地证明了这一点。不管你是否意识到（或者毫不关心）Web在分布式系统历史上的显要地位，你所构建或者使用过的大部分服务都和Web有某些相关性。实际上，我们认为与传输无关的SOAP协议也倾向于使用HTTP。尽管这一点并不明显，但是不要忘记，Web已担负服务的重任多年。
当我们纵观今日的Web服务时，会发现至少有3种方法能让我们构建的软件适应于Web。Web的成功并不是因为其支持者有无人能及的正确性，而是因为它容许很多种架构风格，这些架构存在于Web之上，有时甚至超越Web的边界。有些服务和应用隐藏在Web背后，它们将Web看作不受欢迎但却必要的狭窄关口，只有通过它才能访问对象和过程。调整视角，你就会发现有些服务在Web之“上”，即它们不将HTTP看作是一种简单的传输手段，而是将它看作RFC 2616中所描述的、健壮的协调和传输协议。最后，你会发现一些（数量很少）服务是属于Web的。这些服务使用Web的基本技术（特别是URI、HTTP以及通用的超媒体表现格式，如HTML）向消费者提供一个数据网络，其中的数据包含了描述如何访问和操纵更多数据的信息。
本书集合了当采用多种Web分布技术来设计谨慎而具有防御性的系统时需要了解的知识。作为合理策略和技术的纵览，它能够与我的许多朋友以及ThoughtWorks的同事们经过辛勤努力而获得的经验相媲美。这是一本关于如何使用Web服务把事情做好的书；这也是一本能够帮助你远离困境的书。通过保护服务所在域及来自大批客户端数据的复杂性、提升内部质量及服务寿命的简洁性之间的平衡，本书能够帮助你避免受困于漫长的部署工作中。
Ian Robinson
企业应用中无法避免的一个事实是它们不是孤岛。你可能主要关注于解决特定的商业问题，但是为此你不能自己收集所有必需的数据，或者开发所有的处理过程。即使你有时间，数据和处理有可能在别处已经完成，重复进行就是一种浪费，而且会造成不一致的情况。因此，几乎所有企业应用都需要与其他应用通信。这些外部系统通常不在同一个机构里，而是由某些第三方机构提供。
许多年来，这类协作中最难的部分之一就是获得某种通信路径。这些应用往往在不同平台上由不同语言编写，在支持不同通信协议的不同操作系统上运行。但是在过去的10年中，Web已经成为这类连接问题的一种解决方案。几乎所有系统都打开80端口来交换文本信息。
但是，围绕Web的通信方式还遗留着许多问题。它们应该使用RPC风格的API、面向消息的API还是时尚的REST风格？应该直接在服务中嵌入逻辑还是将其委托给底层对象？我们如何在不破坏客户端的情况下修改正在使用的服务？
在我的系列丛书中，每本书都有特定的主题，这些主题在其他地方还没有太多介绍，但是关于Web服务的不同方面的书籍已经很多。因此，当我看到Robert的手稿时，我认为自己不会对此感兴趣。令我改变想法的是，在这样一本手册中集合了所有上述的关键问题，而且本书的风格正是我所喜欢的，我认为这样的技术书籍才是值得花费精力阅读的。
首先，Robert采用了将主题领域分解为不同模式的方法，这样我们就有了用来谈论这些主题的词汇表。然后，他转向每个模式，说明它们的工作原理和选择它们的方法。结果是，你能够看到Web服务设计的不同方法，并确定哪一种更适合于你的环境。他提供的代码示例能够帮助你看到这些模式在实践中的运用，而这些模式通常足以应用到许多技术架构之上。
本书收集了一些重要的设计决策点，从而帮助你用关注原则的风格使用Web服务，而这些原则即使在技术出现变化的情况下仍然是很宝贵的。
Martin Fowler
http://martinfowler.com
Ian Robinson所作的序
分布式应用开发往往开始得很顺利，但是结果却很糟糕。“指向、添加Web引用、点击”，这就是开发人员将加载的客户端指向你精心制作的服务接口时所做的。由于设计工具的更换，我们不知不觉地将松散耦合变成了不负责任的混乱；到发布的时候，我们都不得不加入因循守旧的一派。
在更加谨小慎微的时代，我们曾经说过：“不，不要分布”。在大部分情况下，这一建议仍然是正确的。逻辑上的层次（Layer）并不等同于物理上的层（Tier）。不管你采用多少种开放标准，将三层应用架构割裂为分布式的各个部分也显然是愚蠢的。
但是今天的应用程序很少成为孤岛。业务能力分散到机构的不同边界中，而实现这些业务自动化的系统也是如此。如果我们要支持现代供应链的分布式特性，在公司内部和不同公司之间，某种形式的服务导向是必要的。
Web及其基础技术已经充分地证明了这一点。不管你是否意识到（或者毫不关心）Web在分布式系统历史上的显要地位，你所构建或者使用过的大部分服务都和Web有某些相关性。实际上，我们认为与传输无关的SOAP协议也倾向于使用HTTP。尽管这一点并不明显，但是不要忘记，Web已担负服务的重任多年。
当我们纵观今日的Web服务时，会发现至少有3种方法能让我们构建的软件适应于Web。Web的成功并不是因为其支持者有无人能及的正确性，而是因为它容许很多种架构风格，这些架构存在于Web之上，有时甚至超越Web的边界。有些服务和应用隐藏在Web背后，它们将Web看作不受欢迎但却必要的狭窄关口，只有通过它才能访问对象和过程。调整视角，你就会发现有些服务在Web之“上”，即它们不将HTTP看作是一种简单的传输手段，而是将它看作RFC 2616中所描述的、健壮的协调和传输协议。最后，你会发现一些（数量很少）服务是属于Web的。这些服务使用Web的基本技术（特别是URI、HTTP以及通用的超媒体表现格式，如HTML）向消费者提供一个数据网络，其中的数据包含了描述如何访问和操纵更多数据的信息。
本书集合了当采用多种Web分布技术来设计谨慎而具有防御性的系统时需要了解的知识。作为合理策略和技术的纵览，它能够与我的许多朋友以及ThoughtWorks的同事们经过辛勤努力而获得的经验相媲美。这是一本关于如何使用Web服务把事情做好的书；这也是一本能够帮助你远离困境的书。通过保护服务所在域及来自大批客户端数据的复杂性、提升内部质量及服务寿命的简洁性之间的平衡，本书能够帮助你避免受困于漫长的部署工作中。
Ian Robinson
书摘
第1章
从对象到Web服务
Web服务在现实中已经应用了很多年。在此期间，就如何使用Web服务而言，开发人员和架构师们经常会遇到一些反复出现的设计挑战。我们了解到，在解决某些特定的问题时，有些特定的设计方法的确比其他方法更有效。本书的读者应该是那些正在使用Web服务或者正在考虑使用Web服务的软件开发人员和架构师。本书的目的是让他们了解一些最常见的和基础的Web服务设计方案，并帮助他们决定何时使用这些设计方案。这里讨论的所有概念都源于现实生活中的经验教训，并通过一些代码示例来演示这些经过实践验证的方案。
服务开发人员会遇到一系列问题，如下所述。
如何创建服务API，普通风格的API是什么样的，特殊风格的API应该在什么时候使用？
在复杂会话中，多个参与方可以在一段持续的时间内交换数据。那么，客户端和服务如何进行通信，创建复杂会话的基础是什么？
实现服务逻辑有哪些可供选择的方法，什么时候应该使用特定的某种方法？
如何减少客户端与服务所使用的底层系统的耦合？
如何发现关于服务的信息？
如何在客户端或服务端提供对身份验证、数据校验、缓存和日志记录等通用功能的支持？
对服务进行的哪些改变会中断客户端的应用？
服务的版本管理有哪些常用的方法？
如何设计服务，才能让它既支持业务逻辑的不断演化，又不必强制客户端频繁地升级？
以上这些问题只是我们必须回答的问题中的一小部分。本书将会帮助你找到合适你的应用场景的解决方案。
在本章中，你将会学习服务到底是什么，Web服务是如何解决之前服务的不足之处的。
1.1Web服务是什么
从技术角度来说，服务（service）这个术语可以指任何软件功能，比如执行一项业务任务、提供文件访问（如文本、文档、图片、视频、音频等），或者执行一些通用功能（如身份验证或日志记录）。对于这些目标，服务实现可以使用自动化的工作流引擎、属于领域模型（Domain Model）的对象[POEAA]、商业软件包、传统应用程序的API、面向消息的中间件（Message-Oriented Middleware，MOM），当然，还有数据库。用许多方法都可以实现服务。事实上，各种各样的技术，例如CORBA和DCOM、为REST和SOAP/WSDL开发的新式软件框架等，都可以用来创建服务。
本书主要介绍如何使用服务在不同应用之间共享逻辑功能，以及如何使运行于不同计算平台上的软件互相协作。这些平台可以是硬件、操作系统（如Linux、Windows、z/OS、Android、iOS）、软件框架（如Java、.NET、Rails）和编程语言的任意组合。本书所讨论的服务，我们都假设它们是在处理客户端应用之外的机器上执行的。服务可以在与客户端在同一台机器上进行处理，不过，服务通常都是在另一台机器上进行处理的。虽然可以用诸如CORBA和DCOM之类的技术来创建服务，但本书的重点是Web服务。Web服务为集成不同的系统提供了方法，并通过HTTP来输出可重用的业务功能。这些服务或者是将HTTP作为一种简单的信息运输工具，通过它来承载数据（如SOAP/WSDL服务）；或者是将HTTP作为一种完整的应用控制协议，为服务行为定义各种语义（如RESTful服务）。
术语
Web服务开发人员经常使用不同的术语来称呼角色相当的概念。遗憾的是，这已经导致了很多混淆。因此，我们用下面这两列澄清这些术语，并将其作为参考。第一列列举了几个用于表示发送请求或触发事件的软件处理过程的名称。第二列包含了用于描述对这些请求和事件做出响应或反应的软件功能的术语。每列包含的这些术语都是同义词。
从对象到Web服务
Web服务在现实中已经应用了很多年。在此期间，就如何使用Web服务而言，开发人员和架构师们经常会遇到一些反复出现的设计挑战。我们了解到，在解决某些特定的问题时，有些特定的设计方法的确比其他方法更有效。本书的读者应该是那些正在使用Web服务或者正在考虑使用Web服务的软件开发人员和架构师。本书的目的是让他们了解一些最常见的和基础的Web服务设计方案，并帮助他们决定何时使用这些设计方案。这里讨论的所有概念都源于现实生活中的经验教训，并通过一些代码示例来演示这些经过实践验证的方案。
服务开发人员会遇到一系列问题，如下所述。
如何创建服务API，普通风格的API是什么样的，特殊风格的API应该在什么时候使用？
在复杂会话中，多个参与方可以在一段持续的时间内交换数据。那么，客户端和服务如何进行通信，创建复杂会话的基础是什么？
实现服务逻辑有哪些可供选择的方法，什么时候应该使用特定的某种方法？
如何减少客户端与服务所使用的底层系统的耦合？
如何发现关于服务的信息？
如何在客户端或服务端提供对身份验证、数据校验、缓存和日志记录等通用功能的支持？
对服务进行的哪些改变会中断客户端的应用？
服务的版本管理有哪些常用的方法？
如何设计服务，才能让它既支持业务逻辑的不断演化，又不必强制客户端频繁地升级？
以上这些问题只是我们必须回答的问题中的一小部分。本书将会帮助你找到合适你的应用场景的解决方案。
在本章中，你将会学习服务到底是什么，Web服务是如何解决之前服务的不足之处的。
1.1Web服务是什么
从技术角度来说，服务（service）这个术语可以指任何软件功能，比如执行一项业务任务、提供文件访问（如文本、文档、图片、视频、音频等），或者执行一些通用功能（如身份验证或日志记录）。对于这些目标，服务实现可以使用自动化的工作流引擎、属于领域模型（Domain Model）的对象[POEAA]、商业软件包、传统应用程序的API、面向消息的中间件（Message-Oriented Middleware，MOM），当然，还有数据库。用许多方法都可以实现服务。事实上，各种各样的技术，例如CORBA和DCOM、为REST和SOAP/WSDL开发的新式软件框架等，都可以用来创建服务。
本书主要介绍如何使用服务在不同应用之间共享逻辑功能，以及如何使运行于不同计算平台上的软件互相协作。这些平台可以是硬件、操作系统（如Linux、Windows、z/OS、Android、iOS）、软件框架（如Java、.NET、Rails）和编程语言的任意组合。本书所讨论的服务，我们都假设它们是在处理客户端应用之外的机器上执行的。服务可以在与客户端在同一台机器上进行处理，不过，服务通常都是在另一台机器上进行处理的。虽然可以用诸如CORBA和DCOM之类的技术来创建服务，但本书的重点是Web服务。Web服务为集成不同的系统提供了方法，并通过HTTP来输出可重用的业务功能。这些服务或者是将HTTP作为一种简单的信息运输工具，通过它来承载数据（如SOAP/WSDL服务）；或者是将HTTP作为一种完整的应用控制协议，为服务行为定义各种语义（如RESTful服务）。
术语
Web服务开发人员经常使用不同的术语来称呼角色相当的概念。遗憾的是，这已经导致了很多混淆。因此，我们用下面这两列澄清这些术语，并将其作为参考。第一列列举了几个用于表示发送请求或触发事件的软件处理过程的名称。第二列包含了用于描述对这些请求和事件做出响应或反应的软件功能的术语。每列包含的这些术语都是同义词。
