基于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

因此REST、SOAP、RPC、RMI、DCOM等都是SOA的一种实现而已。

Webservice：

Web services是建立可互操作的分布式应用程序的新平台。

webservice是一种标准，他可以通过soap或rest的方式来实现。

传统的soap-webservice，使用了soap协议（基于xml包装）等。如果使用restful-webservice的话，则不需要soap与之相关的协议等，而是通过最简单的 http 协议传输数据 ( 包括 xml 或 json) 。既简化了设计，也减少了网络传输量（因为只传输代表数据的 xml 或 json ，没有额外的 xml 包装）。

webservice相关的几个概念：

wsdl：网络服务描述语言是Web Service的描述语言，它包含一系列描述某个web service的定义。

UDDI：是一种目录服务，企业可以使用它对 Web services 进行注册和搜索。UDDI，英文为 "Universal Description, Discovery and Integration"，可译为“通用描述、发现与集成服务”。

UDDI[1] 是一种规范，它主要提供基于Web服务的注册和发现机制，为Web服务提供三个重要的技术支持：①标准、透明、专门描述Web服务的机制；②调用Web服务的机制；③可以访问的Web服务注册中心。UDDI规范由OASIS（Organization for the Advancement of Structured Information Standards[1] ）标准化组织制定。[1]

其中RMI、RPC、SOAP比较：

普通的Web项目，一般是绑定了特定的渲染语言（jsp、velocity，freemark），当然也有原始的html。但是仅仅限定了特定的返回数据格式与之相对应。Webservice项目则是能够被其他系统调用（约束了相关格式）。因此普通的利用ssh或者springmvc建立的web项目并没有发布webservice。普通的web项目可以使用一些技术将需要发布的接口发布出去，就成为了webservice了。

什么是SOAP?

SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。事实上SOAP数据使用XML数据格式，定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。而且随着需要的增长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。另一方面，各个服务器都可以基于这个协议推出自己的API，即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生。WSDL (Web Service Description Language) 也遵循XML格式，用来描述哪个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，简言之，服务发现。现在，使用Web Service的过程变成，获得该服务的WSDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样SOAP格式的应答，最后根据先前的WSDL解码数据。绝大多数情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。

什么是REST？

REST (REpresentational State Transfort) 形式上应该表述为客户端通过申请资源来实现状态的转换，在这个角度系统可以看成一台虚拟的状态机。抛开R. T. Fielding博士论文里晦涩的理论不说，REST应该满足这样的特点：1)客户端和服务器结构；2)连接协议具有无状态性；3)能够利用Cache机制增进性能；4)层次化的系统；说到底，REST只是一种架构风格，而不是协议或标准。但这种新的风格（也许已经历史悠久？）对现有的以SOAP为代表的Web Service造成的冲击也是革命性的，因为它面向资源，甚至连服务也抽象成资源，因为它和HTTP紧密结合，因为它服务器无状态。

目前知道的三种主流的Web服务实现方案为：
REST：表象化状态转变 (软件架构风格）
SOAP：简单对象访问协议
XML-RPC：远程过程调用协议（已经慢慢被SOAP取代）

其他理解：

REST：表征状态转移（Representational State Transfer），采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将所有 Web 系统的服务抽象为资源，REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的Http协议就可以实现，开发者也会受益于这种轻量级的协议。REST是一种软件架构风格而非协议也非规范，是一种针对网络应用的开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

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

XML-RPC：一个远程过程调用（remote procedure call，RPC)的分布式计算协议，通过XML将调用函数封装，并使用HTTP协议作为传送机制。后来在新的功能不断被引入下，这个标准慢慢演变成为今日的SOAP协定。XML-RPC协定是已登记的专利项目。XML-RPC透过向装置了这个协定的服务器发出HTTP请求。发出请求的用户端一般都是需要向远端系统要求呼叫的软件。

三种方案的简单比较

XML-RPC已慢慢的被SOAP所取代，现在很少采用了，但它还是有版权的，我在此就不作多介绍。
成熟度上：SOAP在成熟度上优于REST

效率和易用性上：REST更胜一筹（REST效率更高的原因在于，仅仅是建议的Http协议之上的一种协议。而SOAP则需要对数据、xml封装信息头，解封装等）

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

分布式能力：REST更适合在分布式环境中使用、因为REST是基于原生Http协议的，而http协议是无状态的。大型分布式环境都能够对无状态支持良好，无状态增强了整个系统的扩展性。这也是为什么越来越多的云计算，分布式项目选择REST。

（注：SOAP也是基于HTTP协议的，但是却提供了session、cookie等机制来使得SOAP有状态，从而支持需要有状态的业务。有状态举例：1、增加一个用户2、获取最新增加的用户。那1的执行成功与否，及执行先后顺序的状态将会影响2的结果。）

总体上，因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景，正是那句老话：适合的才是最好的

同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一个看似象摸象样的皮囊。

SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持。REST没有任何规范对于安全方面作说明。因此在考虑安全性上，SOAP要高于REST。

ICE：

ICE是分布式应用的一种比较好的解决方案，虽然现在也有一些比较流行的分布式应用解决方案，如微软的.NET（以及原来的DCOM）、CORBA及WEB SERVICE等，但是这些面向对象的中间件都存在一些不足：
.NET是微软产品，只面向WINDOWS系统，而实际的情况是在当前的网络环境下，不同的计算机会运行不同的系统，如LINUX上面就不可能使用.NET；
CORBA虽然在统一标准方面做了很多的工作，但是不同的供应商实现之间还是缺乏互操作性，并且目前还没有一家供应商可以针对所有的异种环境提供所有的实现支持，且CORBA的实现比较复杂，学习及实施的成本都会比较高；
WEB SERVICE最要命的缺点就是他的性能问题，对于要求比较高的行业是很少会考虑WEB SERVICE的。
ICE的产生就是源于.NET、CORBA及WEB SERVICE这些中间件的不足，它可以支持不同的系统，如WINDOWS、LINUX等，也可以支持在多种开发语言上使用，如C++、C、JAVA、RUBY、PYTHON、VB等，服务端可以是上面提到的任何一种语言实现的，客户端也可以根据自己的实际情况选择不同的语言实现，如服务端采用C语言实现，而客户端采用JAVA语言实现，底层的通讯逻辑通过ICE的封装实现，我们只需要关注业务逻辑。

什么是ESB？