WEB智能应用系统开发运行支撑平台的总体设计

WEB智能应用系统开发运行支撑平台的总体设计（欢迎讨论）
WEB智能应用系统开发运行支撑平台的总体设计
整个应用系统的运行工作原理
1，开发阶段
专家系统开发平台与服务端的交互过程：
图1，
（1），专家系统开发人员查询KBUDDI服务器，获取可用的知识库操作web服务列表，根据自己的需要选择相应的知识库操作web服务。

（2），专家系统开发人员查询组件库，获取可用的智能组件列表，根据自己的需要选择相应的智能组件，获取智能组件的id。

（3），专家系统开发人员根据所选的知识库和智能组件，从组件库中查询合适的输入界面组件并下载到本地，如果没有，则开发人员根据所选知识库操作Web服务返回的知识库文件所需要的初始事实列表创建相应的输入事实界面组件供本地使用，也可以注册到组件库中供以后重用。

（4），开发人员根据所要采用的智能组件下载相应组件的辅助组件（如，输出界面组件，显示界面组件，推理过程分析组件等）。

说明，a，输入界面组件，在生成后的专家系统上，能够通过该界面获取用户的输入，最终生成一个包含所有输入信息的对象，该对象能够传递给服务端的智能组件使用。

b，所选择的知识库的表示形式应与智能组件匹配。

c，在注册智能组件时需要为每个智能组件产生一个唯一id（例如产生GUID使用）。

d，在向组件管理服务中注册智能组件时应提供辅助组件的注册，并与智能组件区别开，一个智能组件可以有多套辅助组件。

e，知识查询服务由知识访问中间件提供，组件查询服务由组件管理服务提供。

f，在开发过程中可以查看组件管理库中所有现有组件（智能组件和辅助组件）信息，每个组件要有详细的说明信息，方便用户从中选择。

g，这里的界面指的不是某个可视化的控件，如一个按钮，一个标签等界面元素，而是完成相关的一种功能的一系列可视化控件及相关的工作流程的组合。

h，界面组件可以用平台提供的界面开发工具开发，也可以用大型的IDE开发。

i，辅助组件也可以不从组件库中下载，而是在本地开发出来使用。

i，输入界面与知识库相关。

专家系统开发平台在本地进行开发的过程
图3，
（1），根据所采用的推理机组件，从本地选择一套合适的辅助组件，这里主要包括输入界面组件，输出界面组件等，将其与所要生成的专家系统绑定。

（2），将所用的知识库操作web服务与所要生成的专家系统绑定。

（3），开发人员为将要发布的专家系统绑定一个身份（方式可以是用户名密码或者授权证书），用于专家系统运行阶段的身份验证和授权。

例如，开发人员以某种方式在容器中间件中为将要发布的专家系统注册一个帐号或者从容器中间件中选择一个合适的帐号，该帐号拥有专家系统正常运行所需的权限，帐号信息至少包括专家系统的ID和密码，作为专家系统的身份凭证，这个ID和密码与将要发布的专家系统绑定，专家系统在运行期间需要向容器中间件提交该ID和密码，由容器中间件进行身份验证。

（4），发布，产生一个领域专家系统。

说明，a，构建专家系统的时候可以提供两种选择，一种仅使用一个智能组件和一个知识库进行推理，没有协作功能，另一种是带有协作功能的，需要选择多个智能组件，一个知识源（每个智能组件使用的知识表示形式不一样，但知识的内容一样）。

b，基于规则的推理机需要的初始输入信息包括初始事实列表，知识源，推理策略（考虑到网络运行，实际只能采取前向一次推理的策略）等。

c，辅助组件的主要组成和目的，1，输出界面组件，解析容器中间件返回的推理结果(xml)，在本地以用户可理解的界面显示出来。

2，推理过程显示组件，将智能组件的计算过程在本地以直观的形式显示给用户。

d，每一种推理机组件至少有一套辅助组件，每一套辅助组件至少包括输入界面组件，输出界面组件，还可以有推理过程显示组件。

e，在开发时，开发人员对其选择的每个推理机组件，选择一套辅助组件（每一个推理机至少应有对应的输入界面组件，输出界面组件），下载到本地，将其与推理机组件绑定，这样开发完成后的专家系统就具有固定的界面。

如果没找到所用推理机的辅助组件（主要是输入界面组件，输出界面组件），或者对已提供的辅助组件不满意，开发人员可以自己开发一套辅助组件使用，并可以将其注册到组件管理服务器上，与对应推理机组件关联。

2，运行阶段
开发出的专家系统的运行过程
图2，
（1），用户向输入界面中输入初始事实，推理策略等参数，产生一个输入对象作为推理机的初始化信息输入。

（2），专家系统根据绑定的知识库信息，访问知识访问中间件，获取所需的知识库。

（3）专家系统向容器中间件发送运行时所需信息，包括所要请求的智能组件信息，那些智
能组件需要的初始化参数信息（例如，对基于规则的推理机，可以有初始事实，推理策略，知识库等，其中，初始事实和推理策略可以封装到一个对象里面作为参数，知识库则以xml 流的形式，由专家系统向知识访问中间件发送请求，然后知识访问中间件直接返回给相应的的智能组件Web服务）。

（4），容器中间件根据所要请求的智能组件信息（智能组件的id）访问组件管理服务，定位所需的智能组件，并加载，然后将推理请求转发给对应的智能组件处理，智能组件需要读取传送过来的初始信息，完成推理工作，然后将处理后的结果（XML）返回给用户。

需要的话，容器可以将智能组件的处理过程也返回给用户。

（5），如果需要的话，专家系统向容器中间件发出协作请求。

（6），容器中间件接受协作请求，调度相应的智能组件进行协作处理，并将结果返回。

（7），专家系统对返回的结果进行解析，以直观的方式显示给用户。

说明，a，容器中间件的接口和知识访问中间件的接口都以web服务的形式暴露出来。

b，推理机组件需要的知识库由专家系统请求知识访问中间件，知识访问中间件将知识库直接返回给容器使用。

c，智能组件不能直接被外部访问，其服务请求和参数由容器转发。

d，容器中间件仅暴露一个web服务类，运行时通过专家系统传递的不同组件id，选择不同的智能组件运行。

e，智能组件在注册到组件管理服务器上后，在组件库里保存对应的组件的位置，以利于容器在运行时加载相应的组件，组件管理服务器和容器服务器应是同一个机器，否则加载智能组件时就需要通过网络下载，而下载的组件和本地的组件拥有的运行权限（比如访问非托管资源的权限）不同，有可能不能正常提供推理功能。

在专家系统开发阶段，开发人员需要查询可用的知识库和组件。

如果没有找到，二次开发人员需要开发相应的知识库和组件，知识库和智能组件需要注册到相应的服务模块才能使用。

需要进行如下工作：
对于自定义开发的智能组件：需要将其上传到组件管理服务中，并进行注册，注册时要提供足够详细的元数据信息，注册后产生一个组件id，保存在组件库中；
对于自定义开发辅助组件：包括输入界面组件，输出界面组件，推理过程显示组件等，需要注册到组件库中，使用时需要下载到本地。

对于自定义开发的知识库：1，知识访问中间件定义一套规范，用户可以使用自己的知识库开发工具或本系统提供的知识库开发工具开发满足规范的知识库（使用本系统的知识库开发工具开发的知识库其形式自然满足规范），这样可以进行不同知识表示形式之间的转换。

2，如果用户有其他需要（用户拥有需要不满足规范的特殊知识表示形式的推理机组件，但没有相应表示形式的知识库），可以开发自定义表示形式的知识库（不满足规范），同时用户需提供相应的知识库操作Web服务，根据需要（用户具有特殊表示形式的知识库，但没有对应
的推理机，想使用本平台现有的推理机）用户可以开发自己的知识格式转换工具。

2，对知识库的所有操作封装为Web服务的形式，并注册到知识目录服务中。

说明，a，容器中间件系统定义一些组件的规范，用户自己开发的智能组件需要满足相应的规范（比如，必须提供一系列与界面无关的接口，对智能组件的访问可以只通过接口进行）才能扩充到容器中间件中。

同样，专家系统开发平台也提供一组辅助组件规范（例如，一系列标准接口API，也可能需要将辅助组件做成自定义控件形式等），用户开发的界面组件应满足规范才能在开发平台中使用。

b，在知识访问中间件中，知识库以及知识库操作web服务由知识的所有者维护，如果知识库格式不规范，同领域的其他表示形式的知识库也由用户自己开发。

容器中间件架构
容器中间件是运行执行环境中的核心中间件，用于容纳、管理和运行实现智能逻辑的组件。

容器中间件提供两个基本服务：组件管理服务和组件运行服务。

组件管理服务架构
组件注册：提供本地或远程容器中组件的信息登记功能；本地组件（和组件管理服务器在一台机器上的组件）直接登记信息，远程组件则需要上传到组件管理服务器上并登记信息。

登记的信息至少应包括：组件注册时产生的唯一id（用来唯一地标识一个组件），组件的名字，组件所在的目录（用于容器中间件找到组件并加载），组件的说明（如，该组件适合何种类型的知识库，输入输出为何种类型，等），组件的元数据，组件的运行状态信息。

不但提供智能组件的注册，还提供辅助组件的注册。

其中辅助组件可被下载。

组件分类：安装某个分类标准提供已登记组件的分类功能，目的是提高组件查询的速度。

例如，用户可能想使用基于规则的推理机进行，希望能列出所有基于规则的推理机组件。

这里的分类标准可以不止一个，方便用户从不同的视点查询可用的组件。

组件查询：提供本地或远程容器中已注册组件的查询、定位功能。

开发阶段主要返回组件的元数据列表，供开发人员参考了元数据列表之后对组件进行选择。

运行阶段供容器准确地定位并加载组件。

组件元数据管理：包括对组件元数据信息的更新。

组件库管理：入库：注册的组件复制到本地某个目录；删除组件；更新组件：替换掉组件，同时更新组件的相关数据；
组件部署：
组件配置：
说明，组件管理服务应提供一套组件库维护工具，用于注册、更新和删除组件。

组件运行服务架构
如图4，
智能组件集：包括各种智能组件，如规则推理机组件，粗机算法组件，格机算法组件，贝叶斯网推理机，决策树算法组件等。

智能组件受组件管理服务管理，运行时由容器加载。

每个智能组件都是一个业务组件，是设计、实现、部署、维护和管理的主要单元。

业务组件封装业务逻辑（也称业务规则），这些规则约束业务概念的行为以匹配特定的需要。

业务工作流组件：业务流程组件形成了它自己的类：业务工作流组件。

业务流程反映了业务执行的宏观级别的活动，例如，接受专家系统的请求及参数后，进行的一次推理的过程。

可以使用任何.NET语言开发自定义的业务工作流组件。

业务实体组件：业务实体是数据容器，封装并隐藏特定数据表示格式的细节。

业务和业务工作流组件可以与独立的业务实体组件交互，或者使用业务实体以便设置它们自己的状态，然后丢弃该业务实体。

业务实体通常用作Data Transfer Objects。

数据访问组件通常返回业务实体，而不是数据库特有的结构。

这非常有利于将数据库特有的细节隔绝于数据层中。

服务接口：容器将它的部分功能作为其他应用程序可以使用的服务进行公开。

服务接口将该服务呈现给外部世界，它隐藏实现细节，并只公开粗粒度的业务接口。

这里使用XML Web Service实现。

数据访问组件：将业务层与特定数据存储解决方案的细节隔离开。

这里的数据存储解决方案主要包括文件系统和数据库系统。

利用数据访问中间件提供数据库访问服务，这里采用访问不同类型的数据库。

安全服务：可以采用身份验证的方式进行用户身份验证，同时提供用户/用户组机制（类似基于角色的安全性机制）和对组件的访问控制功能。

通过容器安全验证的请求才能转发给智能组件处理。

协作组件：调度智能组件之间的协作，以协作完成推理或者对多个推理结果进行综合。

通信：利用通信中间件实现容器中各活动部件之间的通信活动，包括：本地组件之间和组件与容器之间的通信，主要是智能组件之间进行协作需要的通信；容器与其他容器之间的通信主要是负载平衡和容错服务需要的通信。

HTML/XML生成：将结果序列化为XML格式，利于网络传输和数据交换。

事务管理：智能组件使用COM+中的事务处理功能。

实例池：智能组件使用COM+中的对象池服务。

连接池：目的是提高数据库访问效率，节省数据库连接资源。

线程池：提高容器智能组件的使用效率。

生命周期管理：负载组件的加载、卸载、持久化等操作。

状态和会话管理：提供在同一用户会话过程中多次请求之间维护有关状态数据的功能。

Web 服务本来是无状态的，因为我们的Web服务是在中运行，所以可以使用 提供的状态管理服务。

负载平衡：用户的请求经过验证后，由负载平衡服务器转发给最空闲的服务器上的容器，并将该服务器地址与客户请求绑定，以后客户将直接与那台服务器上的容器通信，直到任务处理完成。

失败恢复：失败恢复机制提供容错性，如果一台服务器变得不可用，则另一台服务器自动接管发生故障的服务器并继续处理任务。

运行流程：
（1），容器接收到专家系统的推理请求以及相关的参数。

（2），容器对客户进行身份验证和授权，未通过则拒绝进一步的服务，返回错误信息。

（3），通过验证和授权后，容器将请求转发给相关的业务工作流组件。

（4），每个业务工作流组件按照各自工作流程加载并调度相应的智能组件，执行业务逻辑（这里就是推理过程），并缓存执行结果（可以将结果持久化）。

在这个过程中，可能会用到一些运行时服务，如事务处理，线程池，连接池，数据服务等。

（5），如果客户请求多个组件进行协作处理，则容器将请求转发给相关的协作处理组件。

（6），协作组件读取各工作流程组件缓存的推理结果，进行协作处理（例如,一种协作方式是对结果进行综合），并缓存结果。

（7），容器响应客户请求，返回相关输出。

说明，a，业务工作流组件类似智能组件的facade，加上这一层组件，可以对智能组件的接口做较少的要求（例如，智能组件只需要是跟界面无关的，输入输出使用xml流或者xml 文件等方式），可以减少已有智能组件的接口修改工作，甚至不改变已有智能组件的接口，
还可以对容器传来的参数进行类型验证，可以调用结果缓存服务减少实际的推理次数。

考虑负载平衡的运行流程：
（1）设置一个负载平衡服务器，专门进行负载平衡调度，服务器上维持一个负载地址列表，保存其他各个业务服务器的ip地址以及每台服务器的负载情况和最大负载。

该服务器同时具有安全验证功能，对用户身份进行验证，通过验证的请求转发到下一个服务器，否则拒绝。

（2）客户发来请求，经过负载平衡服务器的时候，负载平衡服务器进行负载平衡调度，将请求转发给负载最轻的业务服务器（智能组件所在的服务器，处理用户请求）处理。

客户接受处理请求的前后应修改负载地址列表上自己的负载信息。

（3）业务服务器处理后的结果再经由安全服务器和负载平衡服务器转发给客户。

考虑容错性
对负载平衡服务器设一个备用服务器，备用服务器使用心跳机制，定时请求主服务器响应，如果连续几次没有响应，则认为主服务器出现故障，备用服务器自动接管主服务器的任务，同时向管理员发出警告消息，由管理员及时排除故障恢复主服务器。

对业务服务器群不设备用服务器，由负载平衡服务器定时检测各个业务服务器是否活动，如果发现某个业务服务器发生故障，则向管理员发出警告，同时将该地址排除在负载地址列表外，在负载平衡调度时要保证所转发的业务服务器是活动的。

负载平衡实现方案2：
如图，
将负载平衡功能放到Web服务器端（开发出的专家系统是在web服务器上运行的，可以在多台服务器上部署容器中间件，这样就可以对每台服务器发布一次web服务，专家系统可以在运行时修改web服务代理类中的URL，选择不同服务器上的web服务，达到负载平衡的目的），容错服务留在应用服务器端。

知识访问中间件
知识目录服务：知识目录服务提供注册、分类、发布和查询知识库操作web服务的功能。

由知识库的所有者实现相应的Web服务，对每一个知识库的所有操作都封装在一个Web服务类（我们称其为知识库操作web服务）里面，然后知识库的所有者将该Web服务注册到
知识目录里面，也就是说，通过知识目录服务可以查询到的不是知识库本身，而是封装了知识库所有操作的Web服务类。

知识库的使用者可以查询和调用web服务的接口，知识库的所有者还有权限注册、发布、更新其web服务，知识目录服务则在知识库操作web服务进行注册时可以对其进行分类。

注册服务提供知识库操作web服务的信息登记功能。

分类服务将已登记的知识库进行分类，便于进行知识表示形式的转换（开发知识访问中间件时对一些典型的知识表示形式定义一些规范，这些知识表示形式有基于规则的，贝叶斯的等，其目的在于便于进行不同知识表示形式之间的转换，遵守规范的知识表示形式可以由知识访问中间件提供的转换工具进行转换）。

发布服务向其他系统（例如，专家系统开发平台，开发时）暴露知识库的访问接口，这里是通过Web服务的形式暴露的。

查询服务提供已注册的知识库操作web服务的查询定位功能，并将查询到的结果返回。

远程知识库访问服务：由于使用了Web服务的实现方法，对客户来说，知识库都是远程访问的。

具体的知识库可以存放于文件系统或数据库系统中，对知识库的物理访问由知识库的所有者实现并封装，对客户透明。

这里的客户是开发平台和智能组件。

异构知识库访问服务：知识的表示形式有很多种，一个推理机往往只支持一种知识表示形式，如果知识库中没有合适表示形式的知识，需要将其他表示形式的知识转换为推理机需要的形式的知识。

在我们的知识访问中间件中，提供一个知识库转换工具，并定义一组规范，对一些典型的知识表示形式分别定义了规范，满足这些规范的知识表示形式之间可以互相转换，否则不能，这时就需要知识库的所有者自己创建并编辑相应表示形式的知识库文件。

说明，知识访问中间件提供一套知识库开发工具，包括知识获取工具和知识维护工具。

知识访问中间件架构图：
说明
规范集合：
[1]KBUDDI规范
该规范即知识目录服务中的查询API和发布API遵循的规范。

该规范用xml语言描述，其中查询操作和发布操作都实现为Web服务，供知识库提供者和知识库使用者调用。

[2]知识库操作Web服务规范
该规范即知识库所有者所提供的、对其拥有的知识库进行操作的Web服务应该遵循的接口规范。

该规范根据智能应用系统访问知识库的需要来确定，它是满足智能应用系统访问知识时所需要的最小的操作集合，即只有提供该规范中规定的所有的知识库操作Web服务，才能满足智能应用系统对知识的需要。

[3]知识库XML文件结构规范
该规范即知识库所有者所提供的知识库操作Web服务返回给智能应用系统的知识库（或者说是知识库文件）应该遵循的规范。

所返回的知识库XML文件只有遵循该规范中规定的组织格式，才能够被本智能应用系统有效使用。

1．知识库所有者可以通过知识目录服务中的发布API来发布它所拥有的知识库的描述信息及相关的知识库操作Web服务的信息。

发布包括增加、修改和删除。

2．知识库所有者可以通过知识目录服务中的查询API来查询与知识库相关的所有信息3．知识使用者可以通过知识目录服务中的查询API来查询它所需要的知识库的所有信息
4．知识使用者根据上一步（第3步）查询的结果，调用与满足其需要的知识库相关的知识库操作Web服务，来获得其需要的知识
5．当通过第4步所获得的知识库的知识表示形式不能满足其需要时，可以通过调用“异构知识库访问服务”，将该知识库转换为满足其需要的知识表示形式。

这在一定程度上可以说屏蔽了知识库的异构性。

分类服务：在知识目录服务中提供分类服务，对发布其中的知识库进行有效的分类。

远程知识库访问：知识访问中间件采用Web服务的方式访问知识库。

基于Web服务本身的特点，不论是访问本地的知识库还是访问远程的知识库，对于知识使用者来说没有什么不同，其访问方式都是一样的。

这在一定程度上可以说屏蔽了知识库的分布性。

API的提供
提供如下API
1，组件管理服务API，提供组件查询注册更新等功能，开发阶段可以查到可用的组件（Web Service或Remoting方式），运行阶段可以加载本地对应的组件（API调用方式）。

2，容器中间件组件服务API，接受专家系统的请求并返回智能组件的运算结果，运行阶段。