工作流管理系统-软件架构设计

分类：
软件研发业务流程技术工作流2008-05-20 08:57611人阅读评论(0)收藏举报
工作架构设计工作流引擎数据库web服务webservice

目录(?)[+]

编写目的
项目背景
定义
参考资料

工作流管理系统

软件架构设计
chenzhenshuang@2911.net
陈振双

目录

软件架构设计....
1

1.引言....
4

1.1编写目的...
4

1.2项目背景...
4

1.3 定义...
4

1.4 参考资料...
5

2.需求概述....
6

2.1总体描述....
6

2.1.1概述....
6

2.1.2新系统目标....
6

2.1.3系统结构设计要求....
7

2.2功能需求概述....
7

2.2.1系统组成....
7

2.2.2工作流总调度子系统....
8

2.2.3工作流调度子系统....
9

2.2.4工作流机子系统....
10

2.2.5流程监控子系统....
10

2.2.6流程定义子系统....
11

2.2.7客户端UI子系统....
11

2.3环境要求概述....
11

2.4安全性能要求概述....
12

2.5性能要求概述....
13

3.系统处理流程设计....
14

3.1总体流程处理设计....
14

3.1.1业务流程设计....
14

3.2子流程或分支流程设计....
15

3.2.1客户端操作子流程....
15

3.2.2总调度子流程....
16

3.2.3调度子流程....
17

3.2.4执行机子流程....
18

3.2.5监控子流程....
20

3.2.6附件上下传子流程....
21

4.技术方案设计....
22

4.1系统总体技术方案设计....
22

4.1.1系统体系结构设计....
22

4.1.2重点技术的分析，采用和设计....
23

4.2系统功能结构设计....
29

4.2.1UI子系统功能结构....
29

4.2.2总调度子系统功能结构....
32

4.2.3调度子系统功能结构....
34

4.2.4工作流机子系统功能结构....
36

4.2.5监控子系统功能结构....
39

5.数据结构设计....
41

5.1逻辑结构设计....
41

6.接口设计....
44

6.1外部接口....
44

6.1.1扩展接口....
44

6.1.2二次开发接口....
45

6.2内部接口....
45

7.容错性设计....
47

7.1Web服务端容错性....
47

7.2工作流调度端及工作流机的容错性....
48

7.3数据库系统的容错性....
48

7.4后台服务的容错性....
49

8.安全性设计....
51

8.1HTTP传输层的安全性....
51

8.2用户密码的安全性....
51

8.3对于数字签名及电子公章的支持....
52

8.4其他的安全性设计....
52

概要设计说明书
1.
引言

1.1编写目的

本文的主要目的是在前期需求分析的基础上，进行系统的概要设计，并为随后进行的详细设计建立基本的框架。

在需求分析文档的基础上，实现所有需求功能点的概要设计并且使得详细设计人员可以在这一基础上进行明确的详细设计开发工作。

本文的主要阅读对象为需求分析人员（审核与校对），以及进一步进行详细设计的设计人员。

1.2项目背景

系统名称：《工作流管理系统》

该系统作为一个企业协作软件产品，可先在集团公司内部使用，待产品完善和成熟后，有计划地推向企业应用市场。

1.3 定义

WfMS: Workflow Management Systems 工作流管理系统

WFMC：Workflow Management Coalition 工作流管理联盟

1.4 参考资料

WFMC工作流参考模型：WFMC-TC00-1003

WFMC接口1：WFMC-TC-1025

工作流管理技术基础(范玉顺)

WFMC其他系列文档

各子系统的需求文档及分析文档

2.
需求概述

2.1
总体描述

2.1.1
概述

本章节将描述系统的各个子系统的初步划分及对应的功能。

本系统的主要功能结构如下图:

2.1.2
新系统目标

本项目的主要目标是设计并完成一个通用的工作流管理系统，本系统能够支持各种现有的工作流需求，包括自动工作流，人工工作流，以及针对企业应用集成的集成工作流。同时，本系统应该能够提供完善的流程监控子系统，完全图形化的流程设计客户端及基于BS构架的客户端UI。

统一规划，统一设计，统一信息交换接口。采用中性化的设计方案，可以应对各种物理平台。应用成熟的先进技术实施系统。

2.1.3
系统结构设计要求

本系统的系统结构将是一个多层次的分布式应用系统，各个子系统之间采用松耦合，基于通用与统一的接口进行信息交换。系统要求具有良好的伸缩性，可以完全支持负载均衡，同时，概要设计将要求保持中性化，可以在不同的物理平台上实现。

2.2
功能需求概述

2.2.1
系统组成

整个系统的结构图如下所示：

、

2.2.2
工作流总调度子系统

本子系统的主要任务是接收来自UI子系统和工作流监控子系统对于工作流的操作与调度，并根据一定的调度算法分发给具体的工作流引擎负责处理。

2.2.3
工作流调度子系统

本子系统的主要任务是接收来自工作流总调度的指派命令，并按照一定的调度算法，分发给具体的工作流机做处理。

2.2.4
工作流机子系统

本子系统的主要任务是接收来自工作流调度的指派命令，并且具体的解析该命令并执行相应的操作，并将结果在数据库内进行更新，以驱动流程实例的流转。

2.2.5
流程监控子系统

本子系统的主要任务是随时监视各个工作流引擎及内部工作流机的运行状况，并随时根据监控人员的指令向以上子系统发出具有高优先级的流程流转命令，以改变流程的正常运行。

2.2.6
流程定义子系统

本子系统的主要任务是利用图形化的拖拉方式，使得用户可以非常容易的进行工作流的定义，修改和发布工作。

2.2.7
客户端UI子系统

本子系统的主要任务是负责整个系统与普通用户的交互，展示流程实例信息，并将用户的操作请求发送到工作流总调度，进行处理。

2.3
环境要求概述

本系统的所有子系统运行于X86平台上，从概要设计层次上将同时支持.NET与J2EE系统。

网络环境

主要环境为局域网

客户应用可以是广域网

TCP/IP工业协议

硬件环境

服务器：

CPU P4 2GHZ以上，内存≥4024M，硬盘≥60G 负载均衡

WEB服务器：

CPU P4 2GHZ以上，内存≥4024M，硬盘≥60G 负载均衡

客户机：

CPU PIII 500MHZ以上，内存≥128M，硬盘≥10G

软件环境

域服务器：

Windows 2000 [Advanced ]Server 以上

其他支持LADP的服务环境

WEB服务器：

Windows 2000 [Advanced ]Server IIS 5.0以上

MS.NET FrameWork 1.1以上

支持WebService等的Java Web容器。

Java JDK 1.4以上

数据库服务器

SQL Server 2000 SQL Server SP3以上

Oracle 8i以上

邮件服务器

MS Exchange 2000以上或其他邮件系统

客户机

Windows 98以上

Microsoft Internet Explore 6.0以上

2.4
安全性能要求概述

由于各个流程实例之中可能含有大量的机密数据，本系统要求较高的安全性能指标，系统操作的各个阶段都要求能够进行加密，同时系统应能够支持各种加密方式，包括RSA, Tripple DES等，还应支持包括电子签名，加密设备等。

2.5
性能要求概述

系统要求具有较强的伸缩性，在机器数量能够满足的情况下能够同时支持万人以上的用户及千人规模的并发量。

3.
系统处理流程设计

3.1
总体流程处理设计

3.1.1
业务流程设计

系统的整体运行流程如下图所示：

触发条件：流程的触发条件包含多种。对于人工工作流（基于状态的工作流）来说，人工输入的信息是触发流程流转的主要触发条件；对于自动或者集成工作流来说（基于顺序的工作流），触发流程流转的条件非常的多，包括客户端文件上传，邮件更新，手工启动等多个。

XML的操作包：为实现系统最大范围的通用性和跨平台性，系统将采用XML作为标准的信息传输格式，所有进一步的需求如加密，压缩等，将在XML的基础上进行。

工作流总调度：工作流总调度应采用开放接口的调度算法，以便系统随时可以按需求更新调度算法。

工作流执行机：工作流执行机在执行系统的请求时，将区分对待基于顺序的工作流和基于状态的工作流，对于基于顺序的工作流工作流执行机将执行直道流程结束，对于基于状态的工作流，执行机将只执行一次状态的改变。

3.2
子流程或分支流程设计

3.2.1
客户端操作子流程

用户信息在输入之后，首先将检查信息输入的合法性，在确认之后，将接受用户信息的输入，为此，对该流程实例置处理标志位，以便锁定该流程实例在处理期间不接受任何其他的用户信息输入。用户信息将按照系统的标准转化为标准的XML数据，并将发送到某一总调度。总调度的列表应存在于配置文件中。

3.2.2
总调度子流程

总调度子流程接受来自客户端或监控系统的处理请求，并根据具体的算法和工作流引擎的运行情况将任务分配到具体的工作流引擎实例，在分配的过程中，总调度将会在XML处理信息内加上路由信息，以标示该信息的具体路由路径。

3.2.3
调度子流程

调度子流程接受来自总调度的处理请求，并根据具体的算法和工作流机的运行情况将任务分配到具体的工作流机实例，在分配的过程中，调度将会在XML处理信息内加上路由信息，以标示该信息的具体路由路径。

3.2.4
执行机子流程

消息进入工作流机后，将首先进行合法性检查，在所有的检查通过后，解析该XML消息，并调用对应的流程定义模块，读取流程定义信息，按照客户端的要求驱动流程运行并将结果保存到数据库内，在运行过程中，所有的附加脚本和组件也将被一一运行。在所有的流程动作结束后，将取消之前所设的流程操作标志位，以便该流程可以继续接受来自客户端的消息，以驱动流程的进一步运转。对于基于顺序的流程而言，工作流机将持续运行，直到流程结束。

3.2.5
监控子流程

对于监控而言，主要包含两个子流程，一是信息收集和展现，监控将收集来自工作流总调度和引擎的处理信息，并实时的记录到自身的数据库中，以备查询。

另一个子流程是监控端的控制，来自监控端的信息将会被发送到专用队列中，同时调度系统将会优先处理来自监控系统的请求。

3.2.6
附件上下传子流程

4.
技术方案设计

4.1
系统总体技术方案设计

4.1.1
系统体系结构设计

系统体系结构如下图所示：

4.1.2
重点技术的分析，采用和设计

Ø 客户端技术

客户端的主要要求是易于部署，广泛适用，功能强大，界面友好。基于以上要求，最适合的技术是采用BS结构的客户端，也就是瘦客户端。基于纯HTML的展现技术可以适用于包括Windows,, Mac, Linux等多个平台，具有最广泛的适用性，基于浏览器的操作方式无需任何客户端部署，只需在Web服务器上安装或更新应用程序，基于全新的DHTML技术使得客户端的图形界面不再像以前那样呆板。

Ø UI自定义技术

UI自定义技术采用基于XML格式的机构，记录页面上的每一个元素所对应的活动定义中的字段之一，所有的XML文档与流程定义同步保存，并且统一在页面读取时采用自定义的组件将该页面转换为系统可以正确识别的文件格式，再予以渲染。

Ø 消息传递技术

由于整个工作流管理系统采用的是消息驱动的机制，消息传递的畅通与否将在很大程度上决定系统的运行状况，为适合多种平台的情况，本系统将不定义具体的消息传递的实现，只定义消息传递模块的接口，在具体实施的过程中可以根据具体的情况实现具体的消息传递模块，同一系统下可以有多个具体的实现模块，系统将根据配置文件来选择合适的模块。

Ø 数据库访问技术

为了最大程度的适应不同的数据库管理系统，所有的数据访问操作将被封装到专用的数据访问层，对于不同数据库的操作如MSSQL，ORACLE的将被封装到不同的模块中，但所有模块支持相同的接口，系统根据配置文件装载不同的模块，但接口保持一致因此无需修改具体的程序。

Ø 流程监控技术

为实时了解整个工作流管理系统的运行状况，所有的工作流运行情况将会被实时反馈到工作流监控子系统中，为保证消息反馈的实时性，并且减低系统的相应负荷，我们将采用UDP/TCP的方式进行监控信息的传递工作。

Ø 消息系统

消息系统主要完成各子系统通信。

消息系统接口实现：

底层的消息平台可选现成的产品；

或直接在数据库上实现。

Ø 工作流执行部分

主要完成业务流程的执行和推进，模型的计算，各接口的实现。

系统架构如下：

接口部分：

接口要垮语言平台。

接口采用何种技术：

EJB(JNDI),

一般的Java Class。是否可以包装为WebService。

包装为WebService。

Ø 各子系统接口逻辑

采用代理机制实现网络通信，跨网络域，编成语言的无关性。

架构如下：

Ø 持久化存储

底层的持久化存储可选现成的产品，或JDBC直接在数据库上实现。

持久化存储：

Java EJB

Hibernate

直接JDBC

Ø 日志

Log4j

Ø Xml解析

DOM4j

xml-apis

JDOM

DOM

SAX

Ø Web Service

Java WebService

MS.Net WebService

以上两种WebService不同语言间互相调用。

Ø 系统各模块装配

Spring

Struts

4.2
系统功能结构设计

4.2.1 UI子系统功能结构

Ø UI展现模块

UI展现模块包含所有的页面可视对象，提供与用户交互的接口，同时若某一模块属于自定义界面，展现模块将负责对自定义界面进行解析，并转换为真正的页面

UI展现模块的结构图如下图所示：

所有的自定义UI模块负责自定义的用户界面的渲染与解析，他们的格式以XML形式保存在数据库中。客户端操作子模块负责客户端的复杂类型操作，比如与Word等文本编辑工具的集成，附件操作子模块负责附件与附件服务器之间基于TCP的通讯功能。客户端安全子模块负责与各种安全接口，包括电子签名的接口。

Ø 工作流实例信息模块

对于数据库内的流程实例信息进行O-R Mapping，以便页面程序可以较为简便的访问并展示流程信息

Ø 数据库访问模块

提供统一的数据库访问模式，使得前台程序做到与数据库无关，与数据库类型无关

数据库访问模块的结构如下图所示：

配置文件解析子模块负责解析基于XML格式的数据库配置文件。配置文件监视子模块负责监视该文件的变化情况，在遇到任何变化的情况下及时通知并更新数据库配置。SQL转换子模块负责将系统的标准查询语言转换为与平台有关的物理查询语言（如MSSQL，Oracle）。以实现SQL与平台无关。数据库接口子模块负责为多种数据库提供统一的访问接口，加解密子模块负责对数据按照需要进行加解密。

Ø 校验模块

负责客户端输入数据的校验，以保证以后操作的正确性，防止错误的数据导致处理失败

Ø 信息传输接口

系统定义的统一数据传输接口，在此接口之上，系统开发人员或第三方开发人员可以实现基于各种传输协议的模块，系统根据配置文件来加载指定的模块并调用约定的接口，关于接口更详细的信息请参见接口设计章节

4.2.2
总调度子系统功能结构

Ø 路由调度模块

路由调度模块接受来自客户端的操作请求信息，并在自身维护所有工作流引擎的状态，然后按照一定的算法进行任务调度

总调度模块的结构图如下所示：

工作流引擎状态解析子模块负责读取并分析当前正在运行的各个工作流引擎的运行情况并给出量化的指标，调度算法子模块负责按照之之前的指标按照约定的路由算法给出目标工作流引擎。路由标示子模块负责对传递过的消息做路由标示。校验子模块负责对所有的消息进行校验以保证正确性。反馈子模块负责将当前总调度的各种操作通过预先定义的接口发送的监控系统。

4.2.3
调度子系统功能结构

Ø 子路由调度模块

子路由调度模块接受来自调度模块的操作请求信息，并在自身维护所有工作流机的状态，然后按照一定的算法进行任务调度

子路由调度模块的结构如下图所示：

工作流机解析子模块负责读取并分析当前正在运行的各个工作流机的运行情况并给出量化的指标，调度算法子模块负责按照之之前的指标按照约定的路由算法给出目标工作流机。路由标示子模块负责对传递过的消息做路由标示。校验子模块负责对所有的消息进行校验以保证正确性。

4.2.4
工作流机子系统功能结构

Ø 工作流定义模块

工作流定义模块将流程的完整定义从数据库内读出，并进行O-R Mapping之后放置在自身的实例当中，调用模块可将当前的流程实例信息输入以得到流程下一步的活动或活动列表。为提高系统的效率，在工作流引擎启动之时，所有的流程定义就将被实例化，读入内存。为保证系统的资源，定义模块为引擎全局共享。

Ø 工作流流转模块

工作流流转模块负责对工作流实例的状态按照客户端的要求进行变动，并将变动存入数据库中。在此期间，若经过的活动或处理含有附加的模块或脚本，流转模块也会相应的进行调用，以满足所有附加功能的完整实现。

工作流流转模块的结构如下图所示：

当消息传递至工作流流转模块时，消息解析子模块首先进行消息解析，判断消息的类型，对应的流程实例等，实例信息子模块将会读取对应的包实例，流程实例，活动实例等的具体类型，根据客户端的请求，活动解析子模块对流程的状态做相应的改变，在该过程中，如果遇有条件判断，脚本解析，附加组件等内容，则会调用对应的子模块进行处理，所有对于流程的处理都会被日志子模块所记录，并保存在数据库中，以保证流程回退的正常操作。附件操作子模块则负责在流程变更的过程中，对于附件服务器上的附件的操作。

4.2.5
监控子系统功能结构

Ø 查询子模块

查询子模块的主要功能让监控子系统可以不受约束的查询各个流程实例和工作流引擎，工作流总调度的运行情况，以便随时掌握整个工作流系统的运行情况。

Ø 数据导入导出子模块

由于针对监控系统的大量数据需要做统计和报表，该模块将按照事先定义的纬度，将数据导入到数据仓库中，进行多维表的计算，以便于进行报表统计。

5.
数据结构设计

5.1
逻辑结构设计

本系统中应包含以下的数据逻辑表：

l 包定义表

包含包一级的数据定义，包含名称，权限设计等

l 流程定义表

所有流程的定义表，包含流程名称，权限，全局设定，所属的包等

l 活动定义表

包含所有的活动名称，定义，属性，所属的流程等

l 流转定义表

包含所有的流转对象，包括名称，属性，开始和结束活动等

l 包实例表

包含所有正在运行的包的实例，以及所有的实例信息

l 流程实例表

包含所有正在运行的流程实例，包括实例信息，包括流程的当前状态，当前活动等

l 活动实例表

l 工作项实例表

l 数据常量表

包含系统中的某些数据常量

l 流程日志表

包含所有的流程流转信息，可以检索任意一个当前仍在运行的流程的所有历史操作记录

l 组织机构表

和工作流管理系统关联的用户的组织机构信息

l 运行日志表

运行日志表中包含了所有用于流程监控与分析的系统处理情况信息

6.
接口设计

6.1
外部接口

6.1.1
扩展接口

扩展接口的主要用途为在不改动系统主程序或流程定义的情况下，针对个别的特殊需求，扩展系统的处理能力。例如：某一流程的某一特殊环节临时需要通知某一领导，但不希望改动程序或流程定义，为此，我们可在该环节上添加特殊的组件或脚本，在流程执行到此处时，会通过实现约定的接口或函数名来调用外加的组件或脚本，以达到通知某领导的功能。

扩展接口将分为两大类，第一类与流程本身的流转无关，也就是该组件或脚本操作的成功与否不影响流程的运转，因此该接口只需要获得当前流程实例的信息即可，第二类为与流程本身的流转有关的接口，也就是该组件或脚本的失败将导致该流程流转的失败，因此在该接口需要额外添加流程流转时的事务对象，以保证该操作一旦失败可以让整个流转回滚，以保证双方同时成功同时失败。

扩展接口将以两种方式提供给开发人员，一种为原生语言或原生语言支持的接口类型，另一种为web service的接口，以支持尽可能多的平台和语言，但考虑到web service本身在效率上不足，以及对事务处理的有限支持，建议采用原生语言或支持的接口类型，以保证系统运行的效率。

6.1.2
二次开发接口

由于需求的多样性，我们无法保证一套工作流管理系统可以满足所有系统的需求，为此，我们可能会针对不同客户进行不同的二次开发，以便满足客户较为特殊的功能。

基于以上考虑，我们将系统中的绝大部分功能，包括新建流程实例，流程流转，流程信息获取，流程更新，流程监控，流程定义等主要功能，以原生语言接口的形式提供，任何开发人员可利用原生语言或支持原生语言接口的语言和平台进行系统的二次开发。

6.2
内部接口

内部接口主要指消息传递的接口。由于本系统为消息驱动的系统，消息接口是本系统最为关键的技术之一。

为保证系统的灵活性和模块的可重用性，所有的消息传递接口将采用完全相同的接口形式，同时由接口开发人员或第三方人员根据已定义的接口，在具体的传输协议上实现相关的模块组件。系统本身将根据配置文件来加载指定的模块，并调用定义好的接口。

根据用途的不同，消息传递接口将分为传入和传出接口，传入接口又包含简单传入接口和request-response接口，同样传出接口也包含简单传出接口与request-response接口，以保证满足各方面的需求。

接口本身将要求能够支持消息的单件处理以及批量处理，对于批量处理的信息，接口将能够实现容错处理，在处理失败时可以及时回滚。

7.
容错性设计

由于系统本身可能作为一个企业的关键应用而存在，因此系统要求较高的容错性以保证长时间稳定的运行。

7.1 Web服务端容错性

Web服务端由于包含主要的用户输入界面，是系统中不可停顿的部分之一。为保证Web服务端系统的稳定运行，我们将采用负载均衡的方式来运行Web服务端，所有的Web服务器通过4层交换机连接在一起，任何一台Web服务器出现故障将被从群集中删除，它的工作将由其他的Web服务器接替，对于客户端而言将不会有任何的感觉。

Web服务器

Web服务器

6509交换机

6509交换机

P1：10.192.1.49

P1：10.192.1.50

Farm ip：10.192.1.23

Vitual dns ip：192.168.3.20

port0

port1

port0

port1

home0 ip：192.168.3.101

port1 ip：192.168.3.1

port1 ip：192.168.3.2

home0

home1

home0

home1

home0 ip：192.168.3.102

gw ip：192.168.3.20

gw ip：192.168.3.20

7.2
工作流调度端及工作流机的容错性

工作流调度的工作状态始终由总调度进行监视，任何工作流调度或工作流机出现故障，系统将自动将自动将所有的工作切换到其他的机器，来保证可以继续有效的工作。

7.3
数据库系统的容错性

数据库系统作为整个系统的核心部分，要求具有极为强大的容错性，要能够在任何情况下保证数据的绝对安全。为此，整个数据系统的结构设计如下所示：

数据库A与数据库B实行双机热备(Cluster),任何一个节点出现故障，系统将自动把活动节点切换到另一台机器上，以保证系统的正常运行，所有的操作不需要人工的干预。为防止天灾对于系统数据的损坏，我们将在远程机房部署另一台数据库服务器，采用日志传送的方式将所有的数据变化传送到远程的数据库，以保证在任何情况下系统都可以将数据保存并恢复。

7.4
后台服务的容错性

对于系统得应用服务程序而言，所有的服务全部采用cluster-aware的应用程序模式，以保证该服务可以部署在服务器集群之上，从而保证应用程序的自动故障切换。

8.
安全性设计

8.1 HTTP传输层的安全性

HTTP层的传输加密将采用较为成熟的HTTPS(SSL)技术，提供基于RSA的数据加密，以保证在客户端与服务器端进行交互的情况下数据不会泄密。

为保证SSL的正常运行，系统要求所有的内部网络为SSL协议打开特定的端口（缺省为443端口），以便于SSL的正常运行。

SSL所需要的基于X.509的证书来源可以有两个，即基于企业内部的证书服务器或是基于购买的第三方的证书。

SSL本身的运行与否与应用程序本身无关，但考虑到所有数据在加解密的阶段所消耗的时间，建议在详细设计阶段考虑客户端与服务端的传输数据量，尽量减少数据量以保证系统的性能。

8.2
用户密码的安全性

用户密码的保存是安全性的主要考虑点之一。为尽可能的防止密码泄露与密码的恶意盗取，系统的用户帐号将与某一目录服务相关联，由用户本身所在的目录验证用户的合法性，而无须在应用内部进行密码的验证工作。

对于没有目录服务的环境，系统必须自行进行用户身份的验证，为保证密码的安全性，数据库内将不回明文存放用户的密码，所有的密码在进行不可逆的Hash运算后，才存入到数据库中，验证密码时系统应首先将密码进行Hash运算，而后将两者的值进行比较从而验证用户输入的密码的有效性。

8.3
对于数字签名及电子公章的支持

系统本身不含有数字签名的功能模块，但是，系统将有公开的接口支持与各种数字签名或电子公章的产品进行集成，以保证系统的充分可扩展性。

8.4
其他的安全性设计

在文件的传输及监控信息的传输过程中，由于本身是基于TCP/IP协议，系统将支持两种方式的加密措施，第一是在应用程序级的加密，由应用程序进行加密的工作，第二为采用IPSec的技术，实现协议级别的加密。