SOA架构十大设计原则服务共享和约架构.docx

张欣

5页

2次

2024-07-12

免费下载

SOA 架构十大设计原则服务共享和约架构

日前国外网站报道介绍了面向服务架构(SOA)的基本原则，提出了公共接口与内部实现

要有明确界限等原则。虽然这些原则并不是绝对的真理，但可作为一个应用开发参考。

　　一、明确的边界

通过跨越定义明确的边界进行显式消息传递，服务得以彼此交互。有时候，跨越服务

边界可能要耗费很大的成本，这要视地理、信任或执行因素而定。边界是指服务的公共接

口与其内部专用实现之间的界线。服务的边界通过 WSDL 发布，可能包括说明特定服务之

期望的声明。

　　二、服务共享和约和架构

服务交互应当只以服务的策略、架构和基于合约的行为为基础。服务的合约通常使用

WSDL 定义，而服务聚合的合约则可以使用 BPEL 定义(进而，对聚合的每个服务使用

WSDL)。服务使用者将依靠服务的合约来调用服务及与服务交互。鉴于这种依赖性，服务

合约必须长期保持稳定。在利用 XML 架构 (xsd:any) 和 SOAP 处理模型(可选标头)的可扩展

性的同时，合约的设计应尽可能明确。

　　三、策略驱动

尽管它往往被认为是最不为人所了解的原则，但对于实现灵活的 Web 服务，它或许是

最有力的。单纯依靠 WSDL 无法交流某些业务交互要求。可以使用策略表达式将结构兼容

性(交流的内容)与语义兼容性(如何交流消息或者将消息交流给谁)分隔开来。

　　四、自治

服务是独立进行部署、版本控制和管理的实体。开发人员应避免对服务边界之间的空

间进行假设，因为此空间比边界本身更容易改变。

五、采用可传输的协议格式，而不是 API

通常,服务提供商基于某种传输协议(例如 HTTP)提供服务,而服务消费者只能通过另一种

不同的协议(比如 MQ)通信。因此，也许需要在服务提供商与消费者之间建立一座异步起动

同步运行的连接桥梁,超越 HTTP 和 Java Messaging Service 消息服务(JMS)等协议.从技术角度

讲，Java Messaging Service 消息服务(JMS)并不是一种传输协议,而是一组供应商中立(vendor-

neutral)的通信 APIs。

　　六、面向文档

消息被构造为“纯文本的”XML 文档(换句话说，数据的格式只对 XML 有意义)。消息通

常用于传输业务文档，比如购买订单、发票和提单。这种交互类型与同步消息排队系统的

兼容性很好，比如 MQ Series、MSMQ、JMS、TIBCO、IMS 等等。

　　七、松耦合

服务之间要求最小的依赖性，只要求它们之间能够相互知晓。

　　八、符合标准

当通过 Web 的服务实现时，最原始的(基本的)面向服务的架构(SOA)的模型仅仅提供了

很低程度上的关于可靠性、安全性以及事务管理的标准化机制。第二代的技术条件和框架

如 WS-ReliableMessaging 规范、 WS-Security 规范和 WS-Coordina+on 规范 ( 与 WS-

AtomicTransac+on 规范和 WS-BusinessAc+vity 规范相联系)，它们试图以工业标准的方式定

位存在的缺陷。

　　九、独立软件供应商

向 SOA 的转变正在深刻改变了经济现实。客户们会期待更合理的费用以及不必重新进

行投资就能改进业务的能力。因此，独立软件供应商没有选择，只能使自己的业务更加灵

活，以期让自己的客户也变得同样灵活。于是，面向服务不仅是简单的在现有的、紧耦合

的、复杂的、不灵活的以及非组件化的业务功能上添加基于标准的接口。更重要的是，为

了兑现 SOA 的承诺，独立软件供应商必须改变他们构建、打包、销售、交付、管理和支持

自身产品的方式。

　　十、元数据驱动

开发元数据本身并不是元数据驱动应用程序的本意。使用元数据来驱动服务在系统边

界的传播是一个更为正确的方法。

SOA 架构理念企业应用 SOA 最常见的 5 种模式

　　随着 SOA 技术的不断完善，SOA 理念与技术实践开始日趋深入。从国内整体市场看，

越来越多的政府机构和企业已经跨过了对 SOA 的价值及重要性的认知阶段，开始从概念普

及、局部尝试准备进入到大规模应用阶段。但是，如何基于国内的 SOA 需求环境让 SOA 真

正落地，如何在各行业构建满足 SOA 特征的应用成为目前我国软件企业与服务提供商面临

的一大难题。

笔者认为，只有 SOA 的应用模式被深刻理解，SOA 应用工作才会有据可依，大力推进

SOA 在中国的成功应用才会有坚实的基础。本文基于国内各行业的实际业务类型，重点研

究了 SOA 的应用模式，并按照不同的侧面对此进行了总结。

　　SOA 作为软基础设施

　　从软基础设施的角度，SOA 的应用可以分为利用信息资源目录梳理业务活动和业务对

象的应用模式，以及建立业务主题库的应用模式两类。利用信息资源目录梳理业务活动和

业务对象的应用模式用于梳理业务以支撑基于 SOA 的应用；建立业务主题库框架的应用模

式则主要是阐述如何建立业务领域的主题库，基于这种应用模式可以建立多层次、分布式

应用系统的基础库。

　　信息资源梳理的目的在于方便部门间的资源共享和业务协同，因此宜将政务部门的组

织结构、部门职责作为梳理的起点，把各部门的业务活动作为信息资源梳理的脉络，把业

务对象和业务流程作为信息资源的关键点，把业务活动之间的关系作为寻找和判断信息资

源如何共享和协同的依据。

　　对于政务部门，信息资源主要包括基础信息、结构化业务数据、非结构化业务数据和

应用资源等。此分类只是资源的外在表现形式，而如何利用这些资源形成完整的服务则是

一项需要研究的内容。通过分析可以建立起相对完善的资源梳理和服务目录，完成以下工

作：

1. 业务活动梳理、编目及查询；

2. 业务活动之间的关系梳理、编目及查询；

3. 基础信息维护、编目及查询；

4. 结构化业务数据维护、编目及查询；

5. 非结构化业务数据维护、编目及查询；