一种基于AnGo动态演化模型的Web系统开发可复用方法

技术领域

本发明属于Web系统开发技术领域，涉及一种对Web系统开发的可复用方法

背景技术

随着Web技术的广泛应用，Web开发也成为了当前软件开发的热点。针对Web应用需求的日益增长，快速开发高质量的Web应用系统，成为业界研究的一大热点问题。然而随着系统业务复杂度的增加，要求Web应用在兼顾开发效率的情况下，应具有更高的可靠性、易维护性和扩展性。传统开发方式存在着业务耦合度高、分层不明确、难以维护和复用等缺陷。在这种背景下，一些开源的框架应用而生，例如以数据流程控制为核心任务的表示层框架(Struts、SpringMVC、WebWork等)；以事务管理为核心任务的控制层框架(Spring)；以数据操作为核心任务的持久化框架(Hibernate、MyBatis、TopLink等)。其中表示层框架中以Struts最为流行，已逐渐成为了该领域的“工业标准”，目前已发展到第二代产品。Struts以MVC模式为核心，强调将应用的开发分为视图、控制和模型三部分，并且为视图(View)和控制(Controller)两个部分提供了实现组件。但struts的Taglib较为复杂，学习成本较大，ActionForms使用不便，无法进行单元测试。Spring是为了解决企业应用开发的复杂性而创建的，主要优势之一就是其分层的架构，分层架构允许使用者选择使用哪一个组件，同时为J2EE应用程序开发提供集成的框架。但Spring开发成本较高，稍显臃肿。在持久化框架中以Hibernate最为优秀，它可以充当模型(Model)组件，能够代替JDBC实现数据持久化的任务。但它由于使用ORM原则，导致配置过于复杂。另外，Hibernate在批量数据处理时有弱势，对于批量的修改，删除，不适合用Hibernate。除了上述流行的Java Web框架外，PHP、Ruby等语言也有其流行的框架，例如Laravel和Ruby on Rails。Laravel是一套简洁、优雅的PHP Web开发框架，富于表达力。Ruby on Rails则拥有较高的开发效率。但以上框架在处理传统业务需求时，服务器端仍旧离不开大量编码，当传统业务需求纷杂的时候，开发工作量较大。

持续变化的需求对开放环境下软件系统的灵活性和可伸缩性提出了较高的要求。在许多情况下，需要系统中能够发生变化的位置、变化的程度等可以被动态调整，即要求软件的运行时可变性是可以动态演化的。为解决此问题，国防科技大学的刘吉伟、毛新军提出了元变机制以支持对可变性要素数量、属性、关系的改变；又利用可变性对象实现了对这些操作的封装和信息隐藏，使人们在关注高层的可变性模型变化时无须考虑可变性要素的异构性等细节。在利用Agent技术实现软件系统自适应演化的研究中，IBM公司研制的基于Java的Agent开发部署环境——ABLE(agent building and learning environment)提供了由智能推理、学习构件包与构造智能Agent的框架构成的开发库，但该框架假定所开发的系统是静态和封闭的，无法满足开放环境下自适应系统的开发。针对分布式软件系统在动态演化中面临的原有软件单元难以重用、忽视软件内部运行状态和用户意愿变更引发的演化需求等问题，西安电子科技大学的李青山、王璐等人提出了一种基于智能体技术的软件自适应动态演化机制。但该机制仍处于验证阶段，机制中各种算法有待完善，其性能也有待进一步验证。

发明内容

为了克服现有的Web系统开发方法的不可复用、服务器端代码开发工作复杂、软件生产效率较低的不足，本发明提供一种对Web系统开发的可复用、提高软件生产效率、极大减少服务器端人工编码、提高了软件开发的质量的基于AnGo动态演化模型的Web系统开发可复用方法，基于AnGo动态演化模型，采用多Agent技术，根据预配置的WRDLPool，实时监听上下文环境，实现对元Agent的动态装配以完成用户交付的任务。该方法能适应多样的应用需求以及持续变化的互联网环境，并能以一种自发、动态的组件装配机制来有效的满足用户需求，极大简化了服务器端的代码开发工作。

本发明所采用的技术方案是：

一种基于AnGo动态演化模型的Web系统开发可复用方法，包括以下步骤：

第一步、建立一个基于AnGo的动态演化模型，分为视图层、控制层和组件层。

1.1、视图层(view layer)：负责数据模型的相互转化，在任务请求阶段，视图层将用户提交的可视化数据转化为符合AnGo模型标准的JSON数据媒介，并传送给控制层；在请求响应阶段，视图层将控制层处理的数据结果转化为可视化数据模型，以便用户进行直观理解。视图层并不依赖具体的技术架构，但需要遵循AnGo模型的接口标准，即以JSON数据为媒介，并通过契约方式与控制层交互以保证请求的唯一性。契约是一种前后端开发的约定，在AnGo模型中，将用户向服务器端发送的每个请求视为一种需求任务，视图层会对每种功能需求嵌入契约值来保证其能被控制层唯一解析执行，因此该契约值具有唯一性，不同用户如果发送同一种契约到控制层，可视同为执行一组相同的功能，差别仅在于输入参数有所不同。

1.2、控制层(controller layer)：负责路由的转发、WRDL配置信息的解析、元Agent的动态装配、任务的执行以及与表现层的通讯，并能根据表现层触发的事件执行相应的动作。

控制层包含的模块有：

决策Agent：任务处理的枢纽，由路由Agent、调度Agent和执行Agent三个子Agent协调处理完成。它接受视图层发送的请求，根据内存池(MemoryPool)中的配置信息，从组件层中筛选出符合特定要求的元Agent进行按序装配，并将处理结果返回至视图层。决策Agent的构成如下：

路由Agent：负责根据请求内容进行路由选择，并将选择结果及请求内容发送至执行Agent。

执行Agent：负责接受路由信息，调用契约值并通知调度Agent完成其相应工作。在接受AgentChain后，负责流水化执行AgentChain，并将处理结果返回至视图层。

调度Agent：负责调度元Agent，并将元Agent组装为AgentChain返回至执行Agent。

WRDLPool：配置文件池，由WRDL(Web Requirement Description Language)语言编写。WRDL并非是一种真正的语言，其含义是一种基于AnGo模型的用户需求转换规则，程序员把每个功能点的个性化需求以及每个元Agent所具有的功能一一对应，通过WRDL语言描述在XML文档上，在程序动态执行时，语义理解Agent进行解释并内存化，存储到MemoryPool中，以作为整个模型动态运行的全局决策依据。

MemoryPool(内存池)：存储WRDLPool语义理解后的信息，在内存中由特定数据结构存储。

语义理解Agent：对WRDL语言编写的XML文档进行语义理解，并将解释的结果存储到MemoryPool中。

监听Agent：每隔一段时间对WRDLPool进行监听，当监听的信息发生变化时，监听Agent会通知语义理解Agent更新WRDL语义，并将最新内容发送到MemoryPool中。

AgentChain：由一系列元Agent按顺序组成，具有完成特定功能的Agent链。

监测Agent：对所有的数据增加、删除、修改操作记录进行追踪，并写入到持久化文件中，在数据库损坏或者管理员误操作等情况下，可以方便地将数据库还原到任意时间点。

异常处理Agent：在异常发生后会进行反向追踪，解析用户的访问路径，分析用户的userAgent、session等上下文环境，收集内存堆栈异常信息等。当发生错误时，提供了人性化交互，不仅生成错误日志以供开发人员查看，还会将前台页面跳转至Error页面向用户显示错误的简要信息和相关的建议。

1.3、组件层(component layer)：负责为调度Agent提供一系列具有基本功能的处理单元。

组件层包含的模块有：

AgentCluster：由大量元Agent组成的无序Agent簇，包含CRUDCluster(由负责数据库增删改查的元Agent组成)、IOCluster(由负责文件输入输出操作的元Agent组成)和MailCluster(由负责邮件收发操作的元Agent组成)等。每个Cluster由一组通用操作的元Agent集合构成。

AgentCenter：Agent中心，对AgentCluster进行实时感知，负责管理元Agent的注册及注销。

元Agent：具有最小执行功能的处理单元，新的元Agent可向AgentCenter进行注册，从而获得参与调度Agent动态装配的资格。

元Agent将用户需求分类成若干功能集合，每个集合内都对应了一种通用的功能需求操作，并由对应元Agent管理。即元表示元Agent到某种功能集合的映射。

第二步、基于所述的模型，提出的Web系统开发可复用方法如下：

2.1：采用元Agent自更新机制将拥有基本功能的元Agent注册到AgentCluster中，或者将已经废弃的元Agent从AgentCluster中注销。该机制的设立主要是为了使得元Agent注册与注销变得及时、有序，进而使得WRDL Pool时刻保持最新。

2.2：采用惰性加载机制加载WRDLPool配置信息。即在程序启动阶段将WRDLPool中的所有配置信息装载到MemoryPool中，来提高配置信息的搜索速度，之后仅在WRDLPool状态发生变化时，才将改变的信息同步到MemoryPool中，以缩短配置加载时间。

2.3：前端发送请求，决策Agent采用内部协作机制处理用户请求，根据MemoryPool中的配置信息，从AgentCluster中筛选出相应的元Agent组装成AgentChain。互联网环境是动态不确定的，这使得Web系统开发也具有了一定的不确定性。为了确保AnGo模型能提供相对明确和稳定的系统级别可复用开发能力，单一的元Agent无法完成多个相互交互的复杂任务。因此，就需要多个元Agent间通过协同的方式来实现对用户需求的解析、处理和资源提供。AnGo模型通过AgentChain来完成这一协作任务，这既提高了软件开发的效率，同时也确保了软件质量，因为Agent Chain中的每一个元Agent在加入前都必须保证是可用、可靠的，并已经通过软件测试。Agent Chain基于元Agent，能够根据环境和需求的变化而变化，它也是确保AnGo系统内各个组件的生存能力的重要方式。决策Agent按序执行该AgentChain即可完成用户交付的任务请求。具体过程如下：

2.3.1)请求响应阶段：首先，前端向路由Agent发出请求，决策Agent接受请求并经过处理后，通过执行Agent将处理结果返回前端。

2.3.2)路由选择阶段：路由Agent接受前端发出的请求，根据请求内容的路径参数转发路由，并将路由选择结果及请求内容发送至执行Agent。执行Agent接受路由Agent传递的信息，将请求内容发送至调度Agent并通知其完成相应的工作。

2.3.3)Agent调度阶段：调度Agent收到执行Agent通知后，根据请求内容从MemoryPool中抽取相应的配置片段，按照片段中的信息前往组件层筛选出与配置相吻合的元Agent，筛选出的Agent会动态感知上下文环境，对自身的先后顺序做出调整并组成一条Agent链(AgentChain)返回至执行Agent。

2.3.4)执行监控阶段：执行Agent按序执行接受的AgentChain，同时异常处理Agent和监测Agent将全程监视AgentChain中每个元Agent的运行过程。

进一步，为了支持决策Agent的动态调度和具有动态多样性需求的请求，提出了决策Agent内部协作机制，该机制使得决策过程更加协调、高效，机制的运作流程如下：

路由Agent包含：解析单元、转发单元

执行Agent包含：协作单元、运行单元

调度Agent包含：查询单元、装配单元、通知单元

1.2.1.前端向解析单元发送Request请求；

1.2.2.解析单元解析出请求路径和请求参数Profile传递给转发单元,请求参数Profile包含契约值和前端表单项、上下文环境；

1.2.3.转发单元根据路径参数进行路由选择，如果成功解析路由，则将路由和请求参数传递给运行单元；如果无法解析路由，则返回False；

1.2.4.运行单元加载路由，此时由于缺少AgentChain，无法执行任务。

因此，运行单元会请求协作单元进行协调；

1.2.5.协作单元将请求参数继续传递给查询单元；

1.2.6.查询单元根据请求参数Profile中的契约值前往MemoryPool进行查询；

1.2.7.返回查询结果；

1.2.8.如果能查询到契约值所唯一对应的Config配置片段，所述Config配置片段包括用户的个性化需求以及元Agent到通用功能集合的某条映射，查询单元会将Config传递给装配单元；如果查询不到，查询单元则会返回False；

1.2.9.装配单元根据Config配置片段前往Agent Cluster查询相应的元Agent，如果在Agent Cluster中能找到配置片段中的所有元Agent，装配单元会将查询到的所有元Agent按顺序组成一条Agent Chain并返回给运行单元，执行步骤1.2.10；如果无法找到所有的元Agent，则会调用通知单元，执行步骤1.2.11；

1.2.10.执行单元装载接受的Agent Chain，此时由于执行单元已经成功加载路由，满足任务运行的条件，AgentChain中的每个元Agent会按顺序流水化执行，并将执行结果返回至前端；

1.2.11.通知单元通知Agent Center完成其相应工作；

1.2.12.Agent Center更新WRDLPool，移除过期的元Agent配置信息；

1.2.13.将WRDLPool的最新配置储存到MemoryPool中。

再进一步，为了支持决策Agent内部协作机制，设计了决策Agent内部协作算法，它是决策Agent运行的核心和决策依据。该算法描述了决策Agent内部如何通过协作的方式实现对任务请求的有序处理。算法流程如下：

输入：请求request，AgentCluster＝{元Agent₁,元Agent₂,…,元Agent_n}

输出：响应response

1.从request中解析出URL

2.根据URL进行路由转发

3.若根据URL找不到正确路由，则返回错误

4.从request中解析出请求参数profile

5.根据profile从Memory Pool中查询配置片段config

6.若查询不到config，则返回错误

7.对于所有Agent_i，其中Agent_i为配置片段config中配置的元Agent，若Agent_i在Agent>i添加到Agent>

8.路由执行Agent Chain

9.返回response

再进一步，步骤2.1)中，元Agent自更新机制的设立主要是为了使得元Agent注册与注销变得及时、有序，进而使得WRDL Pool时刻保持最新；该机制更加适用于以下几种状况：

AgentCluster中的元Agent呈现为混乱的或者无序状态

新的元Agent被注册到AgentCluster

过期的元Agent从AgentCluster中注销

步骤2.1)中，元Agent自更新机制的运行过程如下：

2.2.1)元Agent监控阶段：该阶段，AgentCenter将根据WRDLPool中的AgentCluster配置信息对元Agent及其环境状态进行监控。当所监视的信息发生变化时，Agent Center会将这些变化的信息更新到WRDLPool中。

2.1.2)AgentCluster动态更新：元Agent首先被开发者注册到AgentCluster中，之后，AgentCluster会向AgentCenter登记该元Agent的信息，AgentCenter确认元Agent基本功能信息无误后，将该元Agent及其功能语义更新到WRDLPool中；另一种情形，过期的元Agent被开发者从AgentCluster中废弃，之后，AgentCluster会向AgentCenter注销该元Agent的信息，然后AgentCenter将该元Agent及其功能语义从WRDLPool中移除。

所述步骤2.2中，采用惰性加载机制加载WRDLPool配置信息的过程是：

2.2.1)WRDL监控阶段：监听Agent每隔一段时间对WRDLPool进行监听，当监听的信息发生变化时，监听Agent会通知语义理解Agent更新WRDL语义，并将最新内容发送到Memory Pool中；

2.2.2)WRDL语义理解：在程序启动阶段，语义理解Agent会解释WRDLPool中的XML配置文件，并将解释的结果存储到MemoryPool中；另一种情形，当监听Agent监测到WRDLPool发生变化时，会命令语义理解Agent对变化的内容进行语义分析，并将最新的配置信息同步到MemoryPool中。

本发明的优点是：(1)通用性需求一般都可通过WRDL语言以配置的方式进行发布，由AnGo模型自动演化执行，提高了软件生产效率。(2)用户请求全部交由决策Agent自动组装元Agent完成，极大减少服务器端人工编码，提高了软件开发的质量，从而保证服务器端的稳定。(3)元Agent的注册、注销通过自更新的方式完成，实现了系统功能的实时添加与删除，增强了系统的动态演化能力。(4)采用惰性加载机制将WRDL描述的需求内容存入MemoryPool中，缩短系统配置时间，加快搜索速度，减少服务器响应时间，提升了用户满意度。(5)基于AnGo动态演化模型的开发方法遵循“二八法则”，即通用软件80％的功能基本为常见功能，可快速配置实现，提高面向产品族的软件批量化生产能力。

附图说明

图1示出了模型框架图。

图2示出了元Agent更新及WRDL加载时序。

图3示出了WRDL文档的XML Scheme结构。

图4示出了Agent决策时序。

图5示出了决策Agent内部协作机制。

具体实施方式

下面结合附图对本发明作进一步描述。

参照图1～图5，一种基于AnGo动态演化模型的Web系统开发可复用方法，包括以下步骤：

第一步、建立一个基于AnGo的Web开发动态演化模型，模型按照分层架构思想设计，如图1所示，分为View(视图层)、Control(控制层)和Component(组件层)。

1.1、View(视图层)：负责数据模型的相互转化，在任务请求阶段，视图层将用户提交的可视化数据转化为符合AnGo模型标准的JSON数据媒介，并传送给控制层；在请求响应阶段，视图层将控制层处理的数据结果转化为可视化数据模型，以便用户进行直观理解。视图层并不依赖具体的技术架构，但需要遵循AnGo模型的接口标准，即以JSON数据为媒介，并通过契约方式与控制层交互以保证请求的唯一性。契约是一种前后端开发的约定，在AnGo模型中，将用户向服务器端发送的每个请求视为一种需求任务，视图层会对每种功能需求嵌入契约值来保证其能被控制层唯一解析执行，因此该契约值具有唯一性，不同用户如果发送同一种契约到控制层，可视同为执行一组相同的功能，差别仅在于输入参数有所不同。

1.2、Control(控制层)：负责路由的转发、WRDL配置信息的解析、元Agent的动态装配、任务的执行以及与表现层的通讯，并能根据表现层触发的事件执行相应的动作。

控制层包含的模块有：

决策Agent：任务处理的枢纽，由路由Agent、调度Agent和执行Agent三个子Agent协调处理完成。它接受视图层发送的请求，根据内存池(MemoryPool)中的配置信息，从组件层中筛选出符合特定要求的元Agent进行按序装配，并将处理结果返回至视图层。决策Agent的构成如下：

路由Agent：负责根据请求内容进行路由选择，并将选择结果及请求内容发送至执行Agent。

执行Agent：负责接受路由信息，调用契约值并通知调度Agent完成其相应工作。在接受AgentChain后，负责流水化执行AgentChain，并将处理结果返回至视图层。

调度Agent：负责调度元Agent，并将元Agent组装为AgentChain返回至执行Agent。

WRDLPool：配置文件池，由WRDL(Web Requirement Description Language)语言编写。WRDL并非是一种真正的语言，其含义是一种基于AnGo模型的用户需求转换规则，程序员把每个功能点的个性化需求以及每个元Agent所具有的功能一一对应，通过WRDL语言描述在XML文档上，在程序动态执行时，语义理解Agent进行解释并内存化，存储到MemoryPool中，以作为整个模型动态运行的全局决策依据。

MemoryPool(内存池)：存储WRDLPool语义理解后的信息，在内存中由特定数据结构存储。如JAVA语言就可以用JavaBean来完成对WRDL语言配置文档的映射。

语义理解Agent：对WRDL语言编写的XML文档进行语义理解，并将解释的结果存储到MemoryPool中。

监听Agent：每隔一段时间对WRDLPool进行监听，当监听的信息发生变化时，监听Agent会通知语义理解Agent更新WRDL语义，并将最新内容发送到MemoryPool中。

AgentChain：由一系列元Agent按顺序组成，具有完成特定功能的Agent链。

监测Agent：对所有的数据增加、删除、修改操作记录进行追踪，并写入到持久化文件中，在数据库损坏或者管理员误操作等情况下，可以方便地将数据库还原到任意时间点。

异常处理Agent：在异常发生后会进行反向追踪，解析用户的访问路径，分析用户的userAgent、session等上下文环境，收集内存堆栈异常信息等。当发生错误时，提供了人性化交互，不仅生成错误日志以供开发人员查看，还会将前台页面跳转至Error页面向用户显示错误的简要信息和相关的建议。

1.3、Component(组件层)：负责为调度Agent提供一系列具有基本功能的处理单元。

组件层包含的模块有：

AgentCluster：由大量元Agent组成的无序Agent簇，包含CRUDCluster(由负责数据库增删改查的元Agent组成)、IOCluster(由负责文件输入输出操作的元Agent组成)和MailCluster(由负责邮件收发操作的元Agent组成)等。每个Cluster由一组通用操作的元Agent集合构成。

AgentCenter：Agent中心，对AgentCluster进行实时感知，负责管理元Agent的注册及注销。

元Agent：具有最小执行功能的处理单元，新的元Agent可向AgentCenter进行注册，从而获得参与调度Agent动态装配的资格。

元Agent将用户需求分类成若干功能集合，每个集合内都对应了一种通用的功能需求操作，并由对应元Agent管理。即元表示元Agent到某种功能集合的映射。如数据插入数据库操作是软件系统的一种通用功能，AnGo模型提供元Agent_insert来负责此种需求，对应数据插入操作，可能不同用户又有其差异性，如用户A需要往表x插入1条数据，用户B则需要往表y插入100条，而用户C需要在在表x中插入1条数据后，进行级联操作，再继续往表y插入100条数据。不同插入操作间的变化性通过WRDL语言进行配置描述，然后由Agent_insert统一负责处理，Agent_insert在处理过程中将根据WRDL需求描述信息来进行差异化处理。

第二步、基于所述的模型，提出的Web系统开发可复用方法如下：

2.1：采用元Agent自更新机制将拥有基本功能的元Agent注册到AgentCluster中，或者将已经废弃的元Agent从AgentCluster中注销。该机制的设立主要是为了使得元Agent注册与注销变得及时、有序，进而使得WRDL Pool时刻保持最新。该机制更加适用于以下几种状况：

AgentCluster中的元Agent呈现为混乱的或者无序状态

新的元Agent被注册到AgentCluster

过期的元Agent从AgentCluster中注销

元Agent自更新机制的运行过程如下，如图2所示，该机制分为元Agent监控阶段和AgentCluster动态更新阶段：

2.1.1)元Agent监控阶段：该阶段，AgentCenter将根据WRDLPool中的AgentCluster配置信息对元Agent及其环境状态进行监控(1.1perceive())。当所监视的信息发生变化时，Agent Center会将这些变化的信息更新到WRDL Pool中。

2.1.2)AgentCluster动态更新：元Agent首先被开发者注册到AgentCluster中(1.2register())，之后，AgentCluster会向AgentCenter登记该元Agent的信息(1.3enrol())，AgentCenter确认元Agent基本功能信息无误后，将该元Agent及其功能语义更新到WRDLPool中((1.4update()))；另一种情形，过期的元Agent被开发者从AgentCluster中废弃(1.2discard())，之后，AgentCluster会向AgentCenter注销该元Agent的信息(1.3cancel())，然后AgentCenter将该元Agent及其功能语义从WRDLPool中移除(1.4update())。

2.2：采用惰性加载机制加载WRDLPool配置信息。即在程序启动阶段将WRDLPool中的所有配置信息装载到MemoryPool中，来提高配置信息的搜索速度，之后仅在WRDLPool状态发生变化时，才将改变的信息同步到MemoryPool中，以缩短配置加载时间。

如图2所示，该机制分为WRDL监控阶段和WRDL语义理解。具体过程如下：

2.2.1)WRDL监控阶段：监听Agent每隔一段时间对WRDLPool进行监听(2.1listen())，当监听的信息发生变化时，监听Agent会通知语义理解Agent更新WRDL语义，并将最新内容发送到MemoryPool中。

2.2.2)WRDL语义理解：在程序启动阶段，语义理解Agent会解释WRDLPool中的XML配置文件(2.3analyze())，并将解释的结果存储到MemoryPool中(2.4store())；另一种情形，当监听Agent监测到WRDLPool发生变化时，会命令语义理解Agent(2.2call())对变化的内容进行语义分析(2.3analyze())，并将最新的配置信息同步到MemoryPool中(2.4store())。

WRDL描述的是一种配置规则，和WebService中的WSDL等描述语言相似，其载体AnGo框架选择了XML文件，XML的结构使其能具有良好的扩展性，也更利于Agent体现出动态自适应。通过扩充XML的原始结构，能赋予AnGo框架更多功能。

WRDL语言的本质是写出AnGo框架能理解的描述文件，同时该描述文件能让系统开发人员也便于理解。WRDL把用户需求归为以下七大类：数据浏览(browse)、数据删除(delete)、数据增加(insert)、数据更新(update)、数据导入(import)、数据导出(export)、其他业务逻辑(query)，并对应到xml载体中。

WRDL的基本结构如图3所示，对应的XSD描述格式如下：

WRDL元素说明如表1所示：

表1

WRDL的基本语法为:

1.写入element元素，每一个element代表了一种功能需求

2.element元素加入flag属性，flag映射为AnGo模型的契约，类似于数据库的主键，是唯一的，在每一份XML文件中，契约名称不能重复，并且是前后端交互时必须遵循的。

3.element元素下含子元素sql，其中最重要的属性是value，里面是计算机能执行的sql语句，WRDL把sql语句和功能需求对应起来，并交给决策Agent存储与选择执行

4.sql元素下含子元素param，每一个param元素代表了功能需求的一项输入参数，决策Agent根据WRDL，来决定输入参数是来自客户端，还是来自服务器端session作用域、requet作用域或其他域，并进行自动提取与验证、转化

5.struct元素：和param元素平级，每一个struct元素代表了当前sql语句的一个缺省值，可以在sql语句的任意位置缺省，决策Agent根据WRDL，来决定该缺省值是来自客户端，还是来自服务器端session作用域、request作用域或其他域，并自动将sql语句进行补全

6.title元素：和param元素平级，用于数据在页面上展示时标题或元数据的定义，决策Agent根据WRDL，来决定页面上的元数据信息

7.output元素：和param元素平级，代表程序的核心输出，每一个output元素代表了一项输出项，决策Agent根据WRDL，进行计算，获取数据后组织成json自动填充回页面中

WRDL的解析流程为：

1.查找Elements节点，若能找到，执行步骤2；否则结束流程

2.查找Elements节点下的所有element节点，若找到，执行步骤3；否则结束流程

3.遍历所有element节点，查找element节点的flag属性，若找到，存入内存并执行步骤4；否则重复此步骤，进入下一个element节点

4.查找element节点下的所有sql节点，若找到，执行步骤5；否则执行步骤3，进入下一个element节点

5.遍历所有sql节点，查找sql节点的value属性，若找到，存入内存并执行步骤6；否则重复此步骤，进入下一个sql节点

6.查找sql节点下的所有struct节点，若找到，执行步骤7；否则执行步骤9

7.遍历所有struct节点，查找struct节点的session属性，若找到，存入内存并重复此步骤，进入下一个struct节点；否则执行步骤8

8.查找struct节点的request属性，若找到，存入内存并执行步骤7，进入下一个struct节点；否则执行步骤7，进入下一个struct节点

9.查找sql节点下的所有param节点，若找到，执行步骤10；否则执行步骤13

10.遍历所有param节点，查找param节点的notNull属性，若找到，存入内存并执行步骤11；否则执行步骤11

11.查找param节点的session属性，若找到，存入内存并执行步骤10，进入下一个param节点；否则执行步骤12

12.查找param节点的request属性，若找到，存入内存并执行步骤10，进入下一个param节点；否则执行步骤10，进入下一个param节点

13.查找sql节点下的所有title节点，若找到，执行步骤14；否则执行步骤15

14.遍历所有title节点，将title节点的文本值存入内存并执行步骤15

15.查找sql节点下的所有output节点，若找到，执行步骤16；否则结束流程

16.遍历所有的output节点，将output节点的文本值存入memory pool并结束流程

2.3：前端发送请求，决策Agent采用内部协作机制处理用户请求，根据MemoryPool中的配置信息，从AgentCluster中筛选出相应的元Agent组装成AgentChain。互联网环境是动态不确定的，这使得Web系统开发也具有了一定的不确定性。为了确保AnGo模型能提供相对明确和稳定的系统级别可复用开发能力，单一的元Agent无法完成多个相互交互的复杂任务。因此，就需要多个元Agent间通过协同的方式来实现对用户需求的解析、处理和资源提供。AnGo模型通过AgentChain来完成这一协作任务，这既提高了软件开发的效率，同时也确保了软件质量，因为Agent Chain中的每一个元Agent在加入前都必须保证是可用、可靠的，并已经通过软件测试。Agent Chain基于元Agent，能够根据环境和需求的变化而变化，它也是确保AnGo系统内各个组件的生存能力的重要方式。决策Agent按序执行该AgentChain即可完成用户交付的任务请求。

如图4所示，决策Agent内部协作机制分为请求响应阶段、路由选择阶段、Agent调度阶段和执行监控阶段。具体过程如下：

2.3.1)请求响应阶段：首先，前端向路由Agent发出请求(1.request())，决策Agent接受请求并经过处理后，通过执行Agent将处理结果返回前端(10.response())。

2.3.2)路由选择阶段：路由Agent接受前端发出的请求，根据请求内容的路径参数转发路由，并将路由选择结果及请求内容发送至执行Agent(2.inform())。执行Agent接受路由Agent传递的信息，将请求内容发送至调度Agent并通知其完成相应的工作(3.interact())。

2.3.3)Agent调度阶段：调度Agent收到执行Agent通知后，根据请求内容从MemoryPool中抽取相应的配置片段(4.lookup())，按照片段中的信息(5.result())前往组件层筛选出与配置相吻合的元Agent，筛选出的Agent会动态感知上下文环境，对自身的先后顺序做出调整并组成一条Agent链(6.coordinate())返回至执行Agent(7.return())。

2.3.4)执行监控阶段：执行Agent按序执行接受的AgentChain(8.execute())，同时异常处理Agent和监测Agent将全程监视AgentChain中每个元Agent的运行过程(9.moniter())。

为了支持决策Agent的动态调度和具有动态多样性需求的请求，本文提出了决策Agent内部协作机制，该机制使得决策过程更加协调、高效。

如图5所示，决策Agent内部协作机制的运作流程如下：

路由Agent包含：解析单元、转发单元

执行Agent包含：协作单元、运行单元

调度Agent包含：查询单元、装配单元、通知单元

1.2.1.前端向解析单元发送Request请求；

1.2.2.解析单元解析出请求路径和请求参数Profile传递给转发单元,请求参数Profile包含契约值和前端表单项、上下文环境；

1.2.3.转发单元根据路径参数进行路由选择，如果成功解析路由，则将路由和请求参数传递给运行单元；如果无法解析路由，则返回False；

1.2.4.运行单元加载路由，此时由于缺少AgentChain，无法执行任务。因此，运行单元会请求协作单元进行协调；

1.2.5.协作单元将请求参数继续传递给查询单元；

1.2.6.查询单元根据请求参数Profile中的契约值前往MemoryPool进行查询；

1.2.7.返回查询结果；

1.2.8.如果能查询到契约值所唯一对应的Config配置片段，所述Config配置片段包括用户的个性化需求以及元Agent到通用功能集合的某条映射，查询单元会将Config传递给装配单元；如果查询不到，查询单元则会返回False；

1.2.9.装配单元根据Config配置片段前往Agent Cluster查询相应的元Agent，如果在Agent Cluster中能找到配置片段中的所有元Agent，装配单元会将查询到的所有元Agent按顺序组成一条Agent Chain并返回给运行单元，执行步骤1.2.10；如果无法找到所有的元Agent，则会调用通知单元，执行步骤1.2.11；

1.2.10.执行单元装载接受的Agent Chain，此时由于执行单元已经成功加载路由，满足任务运行的条件，AgentChain中的每个元Agent会按顺序流水化执行，并将执行结果返回至前端；

1.2.11.通知单元通知Agent Center完成其相应工作；

1.2.12.Agent Center更新WRDLPool，移除过期的元Agent配置信息；

1.2.13.将WRDLPool的最新配置储存到MemoryPool中。

为了支持决策Agent内部协作机制，设计了决策Agent内部协作算法，它是决策Agent运行的核心和决策依据。该算法描述了决策Agent内部如何通过协作的方式实现对任务请求的有序处理。算法流程如下：

输入：请求request，AgentCluster＝{元Agent₁,元Agent₂,…,元Agent_n}

输出：响应response

1.从request中解析出URL

2.根据URL进行路由转发

3.若根据URL找不到正确路由，则返回错误

4.从request中解析出请求参数profile

5.根据profile从Memory Pool中查询配置片段config

6.若查询不到config，则返回错误

7.对于所有Agent_i，其中Agent_i为配置片段config中配置的元Agent，若Agent_i在Agent>i添加到Agent>

8.路由执行Agent Chain

9.返回response。