Oracle Rally to Java 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:
The conversion itself is covered by steps 3 through 6 and uses Rally Conversion Suite.
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:
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: 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. |
