透析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的经常使用的方法有:

1. RPC   （远程过程调用协议 ）所谓的远程过程调用 (面向方法)

2. SOAP   （简单对象访问协议） 所谓的面向服务的架构(面向消息)

3. 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 的.

这里提到的条件包括:

1. C/S结构 (这是Internet服务的一个基本特征)

2. 无状态 (很熟悉吧,呵呵)

3. 能够cache (想起了浏览器?)

4. 分层系统 (想起了无数的架构?)

5. 统一的接口 (若是这是可能的,程序员有福了, :D)

6. 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, 主要基于下面几个考虑:

1. 扩展性

2. 松耦合(意味着,不用强制要求客户端去更新相应的代码)

3. 客户端实现语言无关

4. 性能

5. 安全性(例如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总线形式，也能够采用点对点的形式）。

 

 

ESB解决的问题

当你的应用像下面同样时，这个时候就须要考虑使用ESB了，如图：

各个应用系统之间的调用造成了一张网，没有逻辑，随着业务的增长，维护简直就是一场恶梦。

 

各个应用的逻辑很清晰，每一个应用都只须要关心如何暴露本身的服务，而调用的应用只须要知道如何调用服务，至于怎么作，去找谁，则彻底交给ESB来完成。

 

参考资料：

三种主流的Web服务实现方案（REST+SOAP+XML-RPC）简述及比较

Web Service实践之REST vs RPC

谈谈本身对REST、SOA、SOAP、RPC、ICE、ESB、BPM知识汇总及理解

如何选择ESB

Restful api详解和rpc api 区别 （原文连接没有搜到，谷歌找到的是转