Patent Application
20080172654
This application claims benefit of priority of European application no. 07 000 683.8 titled “Method and System for Monitoring a Software System”, filed Jan. 15, 2007, and whose inventor is Andreas Frohlich, Dr. Harald Schöning, Juliane Harbarth and Dr. Michael Gesmann.
European application no. 07 000 683.8 titled “Method and System for Monitoring a Software System”, filed Jan. 15, 2007, and whose inventor is Andreas Fröhlich, Dr. Harald Sc{umlaut over (h)}oning, Juliane Harbarth and Dr. Michael Gesmann, is hereby incorporated by reference in its entirety as though fully and completely set forth herein.
The present application relates to a method and a system for monitoring a software system, in particular for monitoring a software system based on a service oriented architecture.
Monitoring a software system is an important technical task to assure that the system operates as desired. This applies not only to the development stage of a software system, when the source code repeatedly needs to be debugged, but also to the deployment phase, when exceptional runtime situations must be controlled or the performance of the system is to be evaluated for maintenance or other purposes. In its simplest form, monitoring is just a log-producing device noticing actions occurring in the system, manifesting the actions as a log-entry, and adding the entries to a log. In a much broader sense, monitoring can be anything that looks at what is going on and reacts thereupon. Looking at what is going on may include the ability to obtain information about a system's current status and its history.
Traditionally, monitoring a software system comprises the generation of one or more log files according to some fixed, predetermined rules of the monitoring system. Events are logged, possibly together with corresponding timestamps, so that the later inspection of such a log file allows understanding the sequence of events as they occurred in the software system during runtime. In a more advanced alternative, the monitoring process can be controlled using a configuration file, such as the configuration file for the Log4j project, which determines at runtime, what information is written to a log file. However, the logging options provided by such a configuration file are limited to a predetermined logger hierarchy and therefore provides only a very limited amount of flexibility.
Over the years, software systems have become more complex, which makes monitoring difficult. More important, the concept of a service oriented architecture (SOA) has been increasingly used, wherein loosely coupled components, such as web services, are performing the processing by exchanging messages. An SOA is ideally adaptable to changes with respect to both logical changes of the processing flow and changes of the underlying technical implementation.
However, using the above described traditional approach for monitoring the messages exchanged during the operation of an SOA based software system (or any other system of similar flexibility and complexity), requires an adaptation of the whole monitoring system, whenever any changes are made to the format or content of any message to be logged. As a result, the main advantage of using a SOA, namely its flexibility, is essentially lost if the traditional monitoring approach of the prior art is used, wherein the monitoring is determined by a set of more or less fixed rules implemented into the monitoring system. Furthermore, repeated changes of the monitoring system also affect the resulting log file(s) so that its inspection and understanding becomes more and more difficult. Thus, improvements in monitoring a software system (e.g., an SOA software system) are desired.
Various embodiments are presented of a method for monitoring a service oriented architecture (SOA).
The method may include receiving a monitoring message by a monitoring component, where the monitoring message may be sent from a system component of the software system. The method may further include providing an ontology comprising at least one interpretation rule for the monitoring message by the monitoring component. Additionally, the method may include the monitoring component reacting in accordance with the at least one interpretation rule.
Accordingly, the monitoring method may use an ontology-based approach instead of a fixed set of monitoring rules permanently implemented in one way or the other into the monitoring component itself. Changing the ontology allows to dynamically adapt the monitoring rules without having to change the monitoring component itself.
In some embodiments, the format and content of the messages exchanged by the components of the software system may be determined by another or the same ontology. In such a system, wherein the software components are loosely coupled and only communicate via sending messages, a higher degree of flexibility may be achieved when the messages exchanged do not have a fixed format. On the contrary, the message content and format can dynamically be agreed upon using an ontology available to all components in the system. Since the monitoring method may similarly use monitoring messages based on an ontology (possibly an extension of the same ontology as used by the SOA to be monitored), it is as flexible as such a SOA itself.
The ontology may be defined using at least one of the ontology languages OWL, RDF, DAML-OIL and Topic Maps (which are described under “http://www.w3.org” and “www.topicmaps.org”), among others. As used herein, the term “ontology” is used to mean an implementation for establishing the concepts of objects and classes with properties and relations among each other to model a subset of the world that is necessary for the task at hand.
In some embodiments, the at least one interpretation rule of the ontology may be used to determine whether information is logged by the monitoring component and/or in which format the information is logged by the monitoring component. Therefore, the whole monitoring process may be determined or driven by the ontology.
In one embodiment, the information may be logged in a permanent log and a temporary log. A temporary log may, for example, comprise information about a pending process such as the beginning of the process, whereas the permanent log may only comprise information about finished processes.
In one embodiment, the reacting of the monitoring component may include modifying the ontology. For example, patterns the monitoring component is looking for may change and the changes may depend on knowledge gained by examining previous processes. Using an ontology with interpretation rules, which can be dynamically changed, may allow for this kind of feedback.
The monitoring message sent from the system component of the software system to the monitoring component may include a unique identifier of a type of an event to be logged. This may enable mechanisms described further below to refer to log entries using this identifier.
Additionally, a method is provided for querying a log created using any of the above described methods. The method may include receiving a query message for content of the log by the monitoring component, the query being in accordance with at least one rule of an ontology accessible by the monitoring component. The method may further include mapping the query message into a query format suitable for the log, the mapping being based (possibly) on at least one rule of another or the same ontology accessible by the monitoring component. Furthermore, the method may include executing the query and returning the results after mapping them into an output format based on the ontology or the ontologies accessible by the monitoring system.
Accordingly, obtaining information from the log, e.g., reading the log, may again driven by one or more ontologies, wherein the ontologies may be an extension to the other, above mentioned ontologies or a separate ontology accessible by the monitoring component. Since the content and structure of the log entries flexibly depend on ontologies, it is impossible to understand the relationships between log entries without additional input. In other words, the log may not be asked directly, but questions may be asked to the monitoring component, which may consult the ontologies knowledge base for the exact data structure the logs are provided in so that the original query can be correspondingly mapped.
In some embodiments, the query message may be received as an XQuery message and the ontology or the ontologies may include at least one XML Schema defining the data structures for the query message and/or the query format suitable for the log.
Finally, the present invention provides a monitoring system which may be adapted to perform any of the above described methods. Such a monitoring system may either be part of the overall software system or can separately be provided. The monitoring system can be realized by hardware and/or software (e.g., as program instructions stored on a memory medium), for example by a suitable computer program with instructions for performing the technical steps outlined above.
A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings, in which:
While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.
In the following, various embodiments of a method for monitoring a software system (in particular a service oriented architecture software system) are described with respect to a software system 1 as schematically shown in
Looking more in detail at
The role of the monitoring component 10 may be to keep an eye on what is going on in the software system 1. This can mean two things. The first and most obvious task a monitoring component may perform is to write a log 20 (cf.
Since one of the main enhancements a message based software system 1 boasts is its flexibility with respect to changes of the processing logic and/or its implementation, the overall monitoring system should also be adaptive to changes. Such changes could be the following:
1. Which events (e.g., messages) are worth being tracked as a log entry?
2. Which information conveyed by such an event should be kept in the log entry?
3. How should the log entry be formatted?
4. Which events cause alerts?
5. Where should an alert message be sent to?
6. Which information should be contained in this alert message?
7. How should this alert message be formatted?
The monitoring system should be parameterizable with respect to these aspects. This may be achieved by providing the one or more ontologies of the knowledge base 11 (cf.
The first type of assistance the knowledge base 11 of the monitoring system may provide is a means of categorizing events in order to enable the log mechanism to decide what action is appropriate for a certain event. Other necessary meta-information may include mapping algorithms to describe how the information contained in an incoming message 5 has to be turned into log entries and/or alert messages. The last bit of information needed may be a pattern to describe where to send alerts to depending on the messages received.
With respect to the first aspect, categorizing an event can be done by two criteria, the message's sender and the message content. To avoid digging too deep into an incoming monitoring message 5 for a first categorization, there may be a small bit of information contained in the monitoring message 5 that is sufficient. The monitoring message 5 received by the monitor component 10 may represent an action undertaken by any of the system component C1, C2, C3, . . . about which the monitoring system may become informed (not all events may cause a monitoring message 5 to the monitoring component 10). The knowledge base 11 may keep a table of system components C1, C2, C3, . . . and their possible actions, which allows to infer, whether logging and/or alerting is required. Changing the software system 1 by adding/removing/renaming components C1, C2, C3, . . . or component's actions may require the updating of this information stored in the knowledge base 11.
For most purposes, a simple check upon a messages sender and the action it informs about may be sufficient to decide what to do. For example, a statement that every action A1 or A2 undertaken by one of the component C1 to C3 is worth being logged, makes sense. In other cases, however, a more thorough analysis might be appropriate. There might be an action A3 that, if undertaken by component C4 or C5 and adhering to a certain schema, may be dealt with by an alert. This implies a kind of pattern matching between incoming monitoring messages and patterns described by the ontologies in the knowledge base 11. Whichever way this is described, it implies that, in some embodiments, not only the possible actors in the system and their actions, but also the content and format of their monitoring messages 5 may be agreed upon. The logic that steers how to categorize an event is subtle and provide d by the ontologies of the knowledge base 11.
If an event, e.g., a monitoring message 5 informing about a system component C1, C2, C3, . . . having undertaken an action, is detected worth as being reacted upon, a number of questions arise. Which parts of the message should be packed into a log entry, respectively into an alert message, and how? If it is an alert, where is it addressed to? As already pointed out, the contents and formats of the incoming monitoring messages 5 may be known. Therefore, a mapping may be provided that describes how the incoming monitoring message 5 is transformed into the log entry or an alert message. In case of an alert, the address of the component to be informed may need to be found. There are two possibilities here. Firstly, it may be contained in the ontology that is used to detect a reason for alert. On the other hand it may be part of a mapping describing the alert message.
In the following, a small sample ontology of the knowledge base 11 is sketched to illustrate how its content can appear and how the monitor component 10 performs its work based on this information.
The exemplary system comprises five components C1 to C5 which may in total perform ten actions A1 to A10. Of course not every component may perform each of the ten events. The following table comprises the five components and the actions they can perform.
In the present example, each component C1, C2, C3, . . . , when performing any action, sends a monitoring message 5 to the monitoring component 10 that at least contains the information who has performed the action and which action was performed. The message 5 additionally contains data describing the action in more detail. Thus, a typical monitoring message 5 sent to the monitoring component is ‘C’ followed by a number, ‘A’ followed by a number, and a data part. For the basic example, we assume that the data part's format only depends on the action, e.g., a specific action always manifests in a specific data part format independent of the component it was performed by. So our very first bit of one the ontologies of the knowledge base 11 may be a table that explains how to interpret the data part depending on the action.
Using the above ontology the monitoring component 10 may be now sufficiently smart to interpret the messages 5 data-wise. For simplicity, we assume that every system component C1, C2, C3, . . . , that sends a message to the monitoring component 10, wants this message to become a log entry. To keep the example even simpler, we assume that the log entry just keeps the data and only adds a time-stamp.
Now for the alerts: In its simplest form an alert is something like: ‘If anybody is doing A1 tell R1’. Thus, a second ontology contains actions and recipients. Since this does not seem very useful yet we add some small support for pattern matching, saying ‘If C1 is doing A1 and field 11 equals a constant “x” tell R1’. This alert ontology of the knowledge base 11 can be represented by the following table:
We assume that sending an alert just means forwarding the message that causes the alert to the new recipient.
The two tables provided so far together with some assumptions already represent a model a monitoring component 10 can work with.
Extensions of the above described basic concept:
Saying that a component C1, C2, C3, . . . sends a monitoring message to the monitoring component 10 whenever it performs an action sounds as if these two things are supposed to happen at once. Apart from being technically challenging this does also not necessarily have to be the case. For a long action, it might be appropriate to send a message that the action has been started and another one that it has ended. This especially holds for actions that require human interaction and/or comprise sub-actions. The information about a started but still pending action could be stored in a temporary log, whereas the information about a finished action may be kept in a permanent log.
If two different components C1, C2, C3, . . . send a message about the same topic (e.g., action) these messages do not necessarily have to contain the same data component. Ontology 1 can be extended to make the data part definition depend on two keys.
The data part definition can be more flexible. For example, some of the rightmost fields may be optional. Asking whether an optional component is contained is then one of the possible questions being allowed in patterns in Ontology 2.
A third ontology 2 similar to ontology 2 (or an extension to ontology 2) becomes necessary, if the logging is not assumed to be of the “log all” kind.
Ontology 2 might contain more than one line per Component/Action pair in cases where there are multiple recipients and which one has to be informed depends on different patterns. The conditions that cause a recipient to be informed need not be mutual exclusive.
If a log entry should not be just a time-stamp plus a copy of the message, we need a mapping from messages to entries. This can be handled by adding appropriate information in ontology 1 containing a means of transformation. This can be a simple enumeration of fields contained in the respective message or a link to a style-sheet.
The same holds if an alert message should be more sophisticated. In this case the transformation specification needs to be added to Ontology 2.
With respect to the details of implementation, message oriented systems, especially if the services in question are Web services, typically use XML as both the message format and the message description format. Thus, XML also seems the format of choice for describing the ontologies, including the ontologies of the knowledge base 11 of the monitoring system. This is just as well since XML offers everything required for this purpose. Besides being able to store everything that can be described as a table, there are also specific XML dialects for describing ontologies, logical expressions as required in Ontology 2, and means of transformation.
In the following, a concrete example of the monitoring technique of one embodiment is described with reference to an SOA software system designed to enable an electronic business register interoperability throughout Europe. In particular, the monitoring of a specific use case will be described to further facilitate the understanding of the various technical aspects and advantages of the monitoring system and method presented.
The use case, “Transfer of registered Office”, describes how an enterprise moves its office from one member state of the EU to another. One step in this process is that the business register (BR) of the old member state informs the BR of the new member state about the fact that the enterprise has successfully applied for the allowance to move. Granting this right comes along with issuing a suitable legal document referred to as ‘certificate’.
In a flexible SOA environment, the responsible organizations of the member states, between which these messages about issuing such a certificate are exchanged, may implement an overall software system wherein they agree upon the content and format of such a message by basing it on an ontology available to all. Thus, what exactly is sent and how this is packed into the message body is described independently from the software system itself. Thus, the system flexibly depends on an ontology and is easily updated in its behaviour by modifying this ontology.
The above described basic system is illustrated in
Monitoring the System (cf.
The way in which the operation of such a software system is monitored may not restrict the flexibility achieved by basing the system's behaviour on ontologies such as the ontology 100 of
The monitoring component 10 may interpret the monitoring message 120 using the ontology 200 (cf.
In the concrete example of
In the example of
The ontology 200 of
Having written such defined log entries, the problem arises how the log 20 can afterwards be read via queries. It may be impossible to query the log 20 directly, since the structure of the data to be queried may be unknown to an external requester. Thus, a mechanism may be established to offer a query interface based upon the data model provided by an ontology describing the incoming messages. The mechanism may then use the mapping to the log format described by another ontology to transform the original query into another query suitable for the real log format. Having executed the transformed query upon the log 20, the result may be retransformed into a result suitable for responding to the original query.
In the example of
If a person wants to get some information about moves from Sicily to Ireland, the following query Q1 seems appropriate:
The query Q1 is written in XQuery, i.e., an XML query language by the W3C, which may be used in the context of the presently described method. However, this need not generally to be the case. Further, also the logs and other artifacts (especially the ontologies) need not necessarily to be in XML. The present example is based on both XML and XQuery, because it is most easily described thereby and also because it is considered an appropriate technology.
Apart from those parts in the query Q1 that are ruled by the XQuery standard (defining terms such as “for, where, collection, etc.”) there are other bits that depend on how the data to be queried looks like (events, TransferOfSeat, from, land, department, to). These are not contained in the XQuery language set but are taken from meta-data pertaining to the data structure. In XML, such data is dealt with by XML Schema, another well-known W3C standard describing XML data structure.
The above presented exemplary query Q1 is directed towards the monitoring component 10. The monitoring component 10 may know which data fields exist (possibly by possessing an XML Schema as part of its ontology 200) and may thus be able to both offer a suitable language set to the querying device and decide whether the query Q1 makes sense. In the example, the monitoring component 10 may know that there is a collection called ‘events’ that contains ‘TransferOfSeat’ entries and how these entries look like.
Additionally, the monitor component 10 may know from its ontology 200 how to adapt the query Q1 to the format Q2 of the real log 20. Such a mapping might work as follows:
Thus the resulting query Q2 might look as follows:
Having found the log entries corresponding to the query Q2, the result (a list of log entries) can be transformed back into the format requested by the original query Q1 (a list of events). This is achieved by inversely using the same information in the ontology 200 and the above described considerations used for transforming the query Q1.
Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
| Number | Date | Country | Kind |
|---|---|---|---|
| 07 000 683.8 | Jan 2007 | EP | regional |
