CN1744512A

CN1744512A - 网络资源管理方法

Info

Publication number: CN1744512A
Application number: CN 200410057081
Authority: CN
Inventors: 尼姆尤; 张治华
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2004-08-30
Filing date: 2004-08-30
Publication date: 2006-03-08

Abstract

一种使用状态机进行网络资源管理的方法，其中使用标记语言在一配置文件中定义各网络资源的状态机，所述状态机包括相应网络资源的多个状态、与每个状态相关联的至少一个状态迁移、与每个状态迁移相关联的事件、以及与每个状态迁移相关联的至少一个迁移条件，所述方法包括以下步骤：获取一个发生的事件的参数；从配置文件获得与所述事件相关联的迁移条件，以校验与所述事件相关联的状态迁移是否能够被执行；如果通过校验，则执行所述状态迁移。

Description

网络资源管理方法

技术领域

本发明涉及网络资源管理方法，具体涉及一种使用状态机进行网络资源管理的方法。

背景技术

在网络资源管理领域中，需要解决实体对象的状态迁移以及该状态迁移导致的相关联的对象的状态迁移。

一个资源在其生命周期过程中，会经过多个状态，激活这些状态迁移的行为也是不一样的。各个资源类型的状态类型都是不一样的，即使是不同的资源类型有着相同的状态名称，该状态的迁移行为也不是一样的。为了便于理解，首先介绍本发明用到的一些概念：

1)状态(State)

状态表示一个具体的资源实例在某段时间范围内所具有的一个相对稳定的态势，除非针对该资源的一个变更事件(如删除、关联等操作)发生或者相关联的其他资源的状态变更需要该资源的状态发生相应变化，该资源将维持在这个状态。在一个状态，资源将接收特定的一个或多个事件。

2)事件(Action)

事件是指发生在资源对象上的外部操作或者内部状态迁移传播，这些事件可能导致在某个状态下的资源实例发生状态迁移。

3)状态迁移(State Transition)

指对处于某个状态的资源施加一个事件后，资源的状态发生变化的过程。只有该状态接收此事件，且满足一些特定的校验条件，迁移才会发生。所以也称为有条件状态迁移。

4)状态迁移传播(State Transition Propagation)

指一个资源的状态迁移诱发其他类型的资源的状态迁移，被诱发的资源与源资源有着直接或者间接的关联关系。一个状态迁移传播触发的状态迁移可能诱发另外一个状态迁移，这些迁移间存在一个顺序关系，并要求在一个事务内完成。在诱发过程中，原来的事件已经被转化，不再是初始的事件，而是一个传播事件。实际上，被传播后的资源的状态可以从其他资源的状态通过类似的计算而来，但是这种计算将会极其复杂和耗时，在初始事件发生时完成状态迁移传播会更加有效率。

5)状态机(State Machine)

就是针对一个资源类型的所有的状态以及状态迁移(包括状态迁移传播)的集合，是针对一个资源对外部的事件的总体行为的描述。

图1是一个状态迁移和状态迁移传播的示意图，显示了状态机机制的具体示例。其中，端口和单板是不同的资源类型，Connected，In-Use，Installed是不同的状态，Assign是一个事件。当“端口”对象在Connected状态时，接收了Assign操作(和Cable关联)，状态变换为In-Use；同时通过状态迁移传播Propagationl，触发了该“端口”所在的“单板”对象从Installed状态变换成In-Use状态。

对于状态机机制的实现，比较经典的做法是采用有限状态机(FSM)技术，该技术通过一个代码生成器，生成C语言的状态机处理代码，但是在Java语言以及面向对象编程的环境下，该方法并不适用。

如图2所示，与本发明相关的一种现有技术采用如下方案：

1)对于每个资源类型的每个状态，定义一个状态处理类，实现状态处理接口StateHandler，并对类名给予一定规则。

2)通过一个StateHandlerFactory类来通过这个命名规则寻找StateHandler。

3)在资源类对象的事件处理中，调用StateHandler来处理状态迁移。示例代码如下：

void XXXAction(){

String currentState＝thisResource.getStatus()；

StateHandler stateHandler＝null；

stateHandler＝StateHandlerFactory.FindStateHandler(resourceType，currentState)；

stateHandler.Validate()；

//这里是本身针对该事件的业务处理逻辑

……

stateHandler.PerformStateTransition()；

stateHandler.PerformPropagation()；

}

从上述方案描述可以看出，我们要为每个资源的每个状态写一个实现类，每个类的各个方法的实现基本都不会相同，由此带来一系列的问题：

1)大量的代码耗费在条件校验和状态迁移传播上，条件和状态迁移传播越多，代码量越大，事实上他们的编码模式是相似的。这样会导致开发效率低，Bug数量多，维护量也相应增加。

2)任何对状态或者状态迁移的变更，将导致这些代码被重新修改，由此引入新的Bug。

3)校验规则没有归纳，现有的规则不易被重用，也不容易引入新的校验规则。

发明内容

鉴于上述现有技术方案的缺陷，本发明所要解决的技术问题是使状态机可灵活配置，从而通过使用状态机容易地管理网络资源。

根据本发明，提供一种使用状态机进行网络资源管理的方法，其中使用标记语言在一配置文件中定义各网络资源的状态机，所述状态机包括相应网络资源的多个状态、与每个状态相关联的至少一个状态迁移、与每个状态迁移相关联的事件、以及与每个状态迁移相关联的至少一个迁移条件，所述方法包括以下步骤：

获取一个发生的事件的参数；

从配置文件获得与所述事件相关联的迁移条件，以校验与所述事件相关联的状态迁移是否能够被执行；

如果通过校验，则执行所述状态迁移。

根据本发明的技术方案，主要实现以下技术效果：

1)资源的状态机是可灵活配置定义的，可以在不修改代码的情况下，通过修改配置文件来修改资源的行为。针对一个状态，只有已经有相应的状态迁移定义的事件才是被允许的。

2)状态校验器可扩展，可配置，可重用。这些校验器将执行条件检查。

3)状态迁移传播也是可配置的，并根据配置文件自动触发。

附图说明

图1是一个状态迁移和状态迁移传播的示意图；

图2是现有技术的状态处理接口的示意图；

图3是显示用于实施本发明的软件结构的总体示意框图；

图4是用于解释根据本发明的状态机定义的示意图；

图5显示根据本发明的状态机实体对象；

图6是显示根据本发明进行状态机服务的具体示例的图。

具体实施方式

图3显示了用于实施本发明的软件结构的总体示意框图。

在本发明中，状态机以状态机定义文件的方式定义，在***初始化时被载入内存，形成多组状态机实体对象；状态机管理器则利用这些实体对象以及相互关系，对应用模块提供状态机处理服务；应用模块则使用状态机服务来确定该操作(事件)是否能够执行，执行完成后迁移到什么状态。下面自下而上逐一介绍各个部分的详细方案。

状态机的定义

每一个网络资源都对应于一个状态机，每个状态机的定义中首先要包含该资源的多个状态定义，每个状态下有多个状态迁移定义，每个状态迁移由一个相关联的事件诱发，并且每个状态迁移有相关联的一个或多个迁移条件。根据需要，状态机中还定义了与状态迁移相关联的状态迁移传播。

另外，每个状态迁移具有至少一个目标状态，在具有一个以上的目标状态的情况下，每个目标状态具有相关联的至少一个条件，用于确定迁移到哪个目标状态。

在本发明中，状态机可以用任何类型的标记语言来定义，但是优选使用XML语言。XML就是“可扩展的标记语言”(eXtendable MarkupLanguage)，是目前最通用的一种标记语言，运用它可以扩展到多种应用，而且围绕它的开放的解析工具、编辑工具都很丰富。为便于具体说明，在以下的示例中采用XML语言进行说明。以下是XML语言形式的DTD(document type definition，文件所用到的类型的定义)：

<！--一个状态机StateMachine定义包含多个状态State定义-->

<！ELEMENT StateMachine(State+)>

<！ATTLIST StateMachine name CDATA #REQUIRED>

<！--每个状态下有多个状态迁移Transition定义，有且只有这些迁移可以发生在这个状态下，状态包含一个内部引用名称和外部显示名称-->

<！ELEMENT State(Transition*)>

<！ATTLIST State name CDATA #REQUIRED display_name CDATA #REQUIRED>

<！--状态迁移是由一个事件(ActionMethod)来诱发的，可能迁移到多个状态(根据附加条件来决定)，迁移到哪个具体的状态也是根据条件来确定的，由ToState的Condition元素配置；在迁移发生后，可以通过PropagationTrigger触发多个状态迁移传播。-->

<！ELEMENT Transition(ToState+，Condition*，PropagationTrigger*)>

<！ATTLIST Transition actionMethod CDATA #REQUIRED>

<！ELEMENT ToState(Condition*)>

<！ATTLIST ToState name CDATA #REQUIRED>

<！—PropagationTrigger在触发状态迁移传播时，要指定传播的路径associationPath，(通过这个路径可以找到目的资源类型)以及目的地的状态迁移的名字(由propagation定义)-->

<！ELEMENT PropagationTrigger EMPTY>

<！ATTLIST PropagationTrigger associationPath CDATA #REQUIRED

propagation CDATA #REQUIRED>

<！—条件对应一个校验器，name定义了校验器的类名，由于不同校验器的参数各个不同，所以参数(Param)以名值对的形式传入-->

<！ELEMENT Condition(Param*)>

<！ATTLIST Condition name CDATA #REQUIRED>

<！ELEMENT Param EMPTY>

<！ATTLIST Param name CDATA #REQUIRED

value CDATA #REQUIRED>

由以上内容可以看出，在本发明中采用了条件性状态迁移。条件性状态迁移实际上包含两个模式，一种是在判定迁移是否有效前，运用条件检查；另外一种是迁移已经有效，但是根据其他条件来判定应该到哪个状态。把这两种分开可以简化校验的处理流程，因为分开后，只要任何一个条件检查不通过，就认为检验失败；而不用等所有的检验都完成后，计算最符合的分支。

下面结合实际网络资源列举一个例子，来说明如何定义状态机。

如图4所示，假设当端口(Port)连接到电缆时，其状态从Installed到Connected状态，同时诱发单板(Board)从Installed状态转变成In-Use状态。而当端口(Port)和电缆断连时，其状态从Connected到Installed状态，同时如果单板的所有端口都处于Installed状态时，诱发单板(Board)从In-Use状态转变成Installed状态。

那么Port的状态机定义为：

<ToState name＝″CONNECTED″/>//ToState在这里已经结束了，下列的Condition是Transition的。

</Condition>

<PropagationTrigger associationName＝″BOARD_PORT″

propagation＝″Port：Installed_Connected″/>

</Transition>

</State>

</Condition>

<PropagationTrigger associationName＝″BOARD_PORT″

propagation＝″Port：Connected_Installed″/>

</Transition>

</State>

</StateMachine>

Board的状态机定义如下：

<！—这个就是一个被传播的状态迁移-->

</Transition>

</State>

<ToState name＝″INSTALLED″>//该条件是ToState的

</Condition>

<ToState name＝″INUSE″>//该条件是ToState的

</Condition>

</Transition>

</State>

</StateMachine>

被缓存的状态机定义实体

上述定义的状态机，将被转换成***的状态机实体对象，我们称之为“State Machine Specification”，其中包含如图5所示的实体对象(Resource除外)。

图5中所示对象基本上和DTD中描述的对象是一致的，具体含义和关系已经在DTD的解释信息中描述，这里就不再赘述。我们可以通过XML定义来建立资源类型(Resource)和StateMachine对象间的关联，使一个资源对应一个状态机。

状态机服务

状态机服务的过程首先要获取发生的事件的相关参数，进而根据状态机中定义的与事件相关联的迁移条件校验该事件是否能够被执行。如果通过校验，则执行与所述事件相关联的状态迁移，并进而执行与所述状态迁移相关联的状态迁移传播。

可以看到，Transition元素有ToState和Condition两个子元素，并且可包含一个或者多个ToState；同时有多个ToState时，每个ToState也有一个或者多个Condition。在处理该语意时，先看该Transition下的Conditoin是否都得到了满足，如果是，再根据ToState下的Condition来决定是否有合适的状态定义。只有Transition下的条件和ToState下的条件都得到匹配，才会执行该操作，并发生状态迁移。

下面结合图6说明根据本发明进行状态机服务的具体示例。状态机服务由图6所示的ResourceStateManager接口提供，在使用它的服务前，要传递一个StateMachineSession对象，该对象存储必要的与具体事件相关的参数，供ResourceStateManager和StateTransistionCondtionValidator在执行校验时使用。StateTransitionConditionValidator则主要被ResourceStateManager用来执行条件校验，ResourceStateManager根据前述XML的定义，确定对某个状态转移使用某些个条件校验器，并逐个执行校验器的validate()方法，如果任何一个返回异常，就认为该事件不能被执行。

ResourceStateManager的几个主要方法的用途和实现逻辑：

1)validateAction()，该方法用于校验事件是否能够被执行，如果能执行，返回true；否则返回false。在处理过程上，其首先从StateMachine Specification获得在该状态下事件名称相同的Transition对象，然后逐个检查Transition所属的Condition是否被满足(调用不同的StateTransitionConditionValidator的实现类)，如果有满足，则存储满足条件的Transition并返回true。

2)performStateTransition()，该方法执行状态迁移，并执行状态迁移传播。该方法首先从前面validateAction函数中计算出的Transition对象中获得一个确定的ToState对象(也需要逐个检查ToState对象的Condition对象是否被满足，只有满足Condition对象设定的条件的ToState才是有效的)，然后物理化存储新的状态，最后逐个执行该Transition对象下的所有PropagationTrigger对象，PropagationTrigger激活的也是一个Transition对象，所以针对每个PropagationTrigger的处理也是一样的。

3)setStateSessionData()，把该事件相关的参数传递到Session中来，以Map的形式存储。

下面通过一段代码作为例子来说明ResourceStateManager的用法。

在一个资源类型中，每一个不同事件有一个处理函数，该方法的实现示例如下，

XXXActionMethod()

{

ResourceStateManager lStateMgr＝null；

try{//从工厂获得一个ResourceStateManager的实现实例

lStateMgr＝StateMachineFactory.getStateMgmt()；

}

catch(StateMgmtException ex)

{

//异常处理并返回

……

}

//相关的SessionData被传递进来

lStateMgr.setStateSessionData(new StateMachineSession(

opertationType，lResValue))；

try{//校验该事件是否有效的事件

if(false＝＝

lStateMgr.validateAction(lResValue.getTypeName()

，lResValue.getState()

，toState)

{

//如果不是则返回异常

……

}

catch(StateMgmtException ex2)

{

//exception handling here

}

//这里放置具体的业务逻辑，不再需要处理状态相关的工作.

……

try{//最后执行状态迁移的后续状态更改和状态迁移传播

lStateMgr.performStateTransition(aResKey)；

}

catch(StateMgmtException exl)

{

}

所有的其他事件处理将使用同样的编程模式来处理状态迁移，不需要考虑过多的状态机迁移以及状态迁移传播的具体细节。

从上述方案可以看到，通过这样一套机制，我们可以获得如下好处：

1)采用XML这种简单易懂的方式来定义状态机，并表示了条件性状态迁移和状态迁移传播这两个新的特性。

2)状态的条件校验器是与状态机处理松偶合的，并容易扩展。

3)状态迁移和状态迁移传播作为状态机服务的内在特性，对业务逻辑是透明的，简化了编码。

4)状态迁移的处理和业务逻辑的处理是分离的，这样使状态迁移的定义更加容易变化而不用修改源代码。在资源管理应用中，不同的运营商(或是同一运营商的不同分支公司)对业务的要求是不一样的，特别是状态定义上，变化更多，而该机制很好地适应了这种情况。

Claims

1.一种使用状态机进行网络资源管理的方法，其中使用标记语言在一配置文件中定义各网络资源的状态机，所述状态机包括相应网络资源的多个状态、与每个状态相关联的至少一个状态迁移、与每个状态迁移相关联的事件、以及与每个状态迁移相关联的至少一个迁移条件，所述方法包括以下步骤：

获取一个发生的事件的参数；

如果通过校验，则执行所述状态迁移。

2.根据权利要求1所述的方法，其中每个状态迁移具有一个以上目标状态，每个目标状态具有相关联的至少一个条件，所述方法在根据迁移条件判断所述事件能够被执行后，进一步根据与每个目标状态相关联的至少一个条件来执行状态迁移。

3.根据权利要求1所述的方法，其中所述配置文件由XML语言编写。

4.根据权利要求1所述的方法，其中所述状态机还包括与状态迁移相关联的状态迁移传播，并且所述方法还包括在执行状态迁移后进而执行所述相关联的状态迁移传播。

5.根据权利要求1所述的方法，其中可以通过修改配置文件来修改网络资源的状态机。

6.根据权利要求4所述的方法，其中所述状态机还包括状态迁移传播的传播路径，并且所述执行状态迁移传播的步骤根据所述传播路径来进行。

7.根据权利要求4所述的方法，其中在配置文件中将某些网络资源的状态迁移定义为相关联的网络资源的事件。