面向SOA技术架构资料整理

1. 面向SOA四层服务架构

Service-oriented-enterprice企业服务层 Service oriented Business MetaData Business MetaData …… Service inventory服务清单层 Service inventory Technical MetaDatammTechnical MetaData …… Service composition 组合服务层 service service service …… Service 原子服务层 service service service …… 2. 面向SOA体系架构

查找 服务请求者 服务注册中 心 绑定服务并执行 发布 服务提供者 ? 服务提供者

? 一个可以通过网络寻址的实体，它接受和执行来自使用者的请求 ? 它将自己的服务和接口契约发布到服务注册中心，以便服务使用者

发现和访问该服务

? 服务请求者

? 一个应用程序、一个软件模块或需要服务的另一个服务

? 它发起对注册中心中的服务的查找，通过传输绑定服务，并且执行

服务功能

? 服务使用者根据接口契约来执行服务 ? 服务注册中心

? 服务发现的支持者

? 它包含一个可用服务的存储库，并允许感兴趣的服务使用者查找服

务提供者接口

3. SOA应用体系架构

服务 数据仓库 组件 组件 数据 服务 访问 服务 业务 服务 展示 服务 流程服务 SOA应用系统 企业服务总线ESB 服务 目录 服务库

4. SOA服务体系 信息资源层 数据转换 企业征信 自动流程服务 门户组件 展现服务层 人机交互组件 网页组件 报表组件 流程服务层 人工交互流程 流程引擎 流程监控 业务服务层 环境分析 业务服务 业务服务 数据服务层 数据映射 数据聚合 数据同步 结构化数据 非结构数据 …… …… ? 服务体系各层定义

（一）访问服务层：访问服务层实现与底层数据资源、应用资源的通信功能，使用通用标准接口，定义整合企业信息资源（数据资源与应用资源）的各种访问服务，例如：不同类型的适配器以及专用的API等等。访问服务屏蔽了企业信息资源（现在的或未来的）的技术和实现方式，访问服务层之上的开发者无需知道数据的位置、类型以及应用程序的编程语言等。

（二）数据服务层：数据服务层定义的服务支持把异构的、孤立的企业数据转变成集成的、双向的、可重复使用的信息资源。数据服务通过访问服务层以统一的方式访问企业的所有数据，数据服务层之上的开发者可以集中精力处理数据的加工问题，而不必关注访问不同来源的数据的实现细节。

（三）业务服务层：业务服务层定义那些可重用的业务处理过程，用于支持复合的业务处理需求。这层定义的业务处理过程服务可能是单个原子事务的无状态处理操作服务，也可能是多个业务应用或异步服务之间交互的有状态处理操作服务。业务服务层之上的开发者无需知道具体某项业务的逻辑处理过程。

（四）流程服务层：业务流程是一组服务的集合，服务按照特定的顺序并使用一组特定的规则进行调用，其本身也可视为服务。流程服务层定义有状态的（长期运行或需要人工参与）、完整的业务流程。流程服务通过对下层的数据服务、业务服务的编排来实现，流程编排的规则在该层内定义。

（五）综合服务层：综合服务层以提升企业综合管理职能、优化企业价

值链为出发点，规划跨系统、跨业务管理职能域、跨单位的服务。综合服务层定义的服务是由下层的访问服务、数据服务、业务服务、流程服务组合而成的服务，目的是通过服务的简单编排就可以快速搭建出新的业务应用系统。 （六）展现服务层，展现服务层定义企业信息门户（EIP）中可配置、可重用的门户组件（Portlets），用于支持门户应用的开发；以及人机交互组件、网页组件、报表组件实现对不同客户接入方式的支持，并提供丰富的客户端展现方式

5. 技术标准规范体系图 1、数据服务

XQuery（XML Query）：XQuery是W3C所制定的一套标准，用来从类XML文档中提取信息，类XML文档可以理解成一切符合XML数据模型和接口的实体，他们可能是文件或关系型数据库。

2、业务服务

SCA(Service Component Architecture)：SCA即服务组件架构，它提供了一种编程模型，可以支持基于SOA的应用程序实现。SCA支持实现服务组件的各种技术及连接服务组件的各种存取方法。

EJB(Enterprise JavaBean)：EJB是一个可重用的，可移植的J2EE组件。EJB由封装了业务逻辑的多个方法组成。EJB运行

展现服务（HTML、JSP、AJAX) 消息交互（XML、SOAP） 消息传输（HTTP、JMS） 数据服务(JDBC、Xquery) 安全 管理 (WSDM，SSL/TSL) 服务描述与注册发现(WSDL、UDDI) 流程服务(BPEL、BPMN) 业务服务(EJB、SCA) 在一个容器里，多个远程和本地客户端可以调用这个方法，允许开发者只关注与bean中的业务逻辑而不用考虑事务支持、安全性和远程对象访问等复杂和容易出错的事情。

3、流程服务

BPMN（Business Process Modeling Notation）：BPMN是一个业务流程建模和Web服务标准，其首要目标是提供一个通俗易懂的标注体系，另外一个重要目标是提供内部模型，便于下一代XML语言对业务流程的执行。

BPEL（Business Process Execution Language）：BPEL也被称为BPELWS或BPEL4WS（Web服务业务流程执行语言）。它是一种可执行语言，能够与各种业务流程自动化的软件系统相兼容，通过说明性的方式(而不是编程的方式)表达了进行Web服务合成的需求。此标准主要用于组织内部的业务流程管理及服务编排，BPM产品基于此规范实现。

WS-CDL（Web Services Choreography Definition Language）：WS-CDL 即Web服务编排定义语言，它定义为在多个交易伙伴之间建立形式化关系，它不要求所有被集成的端点(endpoints)都有Web服务基础设施。此规范更多地用于组织之外的服务与流程编排。

4、展现服务

JSR168（Java Specification Request 168）：JSR168是java 规范要求，主要应用在Portal软件的开发。它为创建Portlet建

以使用自定义的 SOAP header传递用户凭证，以便根据每个 Web 服务请求对用户进行身份验证；或者应用程序可以有选择地加密消息的一部分，而不是整个消息。

（四）服务的调用方式可分为：同步调用、异步无返回调用、异步有返回调用。如果业务上要求必须阻塞进程同步等待返回结果，则采用同步调用方式；否则应采用异步调用方式，避免因并发数太多而导致服务调用阻塞。同步调用方式对服务的性能有一定的要求，应避免长时间的等待。 6.3.2 访问服务

（一）访问服务用于提供访问各种数据资源以及套装软件、定制软件和遗留应用系统的手段。访问服务设计原则包括但不限于： 1、访问服务为数据服务提供访问相关系统数据资源的通用功能； 2、访问服务必须是无状态的；

3、访问服务允许转换数据的表示方式，如在XML和非XML格式之间的转换；但不应进行基于业务规则的转换，或者对多个数据源进行操作；

4、访问服务不允许包含业务逻辑； 5、访问服务一般采用异步通信机制。

（二）访问服务必须适应调用者的应用（这些应用可以是基于Java的、非Java的、基于集成开发环境的或基于JDBC/ODBC的），可选的访问机制包括但不限于：

1、Java API访问：允许调用者调用访问服务的读和写函数；

2、控件访问：允许调用者在IDE（集成开发环境）中开发Web应用、门户、工作流和Web服务时使用访问服务控件；

3、Web服务访问：允许访问服务作为Web服务进行发布，以便于被任何使用标准WSDL和SOAP接口的调用者访问；

4、SQL/JDBC访问：通过SQL/JDBC接口，访问服务以关系数据库表的形式被访问，参数化的访问服务以存储过程的形式被访问。 6.3.3 数据服务

（一）数据服务通过调用访问服务访问企业的各种数据资源。 （二）数据服务设计原则包括但不限于：

1、数据访问和业务逻辑处理必须清晰地分离，数据服务通过访问服务从各种数据源收集和返回相关的数据；

2、数据在企业范围内流动与共享，其准确性、一致性、完整性应由数据的生成者保证；

3、数据服务应与南方电网企业信息资源规划定义的数据模型保持一致，使得数据在应用层面具有语义标准化的特性，便于复用；并保证数据使用者与生成者的松耦合，使得数据源模型变化不会影响到数据的使用者；

4、当需要进行大批量的数据复制、移动或转换时，允许将批处理作业的控制操作发布成一个数据服务，而大量数据的批处理操作仍然采用ETL或专用接口等效率更高的方式来实现；

5、当数据服务需要交换大量数据时，允许通过FTP或消息中间件（可提供数据压缩、传输安全、分组传输、缓存等高级功能）以附件的形

式进行交换。 6.3.4 业务服务

（一）业务服务是指满足特定业务处理需求的服务，业务服务包含一个或多个业务处理功能，业务服务包含的业务功能数目决定了业务服务的“粒度”以及可重用性。业务服务的“粒度”大，则服务集成成本低，但业务服务的可重用性也低；业务服务的“粒度”小，则服务集成成本高，但业务服务的可重用性也高。业务服务的“粒度”应该在服务集成成本与服务可重用性之间取得合理的平衡。

（二）业务服务设计要求遵循但不限于下述原则： 1、业务服务操作是非长时间的动作；

2、业务服务表达一定的业务逻辑和业务规则，并具有完整业务事务处理的功能； 3、业务服务安全的认证和授权等控制逻辑必须与业务逻辑分开； 4、事务处理必须在服务内部完成，事务不能跨越服务的边界； 5、业务服务的操作重复执行时其结果是相同的。 （三）业务服务是管理与决策应用功能的基础，业务服务设计应保证业务服务能力的高可用与高性能等质量要求。

（四）业务服务除了满足其所在的业务职能域的业务处理功能外，还应同时考虑便于满足集成跨业务职能域的业务处理功能的需求。 6.3.5 流程服务

（一）流程服务封装完整的业务流程或独立定义的子流程，流程服务设计要求遵循但不限于下述原则：

1、所有需要保存服务调用之前的状态和调用结束之后的状态，并最

终向客户应答的服务，都应该设计为流程服务；

2、流程服务的状态在任何一个时间点都应该是能够监控的； 3、流程服务可以长期处于运行状态，可涉及到人工工作流，并包含多个原子事务； 4、流程服务遵循BPEL，BPMN等规范。 6.3.6 综合服务 综合服务分为两大类：

（一）以提升企业综合管理职能为导向的、基于业务系统的跨系统、跨业务管理职能域、跨单位的组合服务，这类综合服务可由访问服务、数据服务、业务服务及流程服务组合而成。

（二）以企业价值链为导向的、基于数据仓库综合分析功能而封装的跨业务管理职能域、跨时间过程域的服务，这类综合服务一般由各类综合分析模型功能封装而成。 6.3.7 展现服务

（一）展现服务处理应用信息的表示，服务体系所有底层的服务都可以通过展现服务暴露给最终用户使用。

（二）展现服务必须将数据和其表现格式区分开。

（三）展现服务包括：企业信息门户中可配置、可重用的门户组件，用于支持门户应用的开发；以及人机交互组件、网页组件、报表组件等，以实现对不同客户接入方式的支持。

（四）展现服务可以集成商品化的前端展现工具，以满足丰富、灵活的客户端展现需求。 6.4 服务实现

6.4.1 服务封装原则

（一）服务封装是SOA服务实现的手段，服务封装将应用系统可重用的功能或数据“剥离”出来，对外以相关的接口方式以及约束这个接口的契约提供给消费者调用。接口和契约的定义是中立的及基于标准的，并独立于实现服务的硬件平台、操作系统与编程语言。 （二）服务封装必须遵循包括但不限于下述原则：

1、无状态原则：最大限度减少服务管理的状态信息的内容以及状态的期限； 2、单一实例原则：避免功能冗余； 3、接口定义原则：使用WSDL定义服务接口，使用WS-Policy描述服务契约，使用XML模式 （Schema）定义服务交换的消息格式（即服务的公共数据）。服务消费者依赖服务契约调用服务。服务定义必须相对稳定，修改必须通过审核批准；

4、自包含和模块化原则：服务封装的是那些在业务上稳定的、重复出现的活动和组件，组成服务的功能实体是完全独立自主的，可以独立进行部署、版本控制、自管理和恢复；

5、粗粒度原则：服务粒度指抽象级别或者服务包含的功能。确定服务粒度时需要考虑性能需求，以及未来可能进行的更改对服务实现的影响。应尽可能使用粗粒度模式隐藏其中的细粒度服务，这样有利于将服务与其实现的更改隔离开来。服务数量太多会带来服务管理的复杂性；

6、松耦合性原则：服务消费者使用服务接口调用服务，服务的位置、实现技术、当前状态以及服务的私有数据对服务消费者是透明的；

系统的适应性将更强。例如，如果改变用户的身份验证方式，从原有的输入用户名和密码更改为提供一个证书验证，在基于策略的管理模式下，安全性策略与应用程序彼此分离，可以通过声明的方式来描述这种更改，并动态实施。

（七）有状态的服务（例如：流程服务）除了上一点无状态的服务的管理内容以外，还需要结合BPM工具对其过程进行管理，管理内容包括但不限于：

1、图形化业务流程建模。

2、流程的终止、暂停、恢复、事务补偿、回退等。

3、允许与运行中的业务流程交互，以便处理流程异常、审批和状态跟踪。

4、通过图形化界面查看流程服务实例的状态、执行过程、节点信息或用户设定的KPI指标等实时数据。 7.6.2 参考流程

（一）服务的注册流程规范如下：

1、服务提供者向信息部门提出服务注册申请。

2、信息部门对申请进行审批：如果审批通过，服务管理平台的管理员将该服务注册到服务目录；如果审批不通过，向该服务提供者发送申请失败的通知（包括审批意见），并结束流程。

3、服务注册成功后，向服务提供者及潜在的服务消费者发送注册成功通知。

4、服务提供者接收注册成功通知后，根据实际情况，判断是否不需

要订阅申请，而直接对潜在的服务消费者进行授权。

7、可重用原则：服务是可重用的；

8、策略声明原则：应利用策略声明描述对服务的期望，例如：安全性方面的要求、与业务有关的语义方面的要求以及服务级别方面的要求等。

6.4.2 服务封装方式

（一）对于技术实现方式和接口不能满足或难以满足本规范服务定义与服务封装要求的现有应用系统，建议通过适配器对现有应用系统进行集成，利用适配器对外提供的各类接口的方式实现服务封装。 （二）对于采用J2EE或.NET等支持Web服务开发的现有应用系统，可以在不改变现有应用系统的技术实现方式与现有接口的前提下，通过增加对外接口以支持标准的服务接口协议的方式，直接实现现有应用系统功能模块的服务封装。

（三）对于新建的应用系统，必须按本规范的服务定义与服务封装的要求，直接采用支持SOA的开发工具进行服务封装。 7

SOA服务集成 7.1 企业服务总线

（一）ESB提供了一种开放的，基于标准的消息机制，通过标准的适配器和接口，来完成服务之间的互操作。ESB提供了多协议的服务调用接入、服务路由、服务访问控制和服务适配器等核心功能。ESB是服务提供者和服务消费者之间的一个中介，避免了点对点的集成，是实现SOA服务松藕合的重要机制。例如：服务消费者可以不关心服务

提供者的接口（消息格式的不同）、地域（服务部署位置的变化）、调用方式（同步/异步）、传输协议（服务提供者和消费者可以使用不同的通讯协议）、技术实现（编程语言/部署环境）等。ESB功能包括但不限于：

1、服务接入：服务接入是调用服务的统一入口。包括：接收服务请求消息和调用者使用的通信协议与ESB内部通信协议之间转换功能。 2、访问控制：访问控制包括：身份鉴别与权限控制。

3、消息转换：消息转换提供不同格式的消息之间的转换，包括输入消息转换和输出消息转换。 4、服务路由：根据消息的内容和预先配置好的规则，将服务请求传递给某个具体的服务处理。 5、适配转换：负责ESB内部通信协议与被调用的服务使用的通信协议之间的转换，并调用服务，获得服务返回结果。 （二）ESB必须包括但不限于下述特性：

1、与操作系统和编程语言无关；并能在Java和.Net应用程序之间工作； 2、使用XML作为标准通信语言； 3、支持Web服务标准； 4、支持多种传输协议，例如：HTTP(S)、JMS、RMI、FTP或其他消息中间件； 5、支持多种消息传递方式，包括：同步、异步、点对点、发布-订阅等； 6、包含基于标准的适配器，例如：JCA、文件适配器、JDBC适配器等； 7、包含基于内容的智能路由功能； 8、包含标准安全模型，用于ESB的认证、授权和审计；

9、包含消息转换功能,使用可视化映射工具定义XSLT规则，在发送应用和接收应用之间能够进行格式转换、语义转换；

10、包含基于模式（schema）的消息验证；

11、支持服务管理，比如服务的注册、维护、报废和版本管理；监控服务的运行情况，包括时延、吞吐量、错误率等；

12、提供对中文的全面支持，包括对GB2312/GBK/UTF8的完善支持； （三）ESB应具有良好的可扩展性，能够充分利用硬件系统的资源，支持垂直扩展和水平扩展，支持负载均衡，满足日益增长的服务数量的需求。 7.2 服务描述

（一）服务使用WSDL描述其使用的抽象消息操作、具体的网络协议和端点地址。

（二）服务使用XML模式（XML Schema）描述其接收和发送的基于XML的消息的结构和内容。（ 三）服务使用Web服务策略（Web Services Policy）规范来描述Web服务的能力、需求和一般特征，包括但不限于安全性策略。 7.3 服务注册/发布

（一）基于SOA松耦合特性，需要对各种服务进行注册，以方便服务提供者发布自己的服务、服务消费查找所需的服务。

（二）服务注册中心需要提供分类管理能力，实现对服务的搜索。 （三）服务注册应该提供服务审批的功能，保证对敏感注册数据的任何变动都能够传递到适合的审批流程中。同时，还应该提供服务变更管理功能，支持变更的通知和订阅，能够实现将注册数据的变动主动地通知到管理员或者相应的流程。 7.4 服务发现/调用

（一）ESB应具有自动发现服务的功能，ESB中可以通过图形化界面及参数配置的方式调用服务。 （二）Java客户端应用程序中使用UDDI API，以编程方式查找服务目录，并调用服务。 （三）SOA服务应优先采用Web服务方式实现，并符合WS-I国际标准。 （四）服务间互操作的协议为简单对象访问协议（SOAP）。 （五）服务间数据交换的格式为可扩展标记语言(XML)。 7.5 服务编排

（一）复杂的服务需要通过若干个简单的服务组合而成，这时候就需要对服务进行编排。

（二）轻量级服务编排在ESB中完成，通过ESB的服务路由、消息格式转换功能，实现多个服务组合成一个更粗粒度的服务。 （三）需要长期运行的业务流程，可利用BPM工具进行服务编排。 7.6 服务管理 7.6.1 管理内容

（一）SOA服务管理贯穿于服务的全生命周期，包括：服务需求分析、服务识别、服务定义、服务设计、服务实现、服务测试、服务部署、服务使用、服务运维、服务退役等。

（二）SOA服务管理包括：服务资产管理、服务运行监控、版本管理、服务动态更新、服务质量管理、服务水平管理、安全管理等，通常通过规则配置来应用管理功能。

（三）SOA服务管理应按照服务体系的层次划分进行分类管理。 （四）服务的资产管理由服务库完成；服务库存储服务全生命周期过程的详细元数据，包括：服务的定义、服务的依赖关系、服务的文档、

实现代码、服务的权限信息、服务运行质量控制信息以及服务的治理规则和策略等。

（五）服务目录存储服务运行时所关注的元数据，是服务库存储的元数据的一个子集；主要用于服务部署时的服务注册、发现和查找，以及提供变更通知功能。

（六）无状态的服务（例如：数据服务、业务服务）通过ESB和服务目录对其进行运维管理，管理内容包括但不限于：

1、服务监控：提供对服务运行指标的监控，包括服务节点的吞吐量和可用性等，以图形化的方式来评估服务相关性和中断造成的影响。监控指标包括但不限于：最小响应时间、最大响应时间、平均执行时间、处理的总消息数和错误数、成功/错误率、违反安全的消息数、校验错误的消息数等。

2、服务水平管理：通过设置服务水平协议（SLA）提示，向服务运行管理团队通知服务运行的状况，或提供与服务质量有关的问题报告等。触发提示时，服务管理平台能按预先制定的策略通知服务运行管理团队的管理人员（通过电子邮件或短信息等）。

3、服务自动发现：通过自动发现实际运行的服务或查找新部署的服务，减少配置管理中的人工操作，还可以通过发现其它隐藏或恶意的服务来应用更加严格的监管策略。

4、服务异常管理：跟踪、检测分布式或异构系统间服务的消息流异常情况。

5、服务策略实施：通过将系统的行为作为策略指定(而非过程代码)，

本文来源：https://www.bwwdw.com/article/s5nd.html