构件化软件的在线演化方法.doc

说 明 书构件化软件的在线演化方法技术领域： 本发明涉及一种构件化软件的在线演化方法，属于软件维护技术领域。背景技术： 目前构件化软件支持产品主要是从大型软件的复用性、分布性角度开发出来的，一般提供应用系统的热部署功能。这是一种大粒度的系统演化，实现了在保持现有系统运行的前提增加新系统的功能，各个系统之间一般没有直接关系。但是，目前还没有针对单个系统的在线演化，即在保持当前系统持续运行、服务的前提下，对系统内的构件进行演化，这是一种细粒度的系统演化，难度比大粒度的系统演化更大。发明内容： 本发明的目的是提供一种细粒度的系统演化方法，在保持当前系统持续运行、服务的前提下，对系统内的构件进行演化，即进行构件的增加、删除、替换、改变构件之间的关系等操作，以取得在线增加服务内容、优化服务流程、消除系统缺陷、提高响应时间的效果。本发明的具体技术方案如下：本发明的构件化软件的在线演化方法是，除了管理一般的构件生命周期状态（例如加载状态、就绪状态、服务状态、执行状态、缓存状态等）外，通过引入构件的属性同步状态、请求截流状态和请求缓冲状态建立对构件的细粒度管理机制，从而更精确地控制构件的行为，并在此基础上进行构件重载，实现软件的在线演化。构件的细粒度管理机制：与操作系统中对进程的管理类似，基于构件的软件系统运行过程中，需要随时对构件的各种状态进行检视、控制。为支持在线演化，除了一般的构件生命周期状态（例如加载状态、就绪状态、服务状态、执行状态、缓存状态等）之外，本发明引入另外三种状态：（1）属性同步状态，当一个新构件将替换一个当前正处于服务状态的构件（下称老构件）时，它必须建立起与老构件相同的环境与属性值，这是通过不断地复制老构件的属性等过程建立起来的；（2）请求截流状态，当新构件与老构件已经达到同步状态时，新构件可以开始接受新请求，老构件不再接受新请求，但必须完成正在执行的操作，并返回操作结果，故称其为截流状态；（3）请求缓冲状态，如果新老构件不在执行操作时间上存在交叠，则必须在切换的瞬间必须对请求进行缓冲，此时该构件处于请求缓冲状态，这与缓存状态不同，后者是指构件的实例服务完后，不立即将实例删除，而是将其放置到一个缓存队列中，这样当其他请求需要该构件服务时就不必重新加载，而是可以直接从队列中取出构件实例，不必初始化构件，从而降低响应时间。通过引入构件的上述三种新状态，可以更精确地控制构件的行为，实现构件对状态的更细粒度的管理，以满足在线演化软件的基本需求。构件重载：现代计算机软件的一个重要假定是程序载运行过程中不修改自身的代码，因此操作系统一般仅在应用系统启动时加载各个模块，而在运行过程中则可以增加模块，但不允许修改模块。这给构件重载造成了困难，为了解决这一问题，本发明利用构造新加载程序的方法，并借助于构件接口来进行构件的重载。每一个构件有一个对应的构件接口类，新的加载程序区分构件的接口与构件的具体实现，其中接口在系统演化过程中是不变的，变化的是实现构件功能的具体对象。当需要重载构件时，首先加载新的构件实现体，并以该构件为模板创建构件实例，然后利用请求路由控制机制和请求缓冲控制机制二者之一或二者结合，将请求消息定向到新构件实现上，这样构件功能的真正实现体即变为新构件的实例。所述请求路由控制机制是：当需要替换一个（或一组）构件时，为保持服务的连续性，往往在加载新构件时，老构件将继续存在于系统之中，因此将发生新老构件同时存在于一个构件管理器中的状况（甚至同时进行服务），这时需要引入请求路由控制机制。请求路由最初是指向老构件的，在替换构件时，如果老构件未处于服务状态或者执行状态（当然，也不处于加载状态），则可以直接将请求路由进行修改，使其指向新构件；如果老构件处于服务状态，则必须将构件状态设置为属性同步状态，建立起老构件的环境与属性，然后修改路由，由新构件接替老构件的当前服务；如果老构件处于执行状态，意味着老构件的许多属性等可能正在变化，因此只有等待其执行结束后才能进行同步，此时可以将构件状态设置为截流状态。此时，新构件可以接受新的服务过程，但不能接收正在服务的某个新请求，只有当老构件正在执行的所有过程全部完成后，才可以完全将请求路由完全映射到新构件上。这样，通过将请求路由从旧构件切换到新构件，即可以实现替换构件的微观过程。所述请求缓冲控制机制是：当进行在线演化时，对部分请求进行临时缓存，以可以接受的响应时间延迟，换取演化的可靠性。请求的缓冲的实现需要结合底层的通信机制，以及底层的线程管理机制进行，请求在底层就是一个基于互操作协议的消息包，可能的协议包括：IIOP、SOAP、JRMP等，与每个构件对应的构件容器上可以缓存这些消息包，从而缓冲来自客户的请求，待新老构件切换完毕时，再将这些消息继续向构件传送。请求缓冲控制机制是替换一个（或一组）构件时采取的另外一种机制，它与请求路由控制可以单独使用，也可以结合使用。单独使用时，演化时间比请求路由控制长一些，但可靠性较高。结合使用时，演化过程相对复杂一些。 本发明的演化流程图如图1所示，系统启动后，系统加载构件，构造适合于演化的结构，构件状态由构件容器进行管理。在运行过程中，每一个构件都有与其相对应的构件容器，专门用于对该构件的管理，构件容器中包含关于构件的各种信息，例如构件标识、构件类型、构件状态、构件安全控制、所需要的构件、通信机制等等。当一个新构件将替换一个当前正处于服务状态的构件时，它通过不断地复制被替换构件的属性等操作建立与被替换构件相同的环境与属性值，即达到新老构件的同步状态。当新构件与老构件已经达到同步状态后，将被替换的构件进入截流状态，不再接收新请求的调入。为保持服务的连续性，往往在加载新构件时，老的构件将继续存在于系统之中，因此将发生新老构件同时存在于一个构件管理器中的状况，这时引入请求路由控制机制将新请求重新定向到新构件上，直到老构件服务结束。这样，通过将请求路由从老构件切换到新构件，实现了替换构件的微观过程，演化过程结束。同时，还可以采用请求缓冲控制机制实现演化过程。如果新老构件不在执行操作时间上存在交叠，则在替换构件的瞬间对来自客户的请求进行缓冲，此时该构件处于缓冲状态，待新老构件同步结束后，构件恢复正常的服务状态，同时，被挂起的请求线程被解挂，并得到服务。采用本发明的方法，在保持当前系统持续运行、服务的前提下，可以对系统内的构件进行演化，达到在线增加服务内容、优化服务流程、消除系统缺陷、提高响应时间的效果，从而大大提高软件系统的服务质量，为用户提供电信级的、7X24（每周7天、每天24小时）的不间断服务，这对于目前基于Web的大型软件系统具有十分重要的意义。附图说明： 图1为本发明的构件化软件的在线演化方法的演化流程图。实施例：本节给出一个在JAVA虚拟机上的实现。JAVA虚拟机处于操作系统之上，应用系统之下，基于JAVA的构件为EJB（Enterprise JavaBean）构件，EJB构件状态由构件容器（Container）进行管理，其接口符合EJB规范。在运行过程中，每一个构件都有与其相对应的构件容器，专门用于对该构件的管理，构件容器中包含关于构件的各种信息，例如构件标识、构件类型、构件状态、构件安全控制、所需要的构件、通信机制等等。完成构件重载需要定义新的加载类，该类继承了java.lang.ClassLoader，利用Java方法的重载，重载了loadClass（）方法，解决直接利用java.lang.ClassLoader加载类时可能遇到的冲突问题，以实现构件的重载。接口的实现符合EJB规范，构件的实现也符合EJB规范。路由信息存放在构件容器中，为便于演化，构件容器必须存放实现类队列，而不是象一般系统那样仅存放一个实现类，路由切换的时机由专门的管理类进行控制，由新、老构件的状态变化所触发。一般一构件的重载可能引起其他多个构件的重载，因此存在一个变化范围问题，这由具体进行演化的操作人员进行控制。缓冲机制的实现借助于JAVA虚拟机的Thread（线程）机制，它与系统通信机制的实现密切相关。服务器端系统存在一个监听进程，处于循环等待状态，等待客户的各种请求，该进程继承了类