Browse Prior Art Database

Method for designing a flexible and backward compatible API

IP.com Disclosure Number: IPCOM000184831D
Original Publication Date: 2009-Jul-01
Included in the Prior Art Database: 2009-Jul-01
Document File: 7 page(s) / 122K

Publishing Venue

IBM

Abstract

Disclosed is a method for designing the API of a common component. This API design is generic, has the capability to input not only objects of different types but also object graphs of any depth and breadth. This API design is also flexible and backward compatible and supports multiple versions of CDM used by different consuming products.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 7

Method for designing a flexible and backward compatible API

A common way of designing an API is to use transfer objects (e.g. TADDM's model objects, or CCMDB's Maximo business objects, etc. ) to pass information between a consuming product and the common component. There are many disadvantages of this approach, specifically,

Transfer objects are often product-specific.

It often requires a very large number of transfer objects. One for each type of object. Since each consuming product only uses a subset of the objects, it is a significant memory overhead to include a large set of objects in each consuming product.

Over time, new classes and new attributes will be added or some attributes may be deprecated. To address these changes, new transfer objects will need to be created or existing transfer objects will need to be changed. When a transfer object has changed, consuming products need to upgrade to pick up the latest transfer objects, this often creates backward compatibility issues.

There is one transfer object per object. It is difficult to write generic getter or setter methods for this type of transfer objects. One often has to use Java* reflection or change the code periodically to handle new or changed transfer objects.

Instead of using transfer objects for transferring information between consuming products and a common component, this disclosure uses an array of HashMap's and nested HashMap. Each HashMap in the array carries information of an object including its class type, its attributes, and naming contexts. The key of the HashMap is the attribute name and the value is the attribute value. The naming contexts are specified in a separate HashMap, the key of the naming context HashMap is the role of the Naming Context, and the value is either a number which points to another object in the HashMap array, or a GUID which references an existing object in the database.

Following examples demonstrate various usage of an array of HashMap's and the nested naming context HashMap.

Example 1 use an array of HashMap's (i.e. identifyingAttributeMaps) to input bulk homogeneous or different types (or classes) of objects. Only two ComputerSystem's, two IpAddress, and two SNAProtocolEndpoint's are shown in this example. But, a caller can use an array of HashMap's to input hundreds or thousands of objects of the same or different types.

1

Page 2 of 7

Example 2 uses an array of HashMap's (i.e.identifyingAttributeMaps) and nested NamingContext HashMap's to input two ComputerSystem graphs (see Figure 1). These ComputerSystem graphs use direct (index based) naming contexts within the structure. That is, objects and their naming contexts are provided in the same HashMap array. An object references its naming context via the naming context's index (or position) in the array.

Figure 1

2

[This page contains 1 picture or othe...