Browse Prior Art Database

Extracting application profiles from a product's trace data

IP.com Disclosure Number: IPCOM000145599D
Original Publication Date: 2007-Jan-18
Included in the Prior Art Database: 2007-Jan-18
Document File: 3 page(s) / 56K

Publishing Venue

IBM

Abstract

An application profile describes how a user's application utilises middleware API functions. This publication describes how a profile can be extracted from trace data generated by the middleware at runtime. The application profile provides an overview of the application and its usage of the middleware functionality based around the distribution of API calls driving the system. In turn the profile can be used to determine potential impact from release to release migrations and give the customer a true representation of their usage of the middleware layer.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Extracting application profiles from a product 's trace data

    Complex middleware products are designed to provide flexible services to the customers who buy them. During the development of such products the test and development teams make assumptions about how customers will make use of the product. These assumptions may affect the way a particular function is tested, or even how it is developed. however, it can be extremely difficult to verify that these assumptions are correct and that they truly represent the products usage when it's out in the field. Incorrect assumptions may lead to poorly tested code, or architectural decisions being taken that have a negative affect when used by the customer.

    The best descriptions of a product's usage are the customer applications, however, customers can be unwilling to share their application source as it may contain proprietary information or in some cases they may no longer have the source code. Another means to determine their usage is in simple discussion with a customer, but this can be unreliable because the people involved in the discussion may not know the low-level detail of their applications and consequently make their own assumptions about how their applications work.

    The novelty here is to extract usage information for a product based on the runtime trace data it generates when a customer runs their application.

    This invention takes a product's runtime trace, generated when a customer application makes use of the product, and extracts from it an 'application profile' which describes the elements of the product the application makes use of.

    This is possible because a trace entry either contains within it data that explicitly describes a functional element of the product or can be mapped back to a source file that in turn can be associated with a functional element of the product. As this invention uses data generated directly by the product it does not suffer the problems described above.

    As an example, consider a product that provides 3 simple API calls to allow an application to Read a record, Rewrite a record, or Delete a record. The diagram below shows a product's trace file generated when a customer application is run against the product. Throughout the trace there are entries that represent the invocation of one of the three API calls (shown here as either, READ, REWRITE, or DELETE) and between them the ellipses represent other trace statements generate...