Oracle Rally to Java (EE) Migration

Introduction

Rally 4GL for rapid application development was adopted by many enterprises for their vertical application development in the late 1980’s and early 1990’s. In the context for which it was created, Rally was a formidable tool that allowed development of applications in the Open VMS environment for text-based systems. Many enterprises and organizations built their mission critical systems with Rally. Many man-years were invested in Rally code, in the application user interface and business logic. But now Rally applications have become legacy ones.

Currently enterprises are moving over to new technologies. Graphical User Interface (GUI) basedoperating systems, Internet, Mobile computing, e-commerce and other forces require businessesto move forward. Maintenance of old architectures is expensive and suppliers are discontinuingservices and maintenance contracts. Professional personnel are hard to find to support oldtechnologies. Users are demanding seamless integration of legacy systems with newtechnologies.

Moving to another platform requires a number of factors to be considered. One majorconsideration is the enterprise’s investment in its legacy applications and significant cost of thenew application development. Another consideration is how to ensure a rapid and smoothmigration path from one infrastructure to another without disturbing critical systems. The morevaluable the encapsulating an organization’s business logic software is, the more complex is theprocess of its evolution. Maintaining legacy software business logic is the important part of anorganization’s knowledge storage. Smooth and reliable transformation requires preserving all ofthe needed business logic.

Rewriting Rally applications from the scratch is a very costly, time consuming process and maylead to the loss of business logic and user interface investments. The significant point is thatlegacy applications are not always well documented. Even when an organization has the originalsystem analysis document, not all the maintenance changes may have been documented, so therisk of business logic loss is very high.

Automated conversion as a migration methodology saves all the investments in business logicand opens the way to maintenance and further development in a new modern environment.The time to start migration is determined by the moment the new requirements can not beimplemented with the old technology. The main goal is not only to migrate into a newenvironment, but to have an opportunity to implement new technologies. The right migrationstrategy also means changing the software ideology to meet new requirements. Therefore, justemulating the old legacy environment with the new one is a wrong decision.

Rally to Java (R2J) is a software engine toolset and set of methodologies that take an applicationcoded in Rally and generate Java / Xml application code with minimal need for a programmerintervention. Java as a target environment allows maximum platform flexibility and at the sametime allows, if needed, to remain with the current server-side platform. Java has proven itself tobe a superior technology as a modern business application tool. Moving to Java is a strategicdecision for an enterprise, a decision to make another step into the future. An enterprise thatdecides to migrate to this modern development environment will use Rally to Java (R2J) as itsconversion tool.

Target Environment

The target environment is a full thin client solution based on the modern J2EE and AJAX methodologies.Thin Client architecture is a pure browser solution with a web server and a J2EE application server on the server side; the application packed as a J2EE servlet running within a J2EE container; database access and some business logic provided via J2EE application server components.

The new architecture is a pure thin client (“browser”) solution with a J2EE container and web server on the server side; the application is packed as a J2EE servlet running within a J2EE container; database access and some business logic are provided via J2EE components. All the data access layer (DAL) and presentation layer (GUI) object definition XML files are also stored on the central web server.

The server side can be any J2EE container / Java Application Server, running on any Java supporting operating system (IBM WebSphere, BEA WebLogic, Oracle Application Server, Tomcat, JBoss, Sybase EAServer, etc.).

The resulting application requires no client installation, except of a browser, with no operating system limitations. Currently supported browsers are Internet Explorer 6.0 and higher, and Firefox 3.0 and higher. The same browser software version has to be installed on all the client workstations. All the browser instances on the client workstations should have the same settings (security, JavaScript etc.).

Application changes, which are made to the XML definition files (database access definitions and GUI definitions), are available immediately. Business logic changes, encapsulated within application server components, are available immediately after installation. Business logic and GUI framework changes, encapsulated within the J2EE Servlet, are available immediately after the Servlet container restart. The database is accessed from the application server components.

This architecture provides centralized application management and does not require any additional software to be installed on the end-user workstations.

Migration Process

Generally the migration process has the following steps:

Detailed analysis, choosing of the target platform
Verification and fixing of the source application
Rally application report generation
Reverse engineering of the source application (based on the application report) and the database metadata
Manual completion of the unreported parts (aggregate field’s information, menu texts etc.)
Code generation
Preparing test environment
Database migration (if a new database platform is chosen)
Unit testing, including required database connection for the data access layer objects
External links migration
Code integration and thin platform adaptation. Application restructuring according to the thin client conversion model.
Database integration and required changes according to the chosen database platform
General graphical design, fine tuning of the resulting GUI in line with customer standards
Application integration testing and required fixing
User acceptance
Building the production environment and putting the new application to production
Training for the customer’s developers

The conversion itself is covered by steps 3 through 6 and uses Rally Conversion Suite.
Rally Conversion Suite consists of these parts:

Java-based JDataPanel framework that allows future flexible and reliable development in the new Java-based environment, and which also includes an independent product for rich Form/Report design – MainTrend’s JDataPanel Designer. The framework supplies all the needed functionality that the Rally application has, including database access, forms and reports. JDataPanel can be used to create new Java applications, not just to convert existing Rally applications.
Rally Converter itself, which translates each Rally application into a set of Java and XML modules.
Conversion and development methodologies, including best practices for the most effective manual completion and enhancement of the resulting applications.

The automated conversion process converts more than 80% of a Rally application to Java/XML automatically. That means that at least 80% of the total conversion work is performed automatically.

We use Rally application report as a source for our conversion process, and there is some information (such as types of aggregate fields, menu choice texts etc.) that is not included into the Rally report. This information can be easily added manually with our editing tool. Also there are some objects (external links, for example), which should be treated manually. For such objects we build wrapper classes, so the manual intrusion is encapsulated within those classes. Also manual part includes GUI tuning according to the customer’s requirements and database access tuning. The database access is very significant, because Rally itself uses “connected” database access model and is tightly coupled with Rdb, and this approach is not always good for modern applications, and always not good for n-tier applications. From our experience, manual part can vary from 5% to 20%, depending on the application.

The generated objects are grouped into the following packages:

“dal” – XML-definitions of the data access layer objects (DSDs)
“external” – all the Java classes for external links
“façade” – all the Java classes for Menus, Tasks and the application manager
“logic” – all the Java classes for ADLs and Action Lists
“presentation” – all the Java classes for Forms, Form Packets and all the XML-definitions for the GUI objects

The presentation layer object definitions and data access layer object definitions ( XML files ) can be stored with the resulting Java application, or can be deployed on a web server

The generated application is deployed with the “thin” framework as follows:

[webapps]
  [... the application's directory 
    [css]
    [html]
    [images]
    [js]
    [jsp]
    [META-INF
      MANIFEST.MF
    ]
    [WEB-INF
      [classes
        [The application's Java classes structured by package name:
          [dal]
          [external]
          [facade]
          [logic]
          [presentation]
        ]
        [net]
          [maintrend - MainTrend's engine Java classes]
        ]
      [lib
        [all the needed libraries, including required JDBC drivers]
      ]
      web.xml
    ]
    index.jsp
    login.jsp
    Configuration.xml
  ]
]

Conversion service

We offer an automated conversion service that can lift Rally applications to the Java/XML technologies while preserving business logic base and user interface investments. Take into account that we don’t sell the tool itself, we offer a service based on our tool. Most of the work can be done remotely, and manual part can performed by MainTrend’s team or can be divided between MainTrend and a customer or a third party conversion partner, to be as much as possible convenient to all the parties.

There can be different models of the conversion projects – from full conversion to different “reverse engineering” stages; automatically generated script can be used by customer’s developers as a tool for business logic capturing, etc.

MainTrend is today the sole provider of such a comprehensive solution for Oracle Rally applications.

As a first step we can define a pilot for the conversion project. The pilot will give enough information to prove that the conversion suits the application; and the pilot results can be used then as a part of the whole conversion.