Browse Prior Art Database

Introspective Application Programming Interface Disclosure Number: IPCOM000124732D
Original Publication Date: 2005-May-04
Included in the Prior Art Database: 2005-May-04
Document File: 2 page(s) / 24K

Publishing Venue



Writing a software layer in front of an internal application programming interface (API) is one way to provide an external API for application programmers to use. A problem that occurs is keeping the external layer current when the internal API changes due to new features and maintenance. Typically, a maintenance programmer who updates the internal API will need to remember to update the external layer. Often this task is neglected, or the maintenance programmer is unaware of the external API, or s/he is not capable of updating it. The result is that the external layer grows out of date and cannot be used to access the newest features of the internal API. The idea disclosed here provides a way to efficiently and accurately report on the currency of the external API.

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

Page 1 of 2

Introspective Application Programming Interface

Modern programming languages like Java provide the ability to perform introspection on class objects that comprise a software system. By using introspection, the methods and data types provided by classes in different layers of a software system can be compared.

In the case at hand, there are two layers involved: (1) an internal layer that provides a full set of methods and data transport classes for interacting with the core system, and (2) a public, external layer that is a subset of the internal layer. The internal layer typically grows and changes during the product lifecycle as new features are added and fixes are made.

When written in a language that supports introspection, the classes in each layer can be called upon programatically to reveal the messages that they process and the data protocols that these messages require. In short, the internal and external APIs can be queried and compared programatically.

The core idea disclosed here is to provide a utility API that provides a list comparing (1) the messages used by each layer and (2) the data protocols provided by each layer. The utility API can reside in either layer. It can be called to provide a difference report at milestones in the product cycle for use by a programmer in updating the external API so it stays current with the internal API.

Main Idea

Each of the class definitions in the external layer corresponds to exactly one class definition in the internal layer. A string in each external class holds the full name of the corresponding internal class. In this way the correspondence of internal classes and internal classes can be known by the utility class that produces the difference reports.

The utility class provides two methods, one to compare method signatures in the two layers, and the other to compare data transfer objects in the two layers.

Both methods are similar in function, so the following general pseudocode description applies to both.

method compare (external...