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. 非结构化业务数据维护、编目及查询；

　　6. 应用资源类维护、编目及查询。

　　完成上述过程的梳理和资源分类只是一个起点，还要利用 SOA 理念，将梳理的结果以

服务的形式体现出来，才能最终为业务应用提供最直接的帮助。事实上，梳理的过程和基

于梳理结果建立服务的过程也就是搭建政务应用基础设施的过程，有了基础设施就有了业

务应用的完整地图，业务流、数据流就可以按照指定的方式运行。

　　资源共享应用模式

　　从软基础设施的角度对电子政务领域的信息资源目录进行了梳理，建立了以组织架构

职责、业务活动、业务对象、业务流程为内容的目录体系，并基于这个目录体系形成了服

务体系，就可以依据这些软基础设施进一步构建具体的资源和服务。这些资源可以通过服

务的模式对外共享，任何需要这些资源的机构和个人都能拿到所需要的资源。

　　资源的有效共享依赖于三个方面：一个是资源本身的描述，另一个是资源本身的实际

存储方式，最后是资源的提供方式。

　　资源本身的描述和逻辑集中有赖于基于元数据的资源描述，逻辑集中就是将资源的描

述以目录的形式进行统一存储；资源的物理存储方式依赖应用构建前期对数据的规划，此

层的变动只会影响资源的物理层面特性，并不影响其服务的特性，因此原有的对应用层限

制最大的数据层，通过目录的统一服务变得非常灵活而有弹性；最后，资源的提供方式则

是基于前两个方面的服务方案，资源共享以服务的形式体现。

业务协同应用模式

　　不同机构的业务办理都有可能依赖于其他业务，而业务本身的办理又通常需要资源的

支撑，资源本身的负责方或许是本单位，也可能是其他单位，信息资源的共享应用模式解

决了第二个问题，而第一个问题也通过对业务的梳理为业务协同建立了完整的指导。如何

实现这些业务的协同是 SOA 在这种应用模式下的重点。在这种应用模式下，完成业务协同

包括三个步骤：

　　第一步：业务处理服务

业务处理服务源于对组织内或组织间业务活动的分析，组织内的业务处理服务可以直

接基于业务活动抽象的用例来构造；组织间的业务活动一部分来自于业务活动的分析，另

一部分来自于资源共享的需求，近而依据这部分需求建立起共享的服务。

　　第二步：业务流程服务

业务流程服务源于组织内各部门间或组织间的业务关系的分析，通过建立业务的前置

关系、后置关系从而形成业务流程，依据业务活动间的关系建立起对外提供的业务服务。

　　第三步：服务查询检索

　　服务查询检索主要是供外部用户明确了解组织提供了哪些服务、具体的服务内容是什

么以及如何获取和使用这些服务。

　　服务查询检索依据信息资源目录，信息资源目录清晰梳理了客户的业务，但如何提供

这些业务，则需要通过服务去实现。通过服务定义和服务描述，建立了关于服务的完整描

述，使用者可以基于这些描述的任一方面对服务进行检索。

最后通过服务检索查询的功能开发定义明确的交互界面，用户可以通过交互界面查询

定位所需的服务。

　　不同服务渠道的应用模式

　　服务的灵活性和可扩展性是 SOA 的主要特性之一，电子政务的一个重要特性是强调服

务，因此整合不同服务渠道也是重点之一。

　　SOA 在应用与业务之间加入一个服务层，解决了原有的系统建设通常不会建立服务层

完成系统间的调用，而是直接调用下层其他应用或者采用数据共享的方式，从而避免直接

访问下层其他应用。另外，在大多数机构中，存在不同的应用和技术共存，由于这些应用

提供的功能都是特定的，要在应用间共享信息最好的解决方案是转向一种面向服务的架构

of 5

免费下载

软考

相关文档

评论