Oracle Rally to Java (EE) Migration

Sample converted Rally application
Download Rally Application Statistics Calculator   ( Java 1.5 or higher environment should have been installed )
Rally Form to JDataPanel Conversion Demo       Thin Client Look and Feel

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) based operating systems, Internet, Mobile computing, e-commerce and other forces require businesses to move forward. Maintenance of old architectures is expensive and suppliers are discontinuing services and maintenance contracts. Professional personnel are hard to find to support old technologies. Users are demanding seamless integration of legacy systems with new technologies.

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

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

Automated conversion as a migration methodology saves all the investments in business logic and 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 be implemented with the old technology. The main goal is not only to migrate into a new environment, but to have an opportunity to implement new technologies. The right migration strategy also means changing the software ideology to meet new requirements. Therefore, just emulating 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 application coded in Rally and generate Java / Xml application code with minimal need for a programmer intervention. Java as a target environment allows maximum platform flexibility and at the same time allows, if needed, to remain with the current server-side platform. Java has proven itself to be a superior technology as a modern business application tool. Moving to Java is a strategic decision for an enterprise, a decision to make another step into the future. An enterprise that decides to migrate to this modern development environment will use Rally to Java (R2J) as its conversion 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 ProcessGenerally 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 fields’ 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
• “facade” – 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

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.

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
  ]
]

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.