老于乐
0%

SOA、SOAP、REST

更新于
SOA, SOAP, REST

SOA: Service-oriented Architecture

基本定义：
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
在一个企业内部，SOA服务通过一个扮演目录列表（directory listing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， Universal Description， Definition， and Integration）是服务登记的标准。
每项SOA服务都有一个与之相关的服务品质（QoS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。

要点：

  • 是一种软件系统架构的思想
  • 将面向对象的概念进一步抽象，提升为面向服务
  • 是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。
  • 可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。
  • SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）
  • 通过使用基于XML（标准通用标记语言的子集） 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口
  • 一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。

特性：

  • 可从企业外部访问
  • 平台无关
  • 随时可用
  • 粗粒度的服务接口分级
  • 松散耦合：
  • 可重用的服务
  • 服务接口设计管理
  • 标准化的服务接口
  • 支持各种消息模式
  • 精确定义的服务契约

应用价值：

  • SOA可通过互联网服务器发布，从而突破企业内网的限制，实现与供应链上下游伙伴业务的紧密结合。通过SOA架构，企业可以与其业务伙伴直接建立新渠道，建立新伙伴的成本得以降低。
  • 业务伙伴对整个业务系统的影响较低。在企业与各业务伙伴关系不断发生变化的情况下，节省的费用会越来越多。
  • SOA与平台无关，减少了业务应用实现的限制。要将企业的业务伙伴整合到企业的“大”业务系统中，对其业务伙伴具体采用什么技术没有限制。
  • SOA具有可按模块分阶段进行实施的优势。可以成功一步再做下一步，将实施对企业的冲击减少到最小。
  • SOA的实施可能并不具有成本显著性。这要分三种情况加以讨论：
    • 当企业从零开始构建业务系统时，采用SOA架构与不采用SOA架构成本可看做是相同的。
    • 当企业业务发展或发生企业重组等变化而原有系统不能满足需要，而需要重构业务系统时，采用SOA架构与不采用SOA架构成本可看做是相同的。
    • 当企业业务发生缓慢变化并可预见到将来需要重构业务系统时，由于可以按模块分阶段逐步实施SOA以适应变化的需要，这样企业不需一下投入一大笔经费进行系统改造，而是根据企业业务发展情况和资金情况逐步投入，缓解了信息投入的压力。

发展效益

  1. 平衡最初的旧系统投资(Leverage initial investment)：组织过去所投资的系统、软硬体，如果能再利用等于赋予其新的价值，这也替组织降低成本并增加竞争力。
  2. 基础建设的便利性(Infrastructure Commoditization)：让所有的应用程式能相互沟通(互通性)。
  3. 快速的接近市场(Faster time-to-market)：服务的重复使用(再利用)，来缩短过去的组织流程，更快速的提供服务来接近市场。
  4. 减少支出(Reduce Cost)：服务的重复使用，可降低开发成本。因为开发新系统的成本，大部份比更新旧有系统来的花费大。
  5. 减低风险(Risk mitigation)：开发新系统的风险远大于更新旧系统。
  6. 持续改善商业流程的循环(Continuous improvement cycle for business process)
  7. 中心流程处理(Process-centric processing)

内容摘抄自：百度百科词条SOA

SOAP：Simple Object Access Protocol

基本定义：
简单对象访问协议(SOAP)是交换数据的一种协议规范，是一种轻量的、简单的、基于XML（标准通用标记语言下的一个子集）的协议，它被设计成在WEB上交换结构化的和固化的信息。

要点：

  • 是Web Service三要素之一。（Web Service三要素：SOAP、WSDL(Web Services Description Language)、UDDI(Universal Description Discovery and Integration)之一， SOAP用来描述传递信息的格式， WSDL 用来描述如何访问具体的接口， UDDI用来管理，分发，查询Web Service 。）
  • SOAP使用基于XML的数据结构和超文本传输协议(HTTP)的组合定义了一个标准的方法来使用Internet上各种不同操作环境中的分布式对象。
  • 基于类对象的传输协议。
  • SOAP封装（envelop），它定义了一个框架，描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们；
  • SOAP编码规则（encoding rules），它定义了一种序列化机制，用于表示应用程序需要使用的数据类型的实例；
  • SOAP RPC表示（RPC representation），它定了一个协定，用于表示远程过程调用和应答；
  • SOAP绑定（binding），它定义了SOAP使用哪种协议交换信息。使用HTTP/TCP/UDP协议都可以。
  • SOAP消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求 / 应答的模式。所有的 SOAP消息都使用 XML 编码。
  • 一条 SOAP消息就是一个包含有一个必需的 SOAP 的封装包，一个可选的 SOAP 标头和一个必需的 SOAP 体块的 XML 文档。
  • 把 SOAP 绑定到 HTTP 提供了同时利用 SOAP 的样式和分散的灵活性的特点以及 HTTP 的丰富的特征库的优点。
  • 在 RPC 上使用 SOAP 并不仅限于 HTTP 协议绑定。SOAP也可以绑定到TCP和UDP协议上。

语法规则:

  • 构建模块: 一条 SOAP 消息就是一个普通的 XML 文档，包含下列元素：
    • 必需的 Envelope 元素，可把此 XML 文档标识为一条 SOAP 消息
    • 可选的 Header 元素，包含头部信息
    • 必需的 Body 元素，包含所有的调用和响应信息
    • 可选的 Fault 元素，提供有关在处理此消息所发生错误的信息
  • 语法规则
    • SOAP 消息必须用 XML 来编码
    • SOAP 消息必须使用 SOAP Envelope 命名空间
    • SOAP 消息必须使用 SOAP Encoding 命名空间
    • SOAP 消息不能包含 DTD 引用
    • SOAP 消息不能包含 XML 处理指令
  • 消息基本结构 
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    <?xml
    　version="1.0"?>
    <soap:Envelope
    　xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
    　soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

    <soap:Header>
    <!--百度百科示例-->
    </soap:Header>
    <soap:Body>
    <!--百度百科示例-->
    <soap:Fault>
    <!--百度百科示例-->
    </soap:Fault>
    </soap:Body>
    </soap:Envelope>

优点：

  • 可扩展的。SOAP 无需中断已有的应用程序, SOAP 客户端、 服务器和协议自身都能发展。而且SOAP 能极好地支持中间介质和层次化的体系结构。
  • 简单的。客户端发送一个请求,调用相应的对象, 然后服务器返回结果。这些消息是XML 格式的,并且封装成符合HTTP 协议的消息。因此,它符合任何路由器、 防火墙或代理服务器的要求。
  • 完全和厂商无关。SOAP可以相对于平台、 操作系统、 目标模型和编程语言独立实现。另外,传输和语言绑定以及数据编码的参数选择都是由具体的实现决定的。
  • 与编程语言无关。SOAP 可以使用任何语言来完成，只要客户端发送正确SOAP 请求( 也就是说, 传递一个合适的参数给一个实际的远端服务器)。SOAP 没有对象模型,应用程序可以捆绑在任何对象模型中。
  • 与平台无关。SOAP 可以在任何操作系统中无需改动正常运行。

内容摘抄自：百度百科词条简单对象访问协议

REST：Representational State Transfer

基本定义：
表述性状态传递（英文：Representational State Transfer，简称REST）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。它是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTful。
目前在三种主流的Web服务实现方案中，因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的web服务开始采用REST风格设计和实现。

基本设计原则：

  • 显式地使用 HTTP 方法。见http方法。
    • 若要在服务器上创建资源，应该使用 POST 方法。
    • 若要检索某个资源，应该使用 GET 方法。
    • 若要更改资源状态或对其进行更新，应该使用 PUT 方法。
    • 若要删除某个资源，应该使用 DELETE 方法。
  • 无状态。
    完整、独立的请求不要求服务器在处理请求时检索任何类型的应用程序上下文或状态。
    REST Web 服务应用程序（或客户端）在 HTTP Header 和请求正文中包括服务器端组件生成响应所需要的所有参数、上下文和数据。
    这种意义上的无状态可以改进 Web 服务性能，并简化服务器端组件的设计和实现，因为服务器上没有状态，从而消除了与外部应用程序同步会话数据的需要。
  • 公开目录结构式的 URI。
    在考虑基于 REST 的 Web 服务的 URI 结构时，需要指出的一些附加指导原则包括：
    • 隐藏服务器端脚本技术文件扩展名（.jsp、.php、.asp）——如果有的话，以便您能够移植到其他脚本技术而不用更改 URI。
    • 将所有内容保持小写。
    • 将空格替换为连字符或下划线（其中一种或另一种）。
    • 尽可能多地避免查询字符串。
    • 如果请求 URI 用于部分路径，与使用 404 Not Found 代码不同，应该始终提供缺省页面或资源作为响应。
  • 传输 XML、JavaScript Object Notation (JSON)，或同时传输这两者。

要点：

  • REST是设计风格而不是标准。
  • REST通常基于使用HTTP，URI，和XML（标准通用标记语言下的一个子集）以及HTML（标准通用标记语言下的一个应用）这些现有的广泛流行的协议和标准。
  • REST 定义了一组体系架构原则，您可以根据这些原则设计以系统资源为中心的 Web 服务，包括使用不同语言编写的客户端如何通过 HTTP 处理和传输资源状态。
  • 事实上，REST 对 Web 的影响非常大，由于其使用相当方便，已经普遍地取代了基于 SOAP 和 WSDL 的接口设计。

HTTP方法：
由于所有资源使用了同样的接口，你可以依此使用GET方法检索一个表述（representation）——也就是对资源的描述。因为规范中定义了GET的语义，所以可以肯定当你调用它的时候不需要对后果负责——这就是为什么可以“安全”地调用此方法。
GET方法支持非常高效、成熟的缓存，所以在很多情况下，你甚至不需要向服务器发送请求。还可以肯定的是，GET方法具有幂等性[译注：指多个相同请求返回相同的结果]——如果你发送了一个GET请求没有得到结果，你可能不知道原因是请求未能到达目的地，还是响应在反馈的途中丢失了。幂等性保证了你可以简单地再发送一次请求解决问题。
幂等性同样适用于PUT（基本的含义是“更新资源数据，如果资源不存在的话，则根据此URI创建一个新的资源”）和DELETE（你完全可以一遍又一遍地操作它，直到得出结论——删除不存在的东西没有任何问题）方法。
POST方法，通常表示“创建一个新资源”，也能被用于调用任意过程，因而它既不安全也不具有幂等性。

内容摘抄自百度百科rest词条及IBM开发者网站文章《基于 REST 的 Web 服务：基础》