软件架构的实现方法和实现平台

摘要

本发明公开了一种软件架构的实现方法和实现平台。本发明实施例提供的软件架构的实现方法包括：将客户端软件的逻辑结构划分为多个逻辑层；建立各逻辑层之间的消息交互方式；通过应用层/UI层提供的客户端软件UI接收来自用户的业务请求消息，利用消息交互方式将业务请求消息发送至业务层；以及，通过应用层/UI层捕获业务层的事件并执行相应的业务操作，利用消息交互方式将应用层/UI层操作结果发送至通信层；通过业务层对业务请求消息请求的业务数据和事件进行管理，并执行业务操作，利用消息交互方式将业务层操作结果发送至通信层；通过通信层中预定通信方式的通信模块将应用层/UI层操作结果和业务层操作结果发送至业务服务器。

说明书

mat="original" lang="zh">

软件架构的实现方法和实现平台

技术领域

本发明涉及计算机软件应用技术领域， 特别涉及一种软件架构的实现方法和软件架构的实现平

背景技术

随着互联网的发展， 软件慢慢成为了用户生活中必不可少的互动沟通交流娱乐工具。 软件也由 最初的向用户提供单一功能或应用， 演变成了为用户提供生活支撑的一个大型的服务平台。

简化 IM客户端的开发效率， 使软件的架构设计和开发过程变得合理高效， 是业界目前亟待解决 的主要问题之一。 发明内容

鉴于上述问题， 本发明实施例提供了一种软件架构的实现方法和相应的软件架构的实现平台， 以达到简化开发操作、 提高软件开发效率的效果。

为了达到上述目的， 本发明实施例采用的技术方案如下：

一方面， 本发明实施例提供了一种软件架构的实现方法， 包括：

将客户端软件的逻辑结构划分为多个逻辑层， 该逻辑层包括基础支持层和从下至上的通信层、 业务层、 应用层 /用户界面 UI层； 以及， 建立各逻辑层之间的消息交互方式， 以利用消息交互方式运 行客户端软件， 其中， 该消息交互方式包括上层的逻辑层通过调用下层逻辑层中的接口访问下层的 逻辑层， 下层的逻辑层按照设定的事件机制向上层逻辑层发送消息；

根据基础支持层提供的内容， 通过应用层 /UI层提供的客户端软件 UI接收来自用户的业务请求 消息， 利用消息交互方式将业务请求消息发送至业务层； 以及， 通过应用层 /UI层捕获业务层的事件 并执行相应的业务操作， 利用消息交互方式将应用层 /UI层操作结果发送至通信层；

根据基础支持层提供的内容， 通过业务层对业务请求消息请求的业务数据和事件进行管理， 并 执行业务操作， 利用消息交互方式将业务层操作结果发送至通信层；

根据基础支持层提供的内容， 通过通信层中预定通信方式的通信模块将应用层 /UI层操作结果和 业务层操作结果发送至业务服务器；

其中， 基础支持层中存储各逻辑层的共有内容以及各逻辑层分别对应的专有内容。

另一方面， 本发明实施例提供了一种软件架构的实现平台， 包括：

逻辑层设置单元， 用于将客户端软件的逻辑结构划分为多个逻辑层， 该逻辑层包括基础支持层 和从下至上的通信层、 业务层、 应用层 /用户界面 UI层； 以及， 建立各逻辑层之间的消息交互方式， 以利用消息交互方式运行客户端软件， 其中， 消息交互方式包括上层的逻辑层通过调用下层逻辑层 中的接口访问下层的逻辑层， 下层的逻辑层按照设定的事件机制向上层逻辑层发送消息；

应用层 /UI层处理单元， 用于根据基础支持层提供的内容， 通过应用层 /UI层提供的客户端软件 UI接收来自用户的业务请求消息， 利用消息交互方式将业务请求消息发送至业务层； 以及， 通过应 用层 /UI层捕获业务层的事件并执行相应的业务操作， 利用消息交互方式将应用层 /UI层操作结果发 送至通信层；

业务层处理单元， 用于根据基础支持层提供的内容， 通过业务层对业务请求消息请求的业务数 据和事件进行管理， 并执行业务操作， 利用消息交互方式将业务层操作结果发送至通信层；

通信层处理单元， 用于根据基础支持层提供的内容， 通过通信层中预定通信方式的通信模块将 应用层 /UI层操作结果和业务层操作结果发送至业务服务器； 其中， 基础支持层中存储各逻辑层的共有内容以及各逻辑层分别对应的专有内容。 由上所述， 本发明实施例通过对客户端软件的逻辑结构进行合理分层以及采用接口访问、 事件 机制建立各层之间交互的技术手段， 搭建了一个良好的软件架构， 各逻辑层之间相互分离， 易于拆 分进行独立开发， 各层之间处理的逻辑性强， 且代码的耦合度低， 对一层的改造不会影响其他层的 运行， 从而达到了以一种更简单的方式开发出性能更加优越的软件的目的。 附图说明

图 1示出了根据本发明一个实施例的软件架构的实现方法中的逻辑层次示意图；

图 2示出了根据本发明一个实施例的一种逻辑层间的关系示意图；

图 3示出了根据本发明又一个实施例的一种线程模型的示意图；

图 4示出了根据本发明又一个实施例的一种基于回调模型的交互方法示意图；

图 5示出了根据本发明又一个实施例的一种基于事件模型的交互方法示意图；

图 6示出了根据本发明又一个实施例的通信层的具体结构示意图；

图 7示出了根据本发明又一个实施例的利用插件管理模块安装插件的方法流程图；

图 8示出了根据本发明又一个实施例的一种利用插件管理模块启动插件的方法流程图； 图 9示出了根据本发明又一个实施例的又一种利用插件管理模块启动插件的方法流程图； 图 10示出了根据本发明又一个实施例的一种软件架构的实现平台结构示意图。 具体实施方式

为使本发明的目的、 技术方案和优点更加清楚， 下面将结合附图对本发明实施方式作进一步地 详细描述。

本发明的主要目的在于搭建一个良好的软件架构使开发出的软件具有更优越的性能， 如软件的 性能更加可靠、 强壮， 且足够灵活、 利于扩展复用。 开发人员使用本发明实施例中的软件架构方案， 能够很简单地开发出集成多个功能和应用的软件。

参见图 1， 示出了本发明一个实施例提供的一种软件架构的实现方法中的逻辑层次示意图。 将客 户端软件的逻辑结构划分为多个逻辑层， 该逻辑层包括基础支持层和从下至上的通信层 （如 Comm 层） 、 业务层 （如 Biz层） 、 应用 （APP ) 层 / UI ( User Interface , 用户界面） 层。 建立各逻辑层之 间的消息交互方式， 以通过各逻辑层之间的消息交互运行客户端软件， 例如， 一种消息交互方式的 示例可以为： 上层的逻辑层通过调用下层逻辑层中的接口访问下层的逻辑层， 下层的逻辑层按照设 定的事件机制向上层逻辑层发送消息。

可选的， 对客户端软件中具有插件的场景， 逻辑层中还包括插件接口层 （如 PluginSDK层） 和 插件层 （如 Plugins层） 。 在插件接口层中为插件提供接口， 以使插件能够访问客户端软件； 以及， 将插件设置在插件层中。 在业务层中还设置有插件管理模块， 插件管理模块执行插件的管理操作， 业务层利用插件管理模块对客户端软件的插件进行管理， 该管理操作至少包括插件的安装、 卸载、 加载和启动等。

下面结合一次业务请求操作， 对本实施例提供的客户端软件进行说明。

首先， 客户端软件根据基础支持层提供的内容， 通过应用层 /UI层提供的客户端软件 UI接收来 自用户的业务请求消息， 利用消息交互方式将业务请求消息发送至业务层； 以及， 通过应用层 /UI层 捕获业务层的事件并执行相应的业务操作， 利用消息交互方式将应用层 /UI 层操作结果发送至通信 层。

本实施例在应用层 /UI层中对客户端软件 UI的控制和管理， 并根据捕获到的业务层的事件执行 相应的业务操作。 具体的， 在应用层 /UI层中执行的操作主要包括如下：

1 : UI的控制和管理。 例如， 在应用层 /UI层中提供统一的会话窗口管理、 选项窗口管理， 以及 对 UI控件进行再度封装， 创建具有特定功能和行为的 UI控件等

2: 和业务层的交互管理。 例如捕获业务层抛出的事件， 根据该事件进行一个业务操作等。 3 : 设置界面管理框架 （CFrame ) 。 CFrame为应用层 /UI层界面管理类容器， 利用该 CFrame统 一存储和获取界面管理类， 应用层 /UI层可使用 CFrame获取到本层中各个界面的管理类， 从而获得 不同的界面模块， 并能对界面模块进行操作， 执行界面间的相互调用。 例如， 通过界面模块的调用， 执行由一个窗口唤起完全不相关的另一个窗口的显示的功能。

其次， 客户端软件根据基础支持层提供的内容， 通过业务层对业务请求消息请求的业务数据和 事件进行管理， 并执行业务操作， 利用消息交互方式将业务层操作结果发送至通信层。

本实施例在业务层中对客户端软件的业务数据和事件进行管理， 并执行业务操作。 在业务层中 设置客户端软件的核心业务逻辑， 对外提供业务对象和方法。 具体的， 在业务层执行的操作主要包 括如下：

1 : 业务数据的管理。 例如， 配置数据的管理、 权限数据的管理等。

2: 事件的管理。 例如， 在业务层收到通知添加好友的数据包时， 业务层处理此数据包并抛出添 加好友的事件，由其他的业务层或应用层 / UI层来处理该事件。

3 : 和通信层数据进行交互。 例如， 接收通信层发送的 SIP数据包。

在业务层中还需要设置供应用层 / UI层调用的接口， 以支持应用层 / UI层对业务层的访问。 在业 务层中采用容器这一技术手段处理相关操作， 一个具体实例可以如下： 构造业务层的容器， 如构造 容器类 CSession, 该容器中可以设置业务层中多个业务管理对象 （如插件管理模块） ， 具体的， 容 器类 CSession可为单实例结构， 其生命周期和进程的生命周期相等。 容器类 CSession在程序启动时 候初始化， 通过容器类 CSession的初始化可以对每个业务对应的业务管理对象进行初始化； 用户注 销或者掉线的时候调用容器类 CSession的清除（Clear )方法， 可清理每个业务管理对象相关的资源， 例如配置、 内存等等。

再次， 客户端软件根据基础支持层提供的内容， 通过通信层中预定通信方式的通信模块将应用 层 /UI层操作结果和业务层操作结果发送至业务服务器。

本实施例在通信层中设置预定通信方式的通信模块。 例如， 对于 SIP ( Session Initiation Protocol, 会话发起协议）通信， 在通信层中设置多个通信模块分别支持 TCP ( Transmission Control Protocol, 传输控制协议 )通信方式、 HTTPS ( Hypertext Transfer Protocol over Secure Socket Layer, 安全 HTTP ) 通道（Tunnel )通信方式、 HTTP通信方式等。 在通信层中还可以对底层通信细节（如各种代理设置、 凭证等等） 进行封装， 并进行对 SIP 协议的拼包、 解包。 为实现逻辑层之间的交互， 在通信层中还 针对 SIP、 HTTP. 文件传输等不同的通信方式为上层分别提供简单易用的接口， 供上层调用。

本实施例在基础支持层中存储各逻辑层的共有内容以及各逻辑层分别对应的专有内容， 以利用 基础支持层提供的内容支持各逻辑层的运行。 在基础支持层中存储的内容包括公共辅助工具类 ( Utils )、 资源（ Resources ) 、 UI控件（ UiControls )和在线升级工具（ Liveupdate )。 其中， Resources 包括程序资源包、 独特设计的支持多国语言的语言包， 该语言包按照语言类型归档， 支持多语言包 的动态插入、 多国语言动态切换， 并可根据用户的需求定制本国语言包， 使语言设计更加本地化。 参见图 2， 示出了本实施例提供的一种逻辑层间的关系示意图。 应用层 /UI层与业务层具有强相关， 通信层和 Utils具有强相关， 应用层 /UI层、 业务层需要 Utils 的支持， 业务层可以访问通信层， 而 Resources 向各层提供图片等实体数据的支持。 基础支持层可以向应用层 /UI层、 业务层、 通信层和 插件接口层提供统一的应用接口， 降低代码重复性和复杂度。 本发明又一个实施例对软件架构的实现方法中的多线程模型进行说明， 软件架构的实现方法中 的其他内容可以参见本发明其他实施例。 本实施例采用如下四类线程模型， 其中除业务线程外， 其 他三类只存在一个全局线程。

( 1 ) UI线程。 UI线程为 Windows桌面应用程序的界面主线程。 除可能耗费较长时间的业务操 作外， 大部分业务操作将完全在 UI主线程中执行， 这样尽量避免引入线程同步问题， 从而降低开发 的复杂度， 提高编程和运行效率。

( 2 ) 业务线程。 业务线程为业务操作所建立的线程。 当一个业务操作可能耗费较长时间， 从而 造成 UI线程阻塞时， 可以为该业务操作创建业务线程。

( 3 )通信线程。 通信线程为通信层收发 SIP数据包所使用的线程。 SIP通信不具有大流量、 高 实时性要求， 收发操作可以在同一个线程中完成。 通信线程中还会进行 SIP拼 /解包等简单操作。

( 4 ) 定时器 （Timer ) 线程。 一个是 Windows Timer, 另外一个是线程 Timer, 根据具体情况选 择使用， 全局共享。

参见图 3 , 示出了本实施例采用的线程模型的示意图。 UI 方法 （UIMethod ) 和业务方法 ( BizMethod ) 可以运行在 UI线程 ( UIThread ) 上， BizMethod还可以运行在业务线程 （ BizThread ) 上， 发送（Send )操作和接收 （Recv )操作运行在通信线程上。 为需要发送和接收的消息分别建立 发送队列和接收队列， 并为超过预定时间仍未处理的消息建立超时队列， 以便于对消息的管理。 超 时判断 （Timeout )操作运行在定时器线程上。 朝向上方的箭头表示按照事件机制的交互， 朝向下方 的箭头表示接口调用。

本发明又一实施例对软件架构的实现方法中的事件机制进行说明， 软件架构的实现方法中的其 他内容可以参见本发明其他实施例。 本实施例提供的事件机制包括两种模型： 回调 （Callback )模型 和事件 （Event )模型。

回调模型的一种应用场景可以为： UI对象主动发起请求， 等待服务器侧（或另一客户端， 下同） 返回应答， 得知处理结果。 例如， 用户发送会话消息后， 需要知道该消息是否发送成功。 在该场景 下有以下几个特点：

1 : 特定的 UI对象主动发起请求， 并等待处理结果；

2: 只有动作发起对象需要关心该处理结果；

3 : 该处理结果在可预测的时间内 （最长为该动作的超时时间） 一定会返回；

4: 从发起请求到处理结果的返回， 需要传递一些上下文信息。

参见图 4， 示出了本实施例提供的一种基于回调模型的交互方法示意图， 包括如下操作：

S400 : 在业务层对回调请求进行记录并根据该回调请求发送业务请求至通信层。 上述回调请求 是由应用层 /UI层中的 UI对象向业务层发起的。 在业务层中通过业务方法记录该回调请求， 例如， 通过 BizMethod ( UiCallback, UiContex ) 处理回调请求。

S401 : 在通信层对业务请求进行处理。 通信层中通过发送操作将业务请求发送出去。

通过上述步骤 S400至 S401在应用层 /UI层、业务层和通信层之间应用回调机制实现了一个回调 请求。

S402： 在通信层接收对业务请求的处理结果数据包， 对处理结果数据包进行解析并将其转换为 响应消息， 从通信层将该响应消息返回至业务层， 进入步骤 S403 , 由业务层处理响应消息。 响应消 息可以是在业务请求发送后实时接收到的， 也可以是在一定时间范围内接收到的。

S403 : 在业务层中判断是否存在回调请求。

业务层判断是否存在与响应消息对应的回调请求， 若是， 确认存在回调请求， 进入步骤 S404， 若否， 结束操作。

S404: 业务层将响应消息返回至发起回调请求的 UI对象， 执行回调操作。

事件模型的一种应用场景可以为： 通信层收到服务器侧 （或另一客户端） 的消息 （可能是请求 也可能是应答）后， 需要反馈到应用层 /UI层上进行某种展示或进行其他相关动作。 在该场景下有以 下几个特点：

1 : 业务层内部数据发生改变， 即发生了一个事件时 （通常是收到服务器侧或另一客户端的消息 时发生， 但不限于此） ， 通知到需要关心该变化的所有 UI对象（被通知者） ；

2: 关心该变化的 UI对象可能不只一个；

3 : 该变化发生的时机对于被通知者不可预知；

4: 被通知者需要 "订阅" 该事件后才可被通知。

参见图 5， 示出了本实施例提供的一种基于事件模型的交互方法示意图， 包括如下操作： S500: 执行事件订阅。

由应用层 /UI层中的一个或多个 UI对象向业务层进行事件订阅， 在业务层中可以通过事件订阅 方法如 SubscribeEvent ( BizEvent, UIEventHandler )执行事件的订阅。

在事件订阅完成后， 执行如下步骤 S501至 S504的操作。

S501 : 通信层接收到消息， 将消息发送至业务层。 通信层接收到的消息会导致业务层的数据变 化， 从而发生相应事件。

S502: 业务层中判断发生的事件是否被订阅， 若是， 进入步骤 S503 , 若否， 结束操作。

S503 : 业务层将事件通知给应用层 /UI层中订阅该事件的 UI对象。

S504: 被通知的 UI对象根据发生的事件执行相应操作。

由上， 本实施例通过上述操作， 提供了一种事件注册管理机制， 把不同的功能和应用调度结合， 代码耦合度低、 流程清晰且具有高性能触发、 界面反应迅速的优点， 在保持软件功能和应用完整性 的同时， 完成了多功能、 应用的互通， 便于开发人员对软件的维护和扩展。 本发明又一个实施例对软件架构的实现方法中的通信层进行说明， 软件架构的实现方法中的其 他内容可以参见本发明其他实施例。 参见图 6， 图中示出了本实施例的通信层的具体结构示意图， 在 通信层中设置业务层管理模块、 模块接口层和模块设置层。 下面分别进行说明：

业务层管理模块：

业务层管理模块负责业务层与通信层的双向通信调用， 例如， 利用业务层管理模块支持业务层 对通信层的接口访问， 为业务层提供 SIP 通讯调用接口， 在模块接口层中设置回调接口等。 业务层 管理模块可以根据业务层对通信层的接口访问， 通过模块接口层中的通信模块接口调用模块设置层 中的通信模块， 以执行客户端的通信。

模块接口层：

在通信层的模块接口层中设置与通信模块对应的通信模块接口 （如回调接口） 以及通信模块接 口的接口数据。 接口数据可以包括连接配置信息、 接收包的数据结构、 发送包的数据结构、 连接类 型等。

参见下述表 1， 示出本实施例提供的连接配置信息。 表 1

接收包的类型 （type ) 、 收到的 SIP请求包 （ SipRequest ) 、 收到的 SIP回应包 （ SipResponse ) 和配对的发送包 （ requestContext ) 。 其中， 接收包的类型可以包括如下：

发送超时 （ SEND— TIMEOUT ) 、 收到非 Ack请求 （ RECV— REQUEST )、

收到回应 （ RECV— RESPONSE ) 、 收到成功回应 （ RECV— RESPONSE— 200 ) 、 收到 Ack 请求 ( RECV ACKREQUEST )。

本实施例提供的发送包的数据结构中包括如下信息：

业务层传递的上下文 （ bizContext ) 和 SIP数据包 （ sipMessage )

本实施例提供的连接类型至少包括 UNKNOWN- TCP DIRECT- HTTPS TUNNEL和 HTTP 四 种类型， 其中， UNKNOWN表示未知的连接类型， TCP— DIRECT表示 TCP i连方式承载 SIP信令， HTTPS TUNNEL 表示 HTTPS方式承载 SIP信令， HTTP表示 HTTP方式承载 SIP信令。

模块设置层：

在通信层的模块设置层中设置预定通信方式的通信模块， 一种通信模块可以为客户端软件提供 一种通信方式， 并可以在通信层中执行通信方式在不同通信模块之间的切换。 本发明又一个实施例对软件架构的实现方法中的业务层的插件管理模块进行说明， 软件架构的 实现方法中的其他内容可以参见本发明其他实施例。 插件是一种软件公开 API接口供自己或者第三 方开发者使用， 以扩展程序功能的应用。本实施例可支持两种类型的插件，一是 B/S ( Browser/Server, 浏览器 /服务器）模式的插件， 或称为外接插件； 一种是客户端 （Client )模式的插件， 或称为本地插 件。 B/S模式的插件指插件的运行环境限定在应用程序指定的插件容器中， 有的 B/S模式的插件需要 服务器支持（该服务器为插件的开发者提供） ， 有的 B/S模式的插件只需要一个带有 Javascript客户 端脚本的 HTML文件即可。

在业务层中设置插件管理模块， 该插件管理模块执行插件的管理操作， 如插件的安装、 卸载、 加载和启动； 通过插件管理模块对客户端软件的插件进行管理；

参见图 7， 示出了本实施例的利用插件管理模块安装插件的方法流程图， 包括如下步骤：

S700： 插件管理模块在数据服务器中搜索插件。

客户端软件的插件管理模块中包括插件容器， 插件容器中会记录插件的插件 ID , 当需要请求某 一插件时， 将插件 ID发送至数据服务器， 以在数据服务器中根据该插件 ID搜索插件， 搜索插件时 可以根据插件类型进行搜索， 也可以模糊搜索， 在此不对搜索方法进行具体限定。

S701 : 插件管理模块根据数据服务器返回的搜索结果， 选取需要的插件。

搜索结果中包括搜索出的一个插件或者包括多个插件的插件集合， 在搜索结果中选取与插件 ID 匹配的 B/S模式的插件。

数据服务器还会将插件的描述信息返回至客户端软件侧。 插件的描述信息可以使用 XML ( Extensible Markup Language , 扩展性标识语言）格式， 方便扩展。 描述信息包括插件编号、 插件名 称、 插件类型、 插件标签、 运行模式、 插件权限、 是否使用其他控件支持等， 但不局限于此， 运用 此描述信息进行服务器侧和客户端软件之间的插件的交互。 插件管理模块也可以根据描述信息执行 对 B/S模式的插件的管理操作。

S702: 插件管理模块显示授权页面， 告知用户插件的授权。

插件的权限要求， 需要在提交插件时明确说明。 在向数据服务器提交插件时， 数据服务器需要 提供一个 Web页面， 供插件提供方提交自己的插件列表， 用户填写相关信息， 获得插件的插件 ID。 插件信息记录至服务器的数据库中。 插件提供方可设置插件的权限要求， 例如， 是否记录用户信息， 是否可以访问软件的核心业务， 是否需要安装 ActiveX控件等， 以便于管理与维护。

S703 : 插件管理模块安装插件， 更新本地数据。

当客户端软件侧满足插件权限要求， 将插件安装在客户端软件中， 更新客户端侧的本地数据。 S704: 插件管理模块发送引用通告到引用通告服务器。

安装完插件后， 发送一个 Trackback (即引用通告） 到插件的引用通告服务器， 引用通告服务器 中记录安装插件的用户和插件的权限要求， 以便于插件管理。

S705 : 插件管理模块更新数据到数据服务器， 以便于数据服务器对客户端软件的包括插件在内 的多个功能进行管理。

参见图 8， 示出了本实施例的一种利用插件管理模块启动插件的方法流程图， 包括如下步骤： S800: 插件管理模块启动选择的插件。

插件管理模块可以根据用户通过菜单或工具条发送的选取指令， 获知当前需要启动的插件。 S801 : 插件管理模块判断选取的插件是否与当前要执行的操作相符合， 若是， 进入步骤 S802， 若否， 进入步骤 S803。

S802: 插件管理模块判断该插件是否多人运行， 若是， 进入步骤 S805， 若否， 进入步骤 S804。 S803 : 插件管理模块向用户提示启动操作结束。

S804: 插件管理模块创建插件容器， 插件容器可以装载多个插件。 然后， 进入步骤 S806。 S805 : 插件管理模块向其他具有相同插件的客户端软件的对方用户发出邀请， 进入步骤 S807。 S806: 插件管理模块运行插件， 进入步骤 S808。

S807: 插件管理模块判断被邀请的对方用户是否接受邀请， 若是， 进入步骤 S804， 若否， 进入 步骤 S803。

S808 : 插件管理模块更新引用通告服务器。

插件启动完成后， 插件管理模块发送一个引用通告到插件的引用通告服务器， 对引用通告服务 器中记录的插件的数据进行更新。

上述步骤 S800至 S808主要对客户端软件作为插件启动的发起方时启动插件的场景进行说明， 对接受插件启动邀请的一方，其利用插件管理模块启动插件的方法流程图，参见图 9， 包括如下步骤：

S900: 插件管理模块接收到插件邀请。

被邀请方一侧的客户端软件的插件管理模块接收邀请方发送来的插件邀请。

S901 : 插件管理模块判断客户端软件中是否安装了被邀请的插件， 若是， 进入步骤 S904， 若否， 进入步骤 S902。

S902: 插件管理模块判断客户端软件中是否需要安装该插件， 若是， 进入步骤 S905， 若否， 进 入步骤 S903。

S903： 插件管理模块向邀请方发送拒绝消息。

S904: 插件管理模块在客户端软件中查找被邀请的插件， 进入步骤 S906。

S905: 插件管理模块将插件安装在被邀请的客户端软件中。

S906: 插件管理模块判断查找到的插件是否与客户端软件兼容， 若是， 进入步骤 S908， 若否， 进入步骤 S907。

S907:插件管理模块为不兼容的插件创建针对该插件的独立承载体，启动该插件，进入步骤 S909。 示例性的， 可以采用插件容器作为上述插件的承载体， 但插件的承载体不局限于插件容器。 S908 : 插件管理模块在客户端软件中为兼容的插件寻找对应的承载体， 启动该插件， 进入步骤 S909.

S909: 插件管理模块向邀请方发送响应。

本实施例可以为客户端软件的插件设置一个插件集， 在插件集中设置插件的描述信息或配置信 息， 以及插件行为定义。 可以将不同类型的插件分别设置在不同的插件集中。 然后将插件集装载在 创建的插件容器中， 来执行插件和客户端软件之间的交互。

插件集中的插件行为可以包括获取插件数量、 添加插件、 删除插件、 插件排序、 获取全部插件 和查找对应插件等。 插件管理模块可以统一管理插件集， 在便于管理的基础上还可对插件集再进行 扩展。 插件管理模块执行的管理可以包括： 加载插件、 安装插件、 卸载插件、 发送插件邀请、 接收 插件邀请， 获取插件列表、 获取插件信息、 保存插件列表和更新插件列表等等。

对于为客户端模式的插件， 在客户端软件中为客户端模式的插件设置配置信息， 以由插件管理 模块根据该配置信息执行对客户端模式的插件的管理操作， 如插件加载、 插件卸载等。

本发明实施例的软件架构的实现方案支持外接插件， 使开发出的软件可移植性强、 重用力度大。 插件可通过接口向外部提供自己的服务， 复用力度大， 移植方便。 增加或减少插件不影响整个体系 结构， 例如， 在软件开发的过程中修改应用程序， 通过补丁包的形式增删插件， 从而使软件的结构 容易调整、 易维护。 本发明实施例的实现方案还支持本地插件， 插件类型划分清晰， 支持插件独立 升级， 便利开发， 降低了维护成本。

本发明又一个实施例还提供了一种软件架构的实现平台 100。 参见图 10， 该平台 100 包括逻辑 层设置单元 110、 应用层 /UI层处理单元 11 1、 业务层处理单元 112和通信层处理单元 113。 对于客户 端软件包括插件的场景， 平台 100中还包括插件接口层处理单元 114和插件层处理单元 115。 下面分 别对这些单元进行说明。

逻辑层设置单元 110， 用于将客户端软件的逻辑结构划分为多个逻辑层， 该逻辑层包括基础支持 层和从下至上的通信层、业务层、应用层 /用户界面 UI层； 以及， 建立各逻辑层之间的消息交互方式， 以利用消息交互方式运行客户端软件， 其中， 消息交互方式包括上层的逻辑层通过调用下层逻辑层 中的接口访问下层的逻辑层， 下层的逻辑层按照设定的事件机制向上层逻辑层发送消息。 具体的， 逻辑层设置单元 110，用于由应用层 /UI层中的 UI对象向业务层发送回调请求； 在业务层对该回调请 求进行记录并根据该回调请求发送业务请求至通信层； 当通信层获取到对业务请求的响应消息时， 从通信层将该响应消息返回至业务层， 在业务层中判断是否存在与该响应消息对应的回调请求， 若 是， 将响应消息返回至发起该对应的回调请求的 UI对象， 若否， 结束操作。 以及， 逻辑层设置单元 110, 用于由应用层 /UI层中的一个或多个 UI对象向业务层进行事件订阅； 当业务层中发生一个事件 时， 在业务层中判断该事件是否被订阅， 若是， 则通知订阅该事件的 UI对象， 以使该 UI对象根据 发生的事件执行相应操作， 若否， 结束操作。

应用层 /UI层处理单元 111 , 用于根据基础支持层提供的内容， 通过应用层 /UI层提供的客户端 软件 UI接收来自用户的业务请求消息， 利用消息交互方式将业务请求消息发送至业务层； 以及， 通 过应用层 /UI层捕获业务层的事件并执行相应的业务操作， 利用消息交互方式将应用层 /UI层操作结 果发送至通信层。

业务层处理单元 112， 用于根据基础支持层提供的内容， 通过业务层对业务请求消息请求的业务 数据和事件进行管理， 并执行业务操作， 利用消息交互方式将业务层操作结果发送至通信层。 进一 步的，业务层处理单元 112，用于在业务层中设置插件管理模块，插件管理模块执行插件的管理操作， 管理操作至少包括插件的安装、 卸载、 加载和启动； 利用插件管理模块对客户端软件的插件进行管 理。 其中， 插件包括 B/S模式的插件和 /或客户端模式的插件。 具体的， 业务层处理单元 1 12， 用于 利用插件管理模块中的插件 ID从服务器侧下载与插件 ID匹配的 B/S模式的插件和该插件的描述信 息， 以由插件管理模块根据描述信息执行对 B/S 模式的插件的管理操作； 为客户端模式的插件设置 配置信息， 以由插件管理模块根据该配置信息执行对客户端模式的插件的管理操作。

通信层处理单元 1 13， 用于根据基础支持层提供的内容， 通过通信层中预定通信方式的通信模块 将应用层 /UI层操作结果和业务层操作结果发送至业务服务器。 具体的， 通信层处理单元 1 13， 用于 在通信层中设置业务层管理模块、 模块接口层和模块设置层； 利用业务层管理模块支持业务层对通 信层的接口访问， 以及由该业务层管理模块根据接口访问， 通过模块接口层中的通信模块接口调用 模块设置层中的通信模块， 以完成客户端的通信； 在通信层的模块接口层中设置与通信模块对应的 通信模块接口以及通信模块接口的接口数据； 在通信层的模块设置层中设置预定通信方式的通信模 块。

其中， 基础支持层中存储各逻辑层的共有内容以及各逻辑层分别对应的专有内容。 基础支持层 存储如下内容： 公共辅助工具类、 资源、 UI控件和在线升级工具， 其中， 资源包括程序资源包、 支 持多国语言的语言包。

进一步的， 逻辑层设置单元 1 10划分的逻辑层还包括插件接口层和插件层， 则平台 100还包括 插件接口层处理单元和插件层处理单元。 插件接口层处理单元 1 14， 用于在插件接口层中为插件提供 接口， 以使插件能够访问客户端软件； 插件层处理单元 1 15， 用于将插件设置在插件层中。

本发明产品实施例中各单元的具体工作方式可以参见本发明方法实施例中的相关内容。

由上所述， 本发明实施例通过对客户端软件的逻辑结构进行合理分层以及采用接口访问、 事件 机制建立各层之间交互的技术手段， 搭建了一个良好的软件架构， 各逻辑层之间相互分离， 易于拆 分进行独立开发， 各层之间处理的逻辑性强， 且代码的耦合度较低， 对一层的改造不会影响其他层 的运行， 从而达到了以一种更简单的方式开发出性能更加优越的软件的目的。

以上所述仅为本发明的较佳实施例而已， 并非用于限定本发明的保护范围。 凡在本发明的精神 和原则之内所作的任何修改、 等同替换、 改进等， 均包含在本发明的保护范围内。