Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Resolver algorithm and method to keep system code flexible

IP.com Disclosure Number: IPCOM000234898D
Publication Date: 2014-Feb-13
Document File: 6 page(s) / 105K

Publishing Venue

The IP.com Prior Art Database

Abstract

The API for a piece of code is defined as input and output variables in some required state. The variables may be of arbitrary complexity. The state is indicated by a unique variable name in the system. Code is associated with any number of input variables (including 0) and at least 1 output variable, where each piece of such code is called a Declaration. When resolve() is called, the available input variables are given, and the desired outputs are also given. The resolve() method first checks if there is a cached execution path (called a Chain which contains Declarations), which can give the required outputs for the given inputs. If so, that Chain is used. If a Chain does not yet exist, a new one is created. The last Declaration in the Chain is found first which can give one or more desired output variables. The inputs to the last Declaration are examined to see if they are already supplied. If they are not supplied, another Declaration for the chain is found to find the step before the last Declaration. This process repeats until all Declarations are found which can give the requested results. If an execution path cannot be determined, an error is thrown. If, during execution, part of the code does not deliver the required outputs, an error is thrown.

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

Page 01 of 6

Resolver algorithm and method to keep system code flexible

Problem:

Most programming languages require developers to develop Application Programming Interfaces (APIs) that allow internal and external users to access functions. Over time, as more customers use the APIs and internal calls are made between pieces of code, the APIs become difficult or impossible to change. Any change to the API risks causing problems for users of those APIs. At the same time, business demands that software is enhanced to provide new functions or fix existing functions. This means we have 2 opposing forces working on software - keep the interface and behavior of existing functions the same (compatibility force), and enhance existing functions and add new ones (change force). The result is that after a few years, a complete rewrite may be required to allow further change, or the business may lose opportunities and eventually fail. Software rewrites are very expensive in terms of both development cost and market opportunities. A more flexible idea of API is required to reduce the impact of the compatibility force, and a more flexible way to enhance and add functions is required to reduce the impact of the change force.

Known solutions:


- Rewrite the codebase. The drawback of this approach is the risk of regression and huge expense of rewriting years of work. http://en.wikipedia.org/wiki/Rewrite_%28programming%29


- Wrap legacy code in a new interface - famous examples are in the banking industry, where most old programs were still needed, but new web interfaces were written to interact with the system. However, for many applications this is not acceptable for performance or security reasons. It also does not address the problem where enhancements to the old system are too difficult or expensive. http://en.wikipedia.org/wiki/Legacy_system


- Incremental refactoring - refactor pieces at a time to avoid the risks associated with a large rewrite. If done carefully, this is the least risky alternative. However, it takes some skill and it does not provide results quickly.


- Minimize technical debt - this is a preventative approach that works well, but depends greatly on organizational culture to be vigilant in preventing problems. http://en.wikipedia.org/wiki/Technical_debt

The core idea of the invention is to redefine an API into a more flexible concept, and an algorithm to enable dynamically finding APIs as required.

In the invention, the API is defined as input and output variables in some required state. The variables may be of arbitrary complexity. The state is indicated by a unique variable name in the system.

Code is associated with any number of input variables (including 0) and at least 1 output variable, where each piece of such code is called a Declaration.

When the user wishes to compute a result, the resolve() method in the invention is called, with any inputs available, and the names of

1


Page 02 of 6

The solution to this problem is in an algorith...