Production

Rally to Java Conversion

Sample converted Rally application

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

Rally is a fourth generation language that unites a high level scripting language with extensive database access support, screen forms and reports. For its time Rally was a powerful, elegant and flexible application development tool. It did, however, have its limitations and does not meet modern requirements. There was no GUI at all; the entire user interface was implemented with character cell terminal. Rally script is not an object-oriented language. Code reuse is very difficult. Sophisticated algorithms and database processing need to be maintained externally in other environments. Thus it does not comply with the modern requirements of rich graphical user interface, n-tier architecture, component-oriented and service-oriented design.

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 new application development. Another consideration is how toensure a rapid and smooth migration path from one infrastructure to another without disturbing critical systems. 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.

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

Conversion as a replacement methodology saves all the investments in business logic and opens the way to maintenance and further development in a new modern environment.

Rally to Java ( R2J ) is a software engine toolset and set of methodologies that take an application coded in Rally and generate Java application source 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 remaine with the current server side platform and configuration.

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. The business logic will be maintained. Changes and enhancements will be done on the new code. This will not be a face-lifting of an existing application, this will be the same complete application built on a new platform.

The Rally Converter Suite consists of three parts:

• A 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. When developed, the purpose of the framework was not to write a Rally engine using Java as a programming language, rather to build a general framework that included Rally functionality as a special case. The purpose was to give Java developers a powerful and flexible Java and XML based environment for building Data Access Layer and Presentation Layer components. The Data Access part is called the DataStore framework, and Graphical User Interface part is called the DataPanel framework. JDataPanel can be used to create new Java applications, not just to convert existing Rally applications.
• The 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 implementation process includes the following steps:

• Full Rally application report generation ( automatic ).
• Translation of the report into intermediate XML-representation ( automatic ).
• Comparison of the generated report with the Rally application to identify and fix unreported application features ( manual with automated tools ).
• Translation of the intermediate XML-representation into a set of Java and XML modules ( automatic ).
• Treatment for issues ( reported in steps 3 and 4 ) that are not automatically converted, or that may be not supported ( manual ).
• Fine tuning of the resulting GUI in line with customer standards ( manual ).
• Application restructuring according to the chosen conversion model - rich lient, thin client or intermediate model ( manual ).
• Fine tuning for effective database support ( manual ).
• Application integration ( manual ).

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

Existing external business logic links can be accessed or via a database ( Oracle Rdb, if it is chosen as a database platform for the converted application, or Oracle database etc. ), or via a VMS-specific tools ( such as WSIT ), or via an application server. When an organization moves away completely from the VMS platform, the external link applications should be also completely rewritten ( this is not a part of the Rally conversion process itself, though a very related and important part ).

The migrations target can be either a "Rich Client" - a standalone Java application, or a "Thin Client" - a pure browser solution with J2EE web and application servers on the server side.

Rich client:

Rich client is an architecture that is based on a standalone Java application:

• A Database Server at the central location.
• A Web Server at the central location. All the data access layer ( DAL ) and presentation layer ( GUI ) object definition XML files can be stored on the central Web Server ( if these objects are embedded within the application itself, there is no need for any web server ).
• The application, including all needed JDBC components, can be deployed or on end-user computers, or on a web server, or on a file server at each regional location ( if there are some ). The application ( .jar files ) are distributed to and stored on these locations.
• Front-end client workstation computers. JRE ( Java Runtime Environment ) needs to be installed. The application is launched via Java WebStart - an advanced full-featured application deployment technology, available on all Java platforms.

This architecture provides centralized application management and requires only JRE to be installed on the end-user workstations:

• Application changes, which are made to the xml definition files, stored on the web server ( database access definitions and GUI definitions ), are available immediately.
• Business logic changes only need to be deployed once to distribution locations, accessed via Java WebStart. This process can be easily automated.
• JRE upgrading can be automated as a silent batch script.
• The database is accessed from each client workstation individually.

Thin Client:

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.

• A Database Server at the central location.
• Web Server at the central location. All the data access layer ( DAL ) and presentation layer ( GUI ) object definition XML files are stored on the central Web Server.
• Application server at the central location ( this can be IBM WebSphere, BEA WebLogic, Oracle Application Server, JBoss ( free software ), Sybase EAServer etc. ).
• Front-end client workstation computers. The same browser software version have to be installed on all the client workstations. All the browser instances on the client workstations should have the same settings ( security, JavaScript etc. ).

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

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

Our Rally conversion service 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.

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

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 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. Business model can also vary - from fixed price projects to hourly based consulting. All the mixed type models are also available.

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

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. For the most cases (not so large applications) the typical price calculator can be used ( may be changed correlated to the specific application after its detailed analysis; for large applications the prices may go down significantly ), our consulting hour price is from $90 to $150 depending on the needed conversion consultant level. From our experience, additional consulting is no more than 50% of the application-dependent price.

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

Demo Applet ( or download it if your firewall does not allow applets )       Thin Client Look and Feel