Revolutive IT™
Alternative solutions for application transformation

U ntil now, there are alternative solutions that are proposed to the clients. Among these solutions, we find following. We will discuss the advantages and disadvantages of these solutions.
Whether there is an alternative to source code transformation depends upon the business objectives. Where the primary objective in converting legacy code is risk reduction, maintenance costs, downsizing etc., then transformation is the only option. However, where the motivation is enabling existing back-end systems to work with new web applications, there may be viable alternatives to transformation. This section assumes that web access to legacy systems is the goal, and discusses the alternative approaches.
Methods for integrating existing systems into web applications are categorized as invasive or non-invasive, depending upon whether the source code of the original application requires modification. Transformation is an invasive technique, since the whole objective of the method is a restructuring of the source code and probably its conversion into a new, more modern development language.

Invasive Techniques

Invasive approaches, where the legacy application code is modified, are inherently much more powerful and flexible. Business functions can be separated from workflow and implemented as components that expose specific business services. However, modifying legacy applications by hand runs the risk of introducing errors into production systems, since it is extremely difficult to analyze existing code and extract all the business rules. A new class of powerful transformation tools for automated object-based transformation makes invasive techniques much more reliable, cost effective and attractive.

Non-invasive Techniques

Non-invasive techniques enable business functions embedded in existing code to be accessed through new interfaces, and are promoted by their vendors as being low risk and economic solutions. However, the front-ends required to handle the mapping of client requests to legacy functions are generally complex and fragile. Non-invasive methods offer only short term solutions to the problem of integration with new technologies, since they do nothing whatsoever modernize the structure of the underlying applications and access methods. They simply postpone the day when these fundamental changes must be made, and the investment in the front-end mapping discarded. Furthermore non-invasive solutions do not scale well, and cause major maintenance problems in the front-end mapping if revisions are made in the legacy code.
Non-invasive techniques are appropriate, however, when applied to object code acquired as a "packaged" solution, or where the source code has been lost.
Non-invasive techniques include:

 Screen scraping
 Packaged applications

Read the comparison of the legacy transformation options: Advantages and Disadvantages


Wrappering allows existing mainframe and UNIX applications to be made available to the network as components. By "wrapping" code round application subprograms they expose themselves, and behave like, Java or DCOM components. This technique enables the construction of new, component based applications without rewriting or changing existing code, making legacy applications accessible on the Web.
A wrapper can be resident on the host from where it is served as a Java Bean or accessed via DCOM from a client. This is called server-side wrapping and prerequisites a suitable environment on the host to support the wrapper (e.g. JVM, OS/390 Open Edition). Alternatively the wrapper can reside on an appropriate client platform (client-side wrapping), whereby subprograms on the server are accessed by Remote Procedure Calls (RPC).
Wrappers are generally delivered as features of a middleware product that also handles the network communication, message queuing, security, integrity etc. This requires additional, complex product knowledge, programming resources and on-going maintenance effort and costs at the host site. Further disadvantages are that changes to the source application require wrapper regeneration, leading to versioning problems and that the middleware introduces protocol conversions during message transfer, compromising the robustness of the solution.

Back to the list


Middleware is a term used to describe messaging and transaction processing monitors that connect web and e-Business application servers with legacy systems at a low level using system-to-system mappings.
Most middleware products also include connectors to common application interfaces and database access methods. They can provide Enterprise Application Integration (EAI) - that is: system-to-system integration between legacy systems and web and e-Business applications based upon the underlying middleware.
This assumes that the legacy systems already provide suitable application programming interfaces (APIs). Some disadvantages of middleware solutions have been briefly described above.
There are many examples of middleware offerings, including:
ActiveWorks, Cross Worlds, MQSeries from IBM, AQ from Oracle, EntireX from Software AG, TIB/ActiveEnterprise from Tibco and Vitria’s Businessware.

Back to the list

Screen scraping

Screen scraping software allows a PC to intercept character-based data from a mainframe and present it, field for field, as an easier to understand graphical user interface
Screen scraping in its simplest form consists of a terminal emulator installed on a PC, together with presentation software. The PC communicates directly with a legacy application via the terminal emulator, which causes it to appear to the host application as a "green screen" device. The screen-scraping software then converts the block-mode communication into a GUI representation on the PC. Newer screen scrapers present the information in HTML, so that it can be accessed via a web-browser. This simply provides the host application with a colorful, graphical user interface (putting lipstick on a pig!). Such screen scrapers are quick to implement, but extremely fragile, since any unexpected message from the host can confuse the presentation software.
Examples of screen scrapers are Rumba from NetManage, Flashpoint, Mozart and Intelligent Environments.
More advanced screen scraping techniques are more robust, converting communications with the host into events that can be handled on the PC by VisualBasic or PowerBuilder applications. These provide sophisticated error-handling, but require much more effort to implement. Screen scrapers in this category include Mitem View.
All screen scrapers suffer from the disadvantage that they do nothing to improve the structure of the host application and generally degrade its performance. Any modification whatsoever to a host screen image requires modification to the screen image on all the PCs where it is resident. Screen scraping must be regarded as a short-term visual improvement to an application, with expensive maintenance implications.

Back to the list

Packaged applications

If the costs or risks associated with retaining and maintaining a legacy application are perceived as too high, then a corporation may decide against any of the above methods. An alternative to redevelopment of the application can be the replacement of the legacy system with an Enterprise Resource Package (ERP application), purchased from a vendor such as SAP, Baan or PeopleSoft. Such packages provide access to their features via APIs, and increasingly expose their features as components. This makes a hybrid transformation/ERP-acquisition project possible.

Back to the list



Legacy Transformation Options: Advantages and Disadvantages




object-based transformation

  • Effectively captures business process knowledge
  • Effective legacy code analysis and
        data modeling
  • Flexible, open solution
  • Complete transformation of UI,
         business process, and data
  • Enables a distributed architecture
  • Separates process from workflow

  • Still requires highly skilled developers
  • Auto-generated code may not deliver top performance
  • Does not support all legacy environments
  • Wrappering

  • Creates open components from
         legacy code
  • Enables distributed architecture
  • Requires advanced OOP skills
  • Highly labor intensive
  • Does not address architecture and deployment issues
  • Provides limited flexibility
  • Does not analyze code and data structures
  • Can create maintenance coordination issues
  • Middleware

  • Transaction-level integration
  • Numerous vendor/product options
  • Supports workflow
  • Must be used in conjunction with other code
  • Does not capture business process knowledge
  • Can create performance bottlenecks
  • May not scale
  • EAI

  • High-level solution
  • Easy to use
  • Vendor is responsible for integration
  • Support business process knowledge and workflow
  • Costly
  • Dependent on vendor for upgrades and changes to connectors
  • Connectors limited to existing legacy application interfaces
  • Can create performance bottlenecks
  • May not scale
  • Screen scraping

  • Fastest, simplest way to enable legacy applications for the Web at the user interface level
  • No transformation of legacy applications for Web
  • Does not address business process or data transformation
  • No distributed architecture
  • Limited functionality
  • Limited flexibility
  • Can create maintenance coordination issues
  • Packaged applications

  • Access to new, advanced functionality
  • Integrated functionality
  • Support for distributed architecture
  • Numerous vendor/product options
  • Requires abandoning investment/value in existing systems
  • Very expensive
  • Very disruptive
  • Web, e-Commerce support still evolving
  • Back to the list

    Our solutions are the most efficient, flexible, quality-based and cheaper of the market, due to our fully innovative and customer-driven approach. Discover them and compare them to the solutions provided you by our competitors.

    Copyright © 2002 Atlantis Technologies. All rights reserved.