CN101282246B - 监控软件系统的方法和系统 - Google Patents

Abstract

本发明涉及一种方法，用于监控软件系统(1)，该软件系统基于面向服务体系结构(SOA)并包括通过发送消息(110)相互通信的系统组件(C1，C2，C3，……，101，102)，该方法包括以下步骤：a.由监控组件(10)接收监控消息(5，120)，所述监控消息(5，120)是从所述软件系统(1)的系统组件(C1，C2，C3，……，101)发送的；b.所述监控组件(10)提供本体(11，200)，所述本体包括至少一个用于所述监控消息(5，120)的解释规则；和c.根据所述至少一个解释规则，所述监控组件(10)做出反应。

Description

监控软件系统的方法和系统

技术领域

本申请涉及一种用于监控软件系统的方法和系统，尤其涉及基于面向服务体系结构的软件系统。

背景技术

为了保证软件系统按照期望的操作，监控软件系统是一件重要的技术任务。这不但应用于软件系统的开发阶段当需要反复地调试源代码时，还应用于部署阶段，例如，当必须控制异常运行时的情况时，或者出于维护或其它目的要评估系统的性能时。在其最简单的形式中，监控(monitoring)仅仅是日志产生设备通知系统中发生的每一动作，将该动作记为日志条目并将该条目增加到日志中。在更广意义上，监控可以是查看正在进行什么并因此做出反应的任何事情。查看正在进行什么包括获得关于系统当前状态及其历史的信息的装置。

传统地，对软件系统的监控包括根据监控系统的一些固定的、预定的规则来生成一个或多个日志文件。事件被记入日志，可能是与相应的时戳一起被记录，以便于通过以后对这样的日志文件的查看使得可以明白事件在软件系统运行时期间发生的顺序。在更高级的替代方案中，可以使用配置文件，比如Log4j项目的配置文件，该配置文件在运行时确定将何种信息写入日志文件。但是，这样的配置文件所提供的日志选项被限于预定的日志记录器层次结构，并因此仅提供非常有限的灵活性。

这些年，软件系统已经变得越来越复杂，这使得监控变的困难。更重要地，面向服务体系结构(SOA)的概念的使用在不断增加，其中松耦合组件比如web服务通过交换消息来执行处理。理想地，SOA适应于关于处理流的逻辑变化以及基础(underlying)技术实现的变化。

但是，使用上述传统方法来监控在基于SOA的软件系统(或灵活性和复杂性相似的任何其它系统)的操作期间交换的消息的话，只要对被记录的任何消息的格式或内容做出改变，就需要整个监控系统的适应。结果，如果使用现有技术的传统监控方法，其中监控由实现在监控系统中的一组多多少少固定的规则来确定，那么使用SOA的主要好处即它的灵活性基本上丢掉了。而且，监控系统的反复变化还影响因此产生的一个或多个日志文件，这样日志文件的查看和理解变得越来越困难。

由于以上原因，本发明的第一方面所基于的技术问题是提供一种监控方法和监控系统，该方法和系统可以灵活地适应于被监控软件系统的变化。根据另一方面，本发明试图辅助读取监控系统的日志文件。

发明内容

根据本申请的第一技术方案，通过一种监控软件系统的方法来解决该问题，其中软件监控系统基于面向服务体系结构并包括通过发送消息相互通信的组件。在一个实施例中，该方法包括以下步骤：

a.通过监控组件接收监控消息，所述监控消息从所述软件系统的系统组件被发送；

b.监控组件提供本体(ontology)，所述本体包括针对所述监控消息的至少一个解释规则；和

c.根据所述至少一个解释规则，所述监控组件做出反应(react)。

因此，优选的监控方法使用基于本体的方法而不是固定的一组监控规则，其中固定的监控规则永久地以一种或另一种方式实现在监控组件自身中。改变本体使得可以动态适应监控规则，而不必改变监控组件自身。

在优选实施例中，软件系统的组件所交换的消息的格式和内容由另一本体或同一本体来确定。在这样的系统中，其中软件组件松耦合以及仅通过发送消息来通信，当交换的消息没有固定格式时，取得了更高程度的灵活性。相反，使用对系统中所有组件都可用的本体，消息内容和格式可以动态地取得一致。由于监控方法以相似的方式使用基于本体(可能是与要被监控的SOA所使用的一样的本体的扩展)的监控消息，该方法就像SOA自身一样灵活。

可以使用本体语言OWL、RDF、DAML-OIL和主题地图(Topic Map)(在http://www.w3.org和www.topicmaps.org有描述)中至少一种来定义本体。在本发明的优选实施例中，本体的含义是一种部件，用于建立带有属性以及相互之间关系的对象和类的概念，从而模拟要处理的任务所必需的世界子集。

在目前优选的实施例中，本体的至少一个解释规则确定：监控组件是否将信息记入日志，和/或监控组件以何种格式记录信息。因此，整个监控过程优选地由本体驱动。

在一个具体实施例中，信息记录在永久日志中和暂时日志中。暂时日志例如可以包括关于未决的(pending)过程的信息，诸如过程的开始，而永久日志可以仅包括已完成过程的信息。

在特别优选的实施例中，监控组件的反应包括修改本体。例如，监控组件所查找的模式可以改变，此改变可取决于通过检查以前的过程而获取的知识。使用带解释规则的本体，允许这种类型的反馈，所述解释规则可以动态改变。

优选地，从软件系统的系统组件发送到监控组件的监控消息包括要记入日志的事件类型的唯一的标识符。这使得下面进一步描述的机制能够使用该标识符来查阅日志条目。

根据本发明的另一个方面，提供一种方法，用于查询使用任意上述方法所创建的日志，该方法包括以下步骤：

a.监控组件接收查询日志内容的查询消息，该查询与监控组件可使用的本体的至少一个规则相一致；

b.将所述查询消息映射为适合于日志的查询格式，所述映射基于监控组件可使用的另一本体或同一本体的至少一个规则；

c.执行查询，并在将结果映射为基于所述本体或监控系统可使用的多个本体的输出格式后，返回结果。

因此，从日志获得信息即读取日志，这也是由一个或多个本体驱动的，其中本体可以是监控组件可使用的其它本体或上述的本体的另一本体的扩展。由于日志条目的内容和结构灵活地依赖于本体，因此在没有其它输入的情况下理解日志条目之间的关系是不可能的。换言之，不可能直接询问日志，而是必须向监控组件问问题，该监控组件查阅本体知识库以获得提供日志的确切数据结构，从而可以相应地映射原始查询。

在特别优选实施例中，查询消息被作为XQuery消息接收，并且所述一个本体或多个本体包括定义查询消息的数据结构和/或适合于日志的查询格式的至少一个XML Schema。

所描述的方法的其它有益修改在其它从属权利要求中定义。

最后，本发明提供适合执行上述方法中任意方法的监控系统。这样的监控系统可以是整个软件系统的一部分或者可以单独被提供。监控系统可以通过硬件和/或软件实现，例如通过合适的计算机程序，该程序中有指令用于执行以上简要描述的技术步骤。

附图说明

在下面的详细描述中，参考附图来描述目前优选的实施例，附图包括以下图：

图1：根据本发明的一个具体实施例的本体驱动SOA以及相关监控系统的概况；

图2：图1的监控系统以及相关信息流的更详细表示；

图3：在本发明的示例性实施例中，管理商业登记转移的示例性本体的示意性表示；

图4：在本发明的具体实施例中，监控图3所示过程的步骤的示意性表示；以及

图5：读取图4所示步骤创建的日志条目的步骤的示意性表示。

具体实施方式

接下来关于图1所示意的软件系统1，描述本发明目前优选的实施例。如我们所看到的，软件系统1基于SOA，即处理由单独的组件C1、C2、C3……来执行，这些组件通过消息通信。图1还显示了也是松耦合的监控组件10，即通过接收监控消息5，该组件被通知软件系统1中正在进行什么，并在接收到监控消息时通过再次发送消息进行反应。如接下来将要说明的，以允许监控操作的最大灵活性的方式来设计监控组件10是可能的。这是通过如下方式实现的：通过知识库11的一个或多个监控本体来定义执行监控的方式，即对何种输入如何反应。

更详细地看图1，总体环境的主要部分是软件系统1，该系统是监控组件10所要监控的。系统1包括单独的组件C1、C2、C3……，这些组件通过消息通信。通过所谓的“仪表板”(dashboard)3，系统1可以提供查询和/或操纵(steering)接口。该仪表板3还可以基于称为“知识库”4的组件中存储的本体来完成自己的工作。该仪表板3还可以具备查看知识库4并更新存储其中的本体的能力。

监控组件10的任务是监视软件系统1中正在进行什么。这可能意味着两件事。监控组件必须做的第一件并且是最显然的任务是写日志20(参见图2)，即跟踪软件系统1中发生的事件，以及如果这种事件被认为是值得注意的话，则将其转换成日志条目并将其加入日志20。监控组件10可以用来做的另一个事情是对某些事件做出带告警的反应。在基于消息的体系结构中，告警意味着向非监控组件例如仪表板3或另一个操纵组件比如监控接口12发送消息。

由于基于消息的软件系统1夸耀的主要提高之一是其关于处理逻辑和/或其实现的变化的灵活性，因此整个监控系统也应该适应变化。这些变化可能如下：

1.何种事件(即消息)值得跟踪为日志条目？

2.这种事件所传达的何种信息应当被保存在日志条目中？

3.日志条目应当如何格式化？

4.哪些事件触发告警？

5.告警消息应当被发送到何处？

6.在这一告警消息中应当包含哪些信息？

7.这一告警消息应当如何格式化？

关于这些方面，监控系统应当是可参数化的。这可以通过提供一个或多个知识库11(参见图1)的本体来实现。要注意的是，两个知识库4和11可以是单独的或者组合到一个公共的总的知识库(未示出)。

监控系统的知识库11应当提供的第一类型的帮助是对事件分类的部件，以使得日志机制能够决定对于某一事件何种动作是合适的。其它必要的元信息是映射算法，以描述到来的消息5中包含的信息如何必须被转换成日志条目和/或告警消息。需要的信息的最后一部分是模式，以描述根据接收的消息向何处发送告警。

关于第一方面，可以根据两个标准对事件分类：消息的发送方和消息内容。对第一分类，为了避免对到来的监控消息5挖掘(dig)过深，监控消息5中应当包含足够用的少量信息。监控组件10接收的监控消息5代表系统组件C1、C2、C3……中任何一个组件采取的动作，监控系统获得关于该动作的通知(并非所有的事件都能触发到监控组件10的监控消息5)。知识库11优选地保存系统组件C1、C2、C3……以及它们可能的动作的表格，该表格允许进行推断是否需要记日志和/或告警。通过增加/删除/重命名组件C1、C2、C3……或组件的动作来改变软件系统1，这需要更新知识库11中存储的信息。

出于大部分目的，对消息发送方及其所通知的动作进行简单核对，这就足以决定要做什么了。例如，如下的语句是有意义的：组件C1到C3之一采取的每一个动作A1或A2都值得记入日志。然而其它情况下更详尽的分析可能是适当的。假如该动作是组件C4或C5采取的，则可能有动作A3，并且坚持某一方案可能会被处以告警。这暗示了在到来的监控消息和知识库11中的本体所描述的模式之间的一种模式匹配。不管以何种方式描述，都暗示了在优选实施例中，不但系统中可能的动作者及它们的动作，而且它们的监控消息5的内容和格式必须取得一致。操纵如何分类事件的逻辑是巧妙(subtle)的，并且由知识库11的本体来提供。

如果事件，即通知系统组件C1、C2、C3……已经采取动作的监控消息5，被检测到值得做出反应，那么就出现多个问题。消息的哪些部分应当被分别打包到日志条目和告警消息中？如何打包？如果是告警，应当被送往何处？如已指出的，到来的监控消息5的内容和格式是已知的。因此，提供了映射，该映射描述了如何将到来的监控消息5转换成日志条目或告警消息。万一出现告警，则需要找到将要被通知的组件的地址。这里有两种可能性。第一，地址可能包括在用于检测告警原因的本体中。另一方面地址可能是描述告警消息的映射的一部分。

接下来，简略描述了知识库11的小样本本体，从而示意知识库11的内容看起来如何，监控组件10如何基于该信息来执行自身工作。

示例性系统包括5个组件C1到C5，它们共执行10个动作A1到A10。当然并不是每个组件执行10个动作的每一个。下面的表格由5个组件和它们可以执行的动作组成。

组件	动作
		C1	A1、A2、A3
C2	A1、A2、A3
		C3	A1、A2、A3、A4
C4	A5
		C5	A4、A5

在本例中，当执行任意动作时，每一个组件C1、C2、C3……向监控组件10发送监控消息5，该监控消息至少包括以下信息：谁执行的动作，执行的是哪个动作。消息5另外还包括更详细地描述动作的数据。因此，发送到监控组件的典型的监控消息5是数字紧随其后的“C”、数字紧随其后的“A”以及数据部分。对于基本例子，我们假定数据部分的格式仅依赖动作，即特定动作总是以指定的数据部分格式出现，而与执行该动作的组件无关。因此我们的知识库11的本体之一的第一部分是表格，该表格说明如何根据动作来解释数据部分。

使用上述本体，现在监控组件10足够聪明来按数据方式(data-wise)解释消息5。为简单起见，我们假定向监控组件10发送消息的每一个系统组件C1、C2、C3……都希望该消息变为日志条目。为了使例子更简单，我们假定日志条目仅仅保存数据并仅增加时戳。

现在对于告警：最简单的格式的告警类似于：“如果任何人做A1，则告诉R1”。这样，第二个本体包括动作和接收方。由于这似乎仍然不是非常有用，我们为模式匹配增加了一些小的支持，称为“如果C1正在做A1，且字段11等于常量“x”，则告诉R1”。知识库11的这种告警本体可以由下面的表格表示：

我们假定发送告警仅意味着转发消息，该消息触发向新的接收者告警。

到目前为止和一些假定一起提供的两个表格已经代表了一个模型，监控组件10可以和该模型一起工作。

上述基本概念的扩展：

●假定，组件C1、C2、C3……只要执行动作就向监控组件10发送监控消息，听起来好像这两件事情同时发生。除了在技术上有挑战之外，也没有必要必须是这种情况。对于长的动作，发送一个消息指示动作已经开始并且发送另一个消息指示动作已经结束，这是恰当的。这对于需要人交互的动作和/或由子动作组成的动作而言尤其有效。关于已开始但是仍未决的动作的信息可以存储在暂时日志中，而关于已完成动作的新型可以保存在永久日志中。

●如果两个不同的组件C1、C2、C3……发送关于相同主题(即动作)的消息，这些消息没有必要必须包括同样的数据组件。本体1可以扩展为使得数据部分的定义依赖于两个键(key)。

●数据部分的定义可以更灵活。例如最右边字段的一些可以是可选的。于是，询问是否包括可选组件，这是本体2中的模式所允许的可能问题之一。

●如果不是假定记日志的类型是“记录所有”，则类似于本体2(或本体2的扩展)的第三本体2变得必要。

●在有多个接收方并且要通知哪个接收方依赖于不同模式的情况下，本体2可能针对每一对组件/动作包括多于一条线(line)。触发通知接收方的条件不必是互斥的。

●如果日志条目不应当仅仅是时戳加上消息的拷贝，那么我们需要从消息到条目的映射。这可以通过在包括变换部件的本体1中增加适当信息来处理。这可以是对各消息中所含字段的简单枚举，或到样式单(style-sheet)的链接。

●这对于告警消息更复杂的情况同样有效。这种情况下，需要将变换规约增加到本体2中。

关于实现的细节，面向消息的系统，尤其如果所关注的服务是Web服务，典型地使用XML同时作为消息格式和消息描述格式。因此XML也像是选择的格式，用于描述包括监控系统的知识库11的本体在内的本体。由于XML提供这个目的所需要的每样事务，因此这也是可以的。除了可以存储可以描述为表格的每样事务，还有用于描述本体、本体2中所需要的逻辑表达式以及变换部件的特定的XML专用语(dialect)。

例子：

接下来，将参考被设计为使得电子商务登记署(business register)在整个欧洲互通的SOA软件系统来描述本发明具体实施例的监控技术的具体例子。特别地，将描述特定用途事例的监控，从而进一步加快理解本发明的监控系统及方法的各种技术方面和优点。

用途事例“登记办公所在地的转移”描述了企业如何将自己的办公室从欧盟的一个成员国搬迁到另一个成员国。这个过程中的一个步骤是，老成员国的商业登记署(BR)将企业已成功申请了搬迁许可这一事实通知给新成员国的BR。授予这项权利伴随而来的是发放合适的法律文件，称为“证书”。

在灵活的SOA环境中，在成员国的负责组织之间交换关于发放了这种证书的消息，成员国的负责组织可以实现总体的软件系统，其中通过将消息基于对所有都可用的本体，它们对消息的内容和格式取得一致。因此，独立于软件系统自身来描述确切地发送什么以及如何将其打包到消息体中。因此，系统灵活地依赖本体，通过修改该本体容易地更新系统行为。

在图3中示意了上述基本系统。本体100可以指定消息110包括什么，例如消息号码(即指定消息类型的键，这里是“已发放证书的信息”)、发送方101和接收方102的指示、海可能有指针，其中从该指针可以检索到消息110提及的证书。

监控系统(参考图4)

监控这样一个软件系统的操作的方式不应限制通过将系统特性基于诸如图3的本体100的本体所获得的灵活性。因此，还必须通过交换消息来执行监控，其中所述消息的格式和内容是使用(其他的)本体动态取得一致的。采取的动作需要被监控组件10公告(notice)的系统组件，比如发送方101，向监控组件10发送监控消息120(参考图4)。如非监控消息一样，消息120的内容和格式由监控组件10以及所有的可能发送这样的消息(即采取这样的动作)的参与者取得一致。

监控组件10使用本体200(参考图4)来解释监控消息120并相应地做出反应。因此，监控组件10具体应当使用其接收的消息做什么，这是本体200规定的。如果代理机构处接收到的证书指示企业同时搬迁到两个成员国，那么本体200例如可以描述出错了。本体200于是还应当指定，当发生了值得注意的事情时应当采取什么动作。任意监控消息120所导致的可能的动作之一是将其表示为日志条目。具体记录哪些信息以及以何种格式记录也基于本体200(或者另一个本体，图4未示出)。

在图4的具体例子中，发送方101(例如为第一成员国工作的代理机构)已经向接收方102(例如新的成员国的管理商业登记的另一代理机构)发送消息110，该消息带有关于发放证书的信息，发送方101向监控组件10发送监控消息120来说明它已经完成上述过程(参考图4)。监控消息120的内容和格式由对发送方101、接收方102以及监控组件10同时可用的本体200取得一致。

在图4的例子中，监控消息120包括动作号码(或者某个其它唯一的标识符，标识由消息120用文件证明的(documented)动作的类型)、发送方101、接收方102，可能还有指向被发送的证书的指针，可能还有更多，例如关于具体谁做了这个动作、已经发送什么额外信息、什么额外信息是可用的但是还没有被发送等等的信息。

被监控组件10访问的图4的本体200不但包括如何解释可能被发送到监控组件10的监控消息120的协议。其还提供相应地做出反应所必须的所有信息。例如，对于那些需要将一条或多条日志条目增加到日志20的监控消息，本体200特别地包括如何将消息转换为这样一条日志记录的信息。如我们可以从在图4的本体200中示意性插入所看到的，最后将在日志20中记录的信息包括时戳、关于参考动作号码记录什么动作的指示、动作的参与者，可能还有指向相关文件的指针，等等。

读取日志

已经写入这样定义的日志条目之后，问题出现了：随后如何通过查询读取日志20？直接查询日志20是不可能的，这是因为将要被查询的数据的结构对外部的请求者而言是不可知的。因此，必须建立一种机制，该机制基于数据模型提供查询接口，其中所述数据模型是描述到来的消息的本体所提供的。然后该机制必须使用到另一个本体所描述的日志格式的映射，从而将原始查询变换为适合真正日志格式的另一个查询。执行了对日志20的变换后的查询之后，必须将结果重新变换成适合向原始查询做出回应的结果。

在图5的例子中，西西里(Sicily)的BR的代理机构已经发放了允许某个企业搬迁到爱尔兰的证书。对于一些成员国(如意大利)，由几个本地代理机构承担国家的BR的动作，而在其它成员国(如爱尔兰)只有一个代理机构。因此，当公司想从西西里搬走时，公司联系它本地的BR代理机构。当西西里代理机构授权搬走(即向公司发放证书)时，爱尔兰管理BR的代理机构被通知未来的搬迁。如以上关于图4所说明的，之后通知监控组件10已经发生了这样的一个动作以及(如本体200所定义的)相应的日志条目被创建。

如果一人想获知关于从西西里搬迁到爱尔兰的一些信息，以下查询Q1似乎是恰当的：

for $event in collection(“events”)/TransferOfSeat

where $event/form/land＝”Italy”

      and $event/from/province＝”Sicily”

      and $event/to＝”Ireland”

 return $event

通过在本发明的上下文优选使用的W3C，在XQuery即XML查询语言中写查询Q1。但是，通常不需要这样。另外，日志和其它人工产物(artifact)(尤其是本体)不必要以XML格式。本例子基于XML以及XQuery两者，这是因为通过其最容易描述，也因为其被认为是恰当的技术。

在查询Q1中，除了XQuery标准所规定的那些部分(定义术语比如“for、where、collection”等等)，还有依赖于将被查询的数据看起来如何的其它部分(events、TransferOfSeat、from、land、department、to)。这些没有包含在XQuery语言集中，但是取自于与数据结构有关的元数据。在XML中，XML Schema处理这样的数据，另一个公知的W3C标准描述XML语言结构。

以上出现的典型查询Q1指向监控组件10。监控组件10知道存在哪些数据字段(可能是通过处理作为其本体200的一部分的XML Schema而知道的)，因此能够提供合适的语言集从而查询设备以及决定查询Q1是否有意义。在该例子中，监控组件10知道有一个称为“events”的集合(collection)，该集合包括“TransOfSeat”条目以及这些条目看起来如何。

另外，监控组件10从其本体200知道如何将查询Q1适应于真正日志20的格式Q2。这样的映射可能工作如下：

●日志20将事件(如几乎所有其它事情可能的)描述为日志条目。

●“TransOfSeat”是日志条目，带有标识事件类型的特定号码。

●对于这类日志条目，“from”和“to”字段代表BR代理机构。

●BR的代理机构由它们所属国家的名称，或(如果国家有多个BR的话)国家加上本地BR的名称并用斜线分隔来表示。

●在日志条目中，有关位置的文本常量被翻译为英语；这样必须在查询中相应地处理常量。

因此由此产生的查询Q2可能如下所示：

for $log in collection(“logs”)/logEntry

where $log/actnr＝1234

      and $log/br1＝“Italy/Sizilia”

      and $log/br2＝“Ireland”

return $log

发现对应于查询Q2的日志条目之后，可以将结果(日志条目的列表)变换回原始查询Q1所请求的格式(事件的列表)。这是通过相反地使用本体200中的相同信息以及用于变换查询Q1的上述考虑来获得的。

Claims (26)

1.一种针对异常运行时情况和/或性能问题而监控软件系统(1)的方法，所述软件系统(1)基于面向服务体系结构(SOA)并包括通过发送消息(110)相互通信的组件(C1，C2，C3，……，101，102)，所述方法包括以下步骤：

a.由监控组件(10)接收监控消息(5，120)，所述监控消息(5，120)是从所述软件系统(1)的系统组件(C1，C2，C3，……，101)发送的；

b.所述监控组件(10)提供第一本体(11，200)，所述第一本体包括至少一个用于所述监控消息(5，120)的解释规则；和

c.根据所述至少一个解释规则，所述监控组件(10)做出反应，其特征在于：

d.所述监控组件(10)的反应包括通过如下方式修改所述第一本体(11，200)：

通过所述监控组件，观测到根据通过检查以前的过程而获取的知识，所述监控组件所查找的模式已经改变；以及

相应地动态改变所述至少一个解释规则。

2.如权利要求1所述的方法，其中所述软件系统(1)的组件(C1，C2，C3，……，101，102)之间所交换的消息(110)的格式和内容由所述第一本体或第二本体(4，100)来确定。

3.如权利要求1或2所述的方法，其中使用本体语言OWL、RDF、DAML-OIL和Topic Maps中的至少一种来定义所述第一本体和第二本体(4，11，100，200)。

4.如权利要求1或2所述的方法，其中所述第一本体(11，200)的至少一个解释规则确定是否由所述监控组件将信息记入日志。

5.如权利要求4所述的方法，其中所述第一本体(11，200)的至少一个解释规则确定所述监控组件(10)以何种格式记录所述信息。

6.如权利要求4所述的方法，其中在永久日志或暂时日志中记录所述信息。

7.如权利要求1或2所述的方法，其中从所述软件系统(1)的所述系统组件(C1，C2，C3，……，101)发送到所述监控组件(10)的所述监控消息(5，120)包括将被记录事件的类型的唯一标识符。

8.如权利要求1或2所述的方法，其中所述解释规则触发所述监控组件(10)的告警消息。

9.如权利要求8所述的方法，其中，所述第一本体(11，200)的解释规则定义所述告警消息的接收者和/或所述告警消息的内容和/或所述告警消息的格式。

10.一种用于查询使用如权利要求4所述的方法为基于SOA的软件系统(1)所创建的日志(20)的方法，包括以下步骤：

a.所述监控组件(10)接收查询日志(20)内容的查询消息(Q1)，所述查询消息(Q1)与所述监控组件(10)可使用的第一本体(200)的至少一个规则相一致；

b.将所述查询消息(Q1)映射为适合所述日志(20)的查询格式(Q2)，所述映射基于所述监控组件(10)可使用的第二本体或所述第一本体(200)的至少一个规则；

c.执行映射后的查询(Q2)并在将结果映射为基于所述第一本体(200)或所述监控组件(10)可使用的多个本体的输出格式后，返回结果。

11.如权利要求10所述的方法，其中所述查询消息(Q1)作为XQuery消息接收。

12.如权利要求11所述的方法，其中所述第一本体(200)包括至少一个XML Schema，该XML Schema定义所述查询消息(Q1)的数据结构和/或适合所述日志(20)的查询格式(Q2)。

13.如权利要求10-12任一所述的方法，其中所述步骤b中的映射包括，基于事件类型的唯一标识符将所述查询消息(Q1)中包含的事件映射为所述日志(20)的日志条目。

14.一种针对异常运行时情况和/或性能问题而监控软件系统(1)的系统，所述软件系统(1)基于面向服务体系结构(SOA)并包括通过发送消息(110)相互通信的组件(C1，C2，C3，……，101，102)，所述系统包括以下部件：

a.用于接收监控消息(5，120)的部件，所述监控消息(5，120)是从所述软件系统(1)的系统组件(C1，C2，C3，……，101)发送的；

b.用于提供第一本体(11，200)的部件，所述第一本体包括至少一个用于所述监控消息(5，120)的解释规则；和

c.用于根据所述至少一个解释规则，做出反应的部件，其特征在于：

所述反应包括通过如下方式修改所述第一本体(11，200)：

观测到根据通过检查以前的过程而获取的知识，所查找的模式已经改变；以及

相应地动态改变所述至少一个解释规则。

15.如权利要求14所述的系统，其中所述软件系统(1)的组件(C1，C2，C3，……，101，102)之间所交换的消息(110)的格式和内容由所述第一本体或第二本体(4，100)来确定。

16.如权利要求14或15所述的系统，其中使用本体语言OWL、RDF、DAML-OIL和Topic Maps中的至少一种来定义所述第一本体和第二本体(4，11，100，200)。

17.如权利要求14或15所述的系统，其中所述第一本体(11，200)的至少一个解释规则确定是否将信息记入日志。

18.如权利要求17所述的系统，其中所述第一本体(11，200)的至少一个解释规则确定以何种格式记录所述信息。

19.如权利要求17所述的系统，其中在永久日志或暂时日志中记录所述信息。

20.如权利要求14或15所述的系统，其中从所述软件系统(1)的所述系统组件(C1，C2，C3，……，101)发送的所述监控消息(5，120)包括将被记录事件的类型的唯一标识符。

21.如权利要求14或15所述的系统，其中所述解释规则触发告警消息。

22.如权利要求21所述的系统，其中，所述第一本体(11，200)的解释规则定义所述告警消息的接收者和/或所述告警消息的内容和/或所述告警消息的格式。

23.一种用于查询使用如权利要求17所述的系统为基于SOA的软件系统(1)所创建的日志(20)的系统，包括以下部件：

a.用于接收查询日志(20)内容的查询消息(Q1)的部件，所述查询消息(Q1)与第一本体(200)的至少一个规则相一致；

b.用于将所述查询消息(Q1)映射为适合所述日志(20)的查询格式(Q2)的部件，所述映射基于第二本体或所述第一本体(200)的至少一个规则；

c.用于执行映射后的查询(Q2)并在将结果映射为基于所述第一本体(200)或多个本体的输出格式后，返回结果的部件。

24.如权利要求23所述的系统，其中所述查询消息(Q1)作为XQuery消息接收。

25.如权利要求24所述的系统，其中所述第一本体(200)包括至少一个XML Schema，该XML Schema定义所述查询消息(Q1)的数据结构和/或适合所述日志(20)的查询格式(Q2)。

26.如权利要求23-25任一所述的系统，其中所述用于将所述查询消息(Q1)映射为适合所述日志(20)的查询格式(Q2)的部件中的映射包括，基于事件类型的唯一标识符将所述查询消息(Q1)中包含的事件映射为所述日志(20)的日志条目。

Images