A logging concept for backend system access-oriented application server enviornments
Original Publication Date: 2004-Jul-23
Included in the Prior Art Database: 2004-Jul-23
In distributed systems software development projects, logging and tracing often is an aspect that is not a prime concern for the project team. Business-related, functional and infrastructure issues need to be resolved first, and hence logging and tracing is being treated rather superficially. Later on, once the code and unit test development efforts give way to integration and testing activities, having comprehensive logging information about user / system interaction and the resulting system behavior becomes crucial for finding system errors and malfunctions. Another couple of months later after the system went live and is in production, ongoing monitoring of user interaction with the system, as well as system component interaction within the system, is needed to isolate and resolve technical and business-level related issues quickly. Also then, appropriate logging information out of the system complements information that systems monitoring and management tools gather and provide. The logging concept presented here supports an enterprise-wide identification of application-level errors in distributed application environments. It provides a schema for unique specification of errors across applications and application components in an enterprise, taking into account that identical errors within a distinct component may have deviating significance and meaning depending on the business-level scope, in which the component has been employed. Thus, system operations staff may maintain an enterprise-level error catalog, enterprise-level log analyzing tools and global log repositories, and over time discover error patterns and resolution procedures more easily in their application landscape than with isolated error and log mechanisms. The concept is basically API and tool independent. The prime focus of this paper is the information structure that is logged rather than the technology used to actually transfer the information from the event source to the ultimate event sink or consumer.
A logging concept for backend system access -
-oriented application server oriented application server
The logging concept addresses the requirement for fine -grained error identification within distributed application environments, supporting operations staff to isolate problems quickly and enabling very distinct error messages for system users. It is based on the concept of object identifiers (see ) and object identifier portions managed by individual application building blocks, which are combined through a global transaction ID. The transaction ID is generated at the user's access point to the system and must be passed through the system as an additional business data field, to make it available to all components that are logging information . Participating applications of the application cluster (or system) and components within these applications must be uniquely identifiable, resulting in unique object identifiers . The transaction ID enables operations staff to isolate the root cause of a problem from logged accompanying symptoms and the concatenated object identifiers may be translated into very distinct error messages at the user's contact point with the application cluster.
The approach is based on the assumption that every sufficiently complex application design introduces some sort of layered abstraction or component responsibilities, and on the concept of object identifiers (OIDs), formally defined in
. An object identifier is a unique identification of an object within a registration tree in a dotted decimal number notation. Figure 1 illustrates a simplified registration tree.
Figure 1: Object Identifiers in an Object Registration Tree
In this tree the OID of the square is the dotted decimal number 1.2.2, starting from the root of the tree. OID 3.1 uniquely identifies the circle, and OID 3.2.1 points to the rhombus.
For the logging concept an object identifier consisting of a technical part and a business-level (or functional) part uniquely identifies errors. The business-level part, which can e.g. be derived from the use cases and use case groups describing the system behavior, assures that identical errors on technical level can be identified in relationship to their business-level scope. An application component failure, such as e.g. an absent database connection or a parameter format exception, may have different meaning or significance in deviating business scenarios . The ultimately unique object identifiers composed of the technical and the business -level identification may be mapped to an appropriate error description for logging or user display.
An Application Model
A sufficiently generic model of an application structure may help to further explicate the concept. Figure 2 outlines the model that is used in the remainder of this paper to illustrate the fundamental principles . Ple...