面向服务的体系结构

面向服务的体系结构(英语:service-oriented architecture)并不特指一种技术,而是一种分布式运算的软件设计方法。软件的部分组件(调用者),可以透过网络上的通用协议调用另一个应用软件组件执行、运作,让调用者获得服务。SOA原则上采用开放标准、与软件资源进行交互并采用表示的标准方式。因此应能跨越厂商、产品与技术。一项服务应视为一个独立的功能单元,可以远程存取并独立执行与更新,例如在线查询信用卡账单。

SOA中的一项服务应有以下四个特性:

  1. 针对某特定要求的输出,该服务就是运作一项商业逻辑
  2. 具有完备的特性(self-contained)
  3. 消费者并不需要了解此服务的运作过程
  4. 可能由底层其他服务组成

SOA是什么 编辑

企业系统的架构师认为SOA能够帮助业务迅速和高效地响应变化的市场条件[1]。服务导向的架构在宏观(服务)上,而不是在微观上(对象),因此提高了重复使用性。同时,服务导向的架构可以简化与传统系统的互连和使用。

在某种意义上说,服务导向的架构可以被认为是一种演化,而不是革命。它捕捉到了之前体系架构的许多最佳实践或实际应用。比如在通信系统中,近年来进展有限的解决方案多采用完全静态的绑定来与网络中的其他装置沟通,但若正式采用SOA方式,解决方案就更能妥善定位,进而突显定义明确且可高度跨平台操作接口的重要性。[2]

有些人质疑服务导向的架构是不是1970年代模块化编程,1980年代的面向事件设计,1990年代的基于接口/构件设计的一种复兴?(1990s)[来源请求]。 服务导向的架构提升了将用户从服务实现分开的目标。服务可以运行在不同的伺服器上,并通过网络被访问。 这也大大增加了服务的重用[来源请求]

SOA的原则 编辑

以下指导原则是开发,维护和使用SOA的基本原则[3]

  • 可重复使用、粒度模块性、可组合型、物件化原件、构件化以及具交互操作性
  • 符合开放标准(通用的或行业的)
  • 服务的识别和分类,提供和发布,监控和跟踪。

下面是一些特定的体系架构原则:

  • 服务封装
  • 服务松耦合(Loosely Coupled) - 服务之间的关系最小化,只是互相知道。
  • 服务契约 - 服务按照服务描述文档所定义的服务契约行事。
  • 服务抽象 - 除了服务契约中所描述的内容,服务将对外部隐藏逻辑。
  • 服务的重用性 - 将逻辑分布在不同的服务中,以提高服务的重用性。
  • 服务的可组合性 - 一组服务可以协调工作并组合起来形成一个组合服务。
  • 服务自治 – 服务对所封装的逻辑具有控制权
  • 服务无状态 – 服务将一个活动所需保存的资讯最小化。
  • 服务的可被发现性 – 服务需要对外部提供描述资讯,这样可以通过现有的发现机制发现并访问这些服务。[4]

除此以外,在定义一个SOA实现时,还需要考虑以下因素:

  • 生命周期管理
  • 有效使用系统资源
  • 服务成熟度和性能

服务导向的架构和Web服务协议 编辑

服务导向的架构通常被定义为通过Web服务协议栈暴露的服务[来源请求]。与SOA相关的Web服务的标准主要有:

  • XML - 一种标记语言,用于以文档格式描述消息中的数据。
  • HTTP(或HTTPS) - 客户端和服务端之间用于传送资讯而发送请求/回复的协议。
  • SOAP(Simple Object Access Protocol) - 在电脑网络上交换基于XML的消息的协议,通常是用HTTP。
  • WSDL(Web Services Description Language,Web服务描述语言) - 基于XML的描述语言,用于描述与服务交互所需的服务的公共接口,协议绑定,消息格式。
  • UDDI(Universal Description, Discovery, and Integration,是统一描述、发现和集成) - 基于XML的注册协议,用于发布WSDL并允许第三方发现这些服务。

注意,一个系统要成为服务导向的系统并不需要这些协议,比如一些服务导向的系统可以通过CORBA实现。

参考文献 编辑

外部链接 编辑

参见 编辑