Skip to content

Oracle Rally to Java Migration


 Sample converted Rally application

 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) 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.

To be more precise in our estimations we need your answers to the following questions:

1. What is the total size of your Rally applications ( in VMS blocks )?
2. Statistics for your Rally applications
3. Is your business logic mostly incorporated within Rally, or located externally (for example, in Cobol, C programmes or DCLs)? What are your plans for the converting of the external business logic routines?
4. What will be your end-user environment ( e.g. MS Windows, X-Windows etc. )?
5. What will be your server-side environment ( operation system, database, application server etc. )?
6. What will be your network topology (for example, central office with a 100Mb network and 100 local offices, connected to the central office by T1, etc.)?
7. What is your estimation for the overall quantity of end-users?
8. Are your personnel familiar with Java environment and, if so, on what level?
9. What is your schedule for the project?
10. Additional notes
Your contact information:
Email
First Name
Last Name
Skype
Phone
Title
Organization
Country

     

Based on this information we can make ( though very preliminary ) estimation of the needed efforts and time schedule, and build right price model. More accurate estimation requires Rally applications and database structure to be analyzed.

In general for the pricing model we can suggest “mixed” model, that is fixed price based on a Rally application characteristics ( number of VMS blocks, forms, fields, DSD’s, external links, tasks etc. ) plus consulting hours pool.

Thank you for your interest in our services. We will be glad to assist you in maintaining the future of your Rally applications.