透析SOA、RPC、SOAP、REST、ICE、ESB模型发展史

最初的程序全是单机程序，没有网络，没有RPC，更没有RESTful。程序猿写的东西孤独运行在单机上。

那时的程序猿们语言相通，参与开发同一套系统的团队可以面对面沟通。

网络出现了。网络，也带来变乱。网络是不同系统之间的通信，无论是早期网络，还是web，如何实行系统间的互联互通是个头痛的问题。

而SOA就是一种思想，就是把项目拆成组件，每个组件暴露出服务，“你调我，我调你”，大家一起把活干完。强调的是服务的相互调用。

SOA

SOA:面向服务的软件架构（Service Oriented Architecture）,是一种计算机软件的设计模式，主要应用于不通应用组件中通过某种协议来互操作。例如典型的通过网络协议。因此SOA是独立于任何厂商、产品与技术的。

SOA作为一种架构依赖于服务的方向，它的基本设计原理是：服务提供了一个简单的接口，抽象了底层的复杂性，然后用户可以访问独立的服务，而不需要去了解服务底层平台实现。

基于SOA的解决方案，努力使经营目标而建立企业的质量体系。SOA架构是五层水平：

1. 用户界面层–这些GUI的最终用户或应用程序访问的应用程序/服务接口。

2. 业务流程层–这些精心设计的代表在应用方面的业务用例服务。

3. 服务层–服务合并在一起，为整个企业提供实时服务。

4. 服务组件层–用来建造服务的组件，如功能库和技术库，技术接口等。

5. 操作系统–这层包含数据模型，企业数据仓库，技术平台等。

正因为SOA架构实现不依赖于技术，因此能够被各种不同的技术实现。

例如：

SOAP, RPC，REST，DCOM，CORBA，OPC-UA，Web services，DDS，Java RMI，WCF (Microsoft‘s implementation of web services now forms a part of WCF)，Apache Thrift，SORCER

web service是SOA很常用的一种实行方式。

Web Service

Web Service 也提出了好久了, 那么究竟什么是 Web Service ?

简单地说, 也就是服务器如何向客户端提供服务.

webService的常用的方法有:

RPC （远程过程调用协议）所谓的远程过程调用 (面向方法)
SOAP （简单对象访问协议）所谓的面向服务的架构(面向消息)
REST （表象化状态转变）所谓的 Representational state transfer (面向资源)

下面分别作简单介绍：

RPC：即远程过程调用(Remote rocedure call), 很简单的概念, 像调用本地服务(方法)一样调用服务器的服务(方法)。透过向装置了这个协定的服务器发出HTTP请求。发出请求的用户端一般都是需要向远端系统要求呼叫的软件。

通常的实现有 XML-RPC , JSON-RPC , 通信方式基本相同, 所不同的只是传输数据的格式.

(如果你已经习惯于XML繁重的尖括号,你不妨可以尝试下更加轻型,高效,传输效率高的 JSON.)

一个简单的通信过程通常为:

Request

  member.get_username_by_id              1

Response

              Zhu Tao

向服务器发送一个过程调用的方法及其参数, 得到服务器返回的方法执行的结果.

在 XML-RPC 之后又有了更加强大的 SOAP , 用于一些比较复杂的系统之上。（在新的功能不断被引入下，这个标准慢慢演变成为今日的SOAP协定。XML-RPC协定是已登记的专利项目。）

SOAP：简单对象访问协议（Simple Object Access Protocol）是一种标准化的通讯规范，主要用于Web服务（web service）中。

SOA 是前几年炒的很火的一个词, 不亚于当前的 Cloud Computing , 如果说 RPC 是基于方法调用(method),那么 SOA 则是基于消息，基于方法调用通常会与特定的程序语言耦合起来,而后者则与具体的实现语言无关, 所以在一定程度上得到大公司的支持。

用一个简单的例子来说明 SOAP 使用过程，一个 SOAP 消息可以发送到一个具有 Web Service 功能的 Web 站点，例如，一个含有房价信息的数据库，消息的参数中标明这是一个查询消息，此站点将返回一个 XML 格式的信息，其中包含了查询结果（价格，位置，特点，或者其他信息）。由于数据是用一种标准化的可分析的结构来传递的，所以可以直接被第三方站点所利用。

REST：表征状态转移（Representational State Transfer），采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将所有 Web 系统的服务抽象为资源，REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。

Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的Http协议就可以实现，开发者也会受益于这种轻量级的协议。

REST是一种软件架构风格而非协议也非规范，是一种针对网络应用的开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

一种 Web Service 能够如果满足 REST 的几个条件, 通常就称这个系统是 Restful 的.

这里提到的条件包括:

C/S结构 (这是Internet服务的一个基本特征)
无状态 (很熟悉吧,呵呵)
可以cache (想起了浏览器?)
分层系统 (想起了无数的架构?)
统一的接口 (如果这是可能的,程序员有福了, :D)
code on demand(可选, 其实是一种扩展性的要求)

看了这几个特征后,你想起了什么?

你可能会破口而出: HTTP.

我答: You got it!

HTTP是WWW的最核心的协议, 它将简单的分布于世界各个角落的资源都统一起来, 统一的地址, 简单的方法, 和一定数量的表达方式.(你可能对这三点描述很模糊,请go ahead).

REST 的三个要素是 唯一的资源标识, 简单的方法 (此处的方法是个抽象的概念), 一定的表达方式.

看下图:

图一. REST的三角架构(摘自 Restful User Experience )

REST 是以资源为中心, 名词即资源的地址, 动词即施加于名词上的一些有限操作, 表达是对各种资源形态的抽象.

以HTTP为例, 名词即为URI(统一资源标识), 动词包括POST, GET, PUT, DELETE等(还有其它不常用的2个,所以整个动词集合是有限的), 资源的形态(如text, html, image, pdf等)

Web 应用程序最重要的 REST 原则是

客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。

在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一的界面，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎，资源表示通过超链接互联。

另一个重要的 REST 原则是分层系统，这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层，可以限制整个系统的复杂性，促进了底层的独立性。

当 REST 架构的约束条件作为一个整体应用时，将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构，改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。

在 RPC 样式的架构中，关注点在于方法，而在 REST 样式的架构中，关注点在于资源 —— 将使用标准方法检索并操作信息片段（使用表示的形式）。资源表示形式在表示形式中使用超链接互联。

RESTful API 设计指南

参考阮老师的博客吧：http://www.ruanyifeng.com/blog/2014/05/restful_api.html

觉得这个没有什么好说的！

RPC、SOAP、REST的区别

REST这种设计风格，它的很多思维方式与RPC是完全冲突的。

RPC的思想是把本地函数映射到API，也就是说一个API对应的是一个function，我本地有一个getAllUsers，远程也能通过某种约定的协议来调用这个getAllUsers。至于这个协议是Socket、是HTTP还是别的什么并不重要； RPC中的主体都是动作，是个动词，表示我要做什么。

而REST则不然，它的URL主体是资源，是个名词。而且也仅支持HTTP协议，规定了使用HTTP Method表达本次要做的动作，类型一般也不超过那四五种。这些动作表达了对资源仅有的几种转化方式。这种设计思路是反程序员直觉的，因为在本地业务代码中仍然是一个个的函数，是动作，但表现在接口形式上则完全是资源的形式。就像面向对象的「万物皆对象」理论在习惯了纯粹面向过程开发的程序员眼里显得十分别扭一样：我的代码本来就是按顺序、循环、分支这么运行的啊，为啥非得在很明确的结构上封装一层一层的基类子类接口，还要故意给两个函数起同一个名字，调用时才选择用哪一个呢？使用「万物皆资源」的思想编写实际项目中的API接口时，最常见的问题就是「这玩意到底是个什么资源？………………算了，我就直接写吧，不管什么风格了」比如，login和logout应该怎么REST化？比如，多条件复合搜索在GET里写不下怎么办？比如，大量资源的删除难道要写几千个DELETE？其实在理解了REST后，这些都不是什么无解的难题，只是思维方式要转换一下： login和logout其实只是对session资源的创建和删除； search本身就是个资源，使用POST创建，如果不需持久化，可以直接在Response中返回结果，如果需要（如翻页、长期缓存等），直接保存搜索结果并303跳转到资源地址就行了； id多到连url都写不下的请求，应该创建task，用GET返回task状态甚至执行进度； ……等等等。

如果你想只记住一点,那么就请记住 RPC是以动词为中心的, REST是以名词为中心的, 此处的动词指的是一些方法, 名词是指资源.

你会发现,以动词为中心,意味着,当你要需要加入新功能时,你必须要添加更多的动词, 这时候服务器端需要实现相应的动词(方法), 客户端需要知道这个新的动词并进行调用.

而以名词为中心, 假使我请求的是 hostname/friends/, 无论这个URI对应的服务怎么变化,客户端是无需关注和更新的,而这种变化对客户端也是透明的.

至于其它的区别,如对实现语言的依赖, 耦合性等,这些都是上面提到的这个根本区别所衍生的.

推荐阅读 Restful User Experience (这个slide是个人认为解释的最好的) 还有 ReST vs SOA(P).

RPC与REST如何选择?

通常如果我们是客户端,我们基本上是没有选择的权利的, 服务提供商通常只有一种架构的服务.例如facebook, 人人网开放的API(使用的是 REST ).

但是倘若我们有幸设计和实现自己的 Web Service 我们该如何选择呢?

成熟度上：SOAP在成熟度上优于REST

效率和易用性上：REST更胜一筹

安全性上：SOAP安全性高于REST，因为REST更关注的是效率和性能问题

总体上，因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。

根据笔者自己的经验和心得, 建议 能够使用REST就尽量使用REST, 主要基于下面几个考虑:

扩展性
松耦合(意味着,不用强制要求客户端去更新相应的代码)
客户端实现语言无关
性能
安全性(例如HTTPS)

当然上述的几点也并非 RPC 都不满足,不过相对而言, REST 更加清晰和简洁, 再辅以 JSON 相应的服务会在性能和稳定性(简单通常意味着robust)方面有很大的提高。

当然，如果只是规定了一种规范，却不理解它表相下面的思维方式，实施中又按照自己的理解随意变动，那结果肯定是混乱不堪的。当然，API怎么写是开发者的自由。但如果一个API在url里放一堆动词、资源设计混乱、各种乱用HTTP Method和Status Code，还自称RESTful API的话，那就像你养了一条狗，还管它叫猫一样。这种混搭产物，不如叫它REFU吧。（Remove Extension From Url：从url里去掉文件扩展名）前面说了半天REST的理念和不懂REST造成的问题，但是，这并不代表REST比RPC更「高等」，更不是说不理解REST的人是落伍的。所谓代码风格、接口形式、各种林林总总的格式规定，其实都是为了在团队内部形成共识、防止个人习惯差异引起的混乱。JSON-RPC当然也是有规范的，但相比REST实在宽松太多了。如果一个开发团队规定必须在url里写action，所有请求都是POST，可以吗？当然也没问题，只是不要拿出去标榜自己写的是RESTful API就行。规范最终还是为了开发者和软件产品服务的，如果它能带来便利、减少混乱，就值得用；反之，如果带来的麻烦比解决的还多，那就犯不上纯粹跟风追流行了。

所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景，正是那句老话：适合的才是最好的

ICE

ICE是分布式应用的一种比较好的解决方案，虽然现在也有一些比较流行的分布式应用解决方案，如微软的.NET（以及原来的DCOM）、CORBA及WEB SERVICE等，但是这些面向对象的中间件都存在一些不足：

.NET是微软产品，只面向WINDOWS系统，而实际的情况是在当前的网络环境下，不同的计算机会运行不同的系统，如LINUX上面就不可能使用.NET；

CORBA虽然在统一标准方面做了很多的工作，但是不同的供应商实现之间还是缺乏互操作性，并且目前还没有一家供应商可以针对所有的异种环境提供所有的实现支持，且CORBA的实现比较复杂，学习及实施的成本都会比较高；

webService最要命的缺点就是他的性能问题，对于要求比较高的行业是很少会考虑 webService的。

ICE的产生就是源于.NET、CORBA及WEB SERVICE这些中间件的不足，它可以支持不同的系统，如WINDOWS、LINUX等，也可以支持在多种开发语言上使用，如C++、C、JAVA、RUBY、PYTHON、VB等，服务端可以是上面提到的任何一种语言实现的，客户端也可以根据自己的实际情况选择不同的语言实现，如服务端采用C语言实现，而客户端采用JAVA语言实现，底层的通讯逻辑通过ICE的封装实现，我们只需要关注业务逻辑。

ESB

企业服务总线（Enterprise Service Bus，ESB）的概念是从面向服务体系架构(Service Oriented Architecture， SOA)发展而来的。SOA描述了一种IT基础设施的应用集成模型；其中的软构件集是以一种定义清晰的层次化结构相互耦合。一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。

在企业计算领域，企业服务总线是指由中间件基础设施产品技术实现的、通过事件驱动和基于XML消息引擎，为更复杂的面向服务的架构提供的软件架构的构造物。企业服务总线通常在企业消息系统上提供一个抽象层，使得集成架构师能够不用编码而是利用消息的价值完成集成工作。

企业服务总线提供可靠消息传输，服务接入，协议转换，数据格式转换，基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式。

ESB与EAI区别：

ESB是将所有的系统的交互都放在SOA统一服务总线上面来控制处理。

EAI只是将不同的系统集成起来（可以采用ESB总线形式，也可以采用点对点的形式）。