Skip to main content

Request for Expression of Interest

Printer-friendly version

Computing Integrity is currently evaluating technology that can be used to transform ABL source code and is looking for companies who have legacy code needing modernization or other improvement so that we can better understand the transformation requirements they face. The transformations we are considering vary from simple operations that improve code quality to substantial transformations required in modernizing an application. While some transformations need some manual aspect, e.g., the need for human design skills, the bulk of the work will be highly automated, ensuring great speed and accuracy. It is anticipated that we will achieve as much as 5 to 1 improvements in the cost to implement any given transformation relative to current methods. Please let us know your transformation needs so that we can insure that our tools address all requirements.

The transformations we are currently evaluating are listed below.

User Interface Layer Separation and Replacement
We propose to identify user interface (UI) code, transform components with UI into separate UI and business logic (BL) components with a well-defined interface, and move the user interface code into a new separate layer consistent with OpenEdge Reference Architecture (OERA) principles. Both client-server and N-tier models are possible and the process will allow for replacing the technology in the user interface with browser clients with Ajax, .NET clients, Java clients, ABL GUI for .NET clients, and probably even ChUI clients if there is demand. It is anticipated that the new UI will fulfill the same contract as the existing UI, but is likely to require human input on the final design for optimum results.

Data Access Layer Separation
We propose to analyze the existing application to determine how and where data are used, to generate a set of data access (DA) components which implement those uses consistent with OERA principles, and then to transform existing direct references to data into references to the new DA components. This could be combined with DataServer enablement (see below).

Implementing Common Infrastructure Components
OERA design principles include the use of common infrastructure components to provide services needed by many different components. In existing applications there are typically either prototypes of such services or in-line code and the implementation is limited compared with design goals for a new application. We propose to create high quality infrastructure components and provide transforms to replace existing component references or in-line code with references to the new components. Sample Common Infrastructure Components include Authentication, Authorization, Logging, and Session Management1.

Object-Oriented Repackaging
While no simple transformation will convert a procedural ABL application into an exemplar of best object-oriented (OO) design, we propose to provide a series of incremental transformations which will move an existing procedural application in the direction of OO encapsulation by identifying behavior clusters, replacing these with classes, and then refactoring the application to change direct behavior references to references to the classes. We expect this to be an incremental process with the opportunity for human interaction, including the human creating new classes and then refactoring them into existing code.

DataServer Enablement
While DataServers allow the use of ABL code with non-Progress databases, there are some ABL features which cannot be used with a DataServer and some best practices that need to be followed to insure behavior consistent with that in Progress databases. We propose to automate the identification and modification of legacy ABL data access code to create a DataServer enabled application.

RFEoI.pdf59.71 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


Internationalization might be another use of this tool.