Many companies have millions of dollars invested in existing Oracle VMS application systems, with most of these mission critical systems that run their business. Application software and its associated databases are valuable corporate assets. Companies now want to leverage their current investment in data, products and applications with new Web-enabled applications. It is generally not practical to spend countless dollars replacing existing, functional systems with new technology or a new programming paradigm. It makes far more business sense to implement new technology (such as Oracle 10g, 11g and Java) where the impact will be the greatest (such as in the front-end of the application) and the relative cost will be the most reasonable. The goal is to leverage existing application systems and data while providing new Web based functionality.
Many organizations are contemplating utilizing the new capabilities that are being provided with Web technology. While past versions of Oracle Forms have enabled companies to access the Web, 10g and 11g are providing one of the most robust environments thus far. However, the move to the Web is not always as easy as it seems. It is important that organizations understand the business reasons to move their applications and determine if the effort and dollars spent will justify the migration costs. Understanding the risks of migration, the options available and the benefits of Java is imperative to ensure an organization is not spending precious IT dollars on an alternative that does not make business sense.
While migrating VMS Oracle applications to the Web seems challenging, the ability to maintain the years of application development with proven automated tools provides tremendous benefits to organizations. By utilizing an automated migration tool, organizations can save costs as well as time over rewriting an application.
As companies review the differences between migrating to Java and performing development in 10g and 11g there are some key components that assist in the decision for the future development environment.
Migration to Forms 10g and 11g is beneficial if:
- The organization has very few Java resources and retains a skill set in Forms and PL/SQL development
- The application doesn’t require changes to the look and feel of the application
- Skill sets in Forms and PL/SQL are readily available to the organization long-term (stability in resource retention)
- The Forms being used presently are character based versions of Forms (this is due to the learning curve involved in migrating from a client-server technology to multi-tiered Java)
- Java plug-ins (downloads) are acceptable to clients using the application
Migration to Java is beneficial if:
- Java has been chosen as the future
development environment for the organization
- Application development costs require
reduction (Java development provides much
lower development costs)
- The legacy Forms application requires
integration with other applications
developed in other environments
- Other applications within the
organization are utilizing Java technology
- The use of open source technology is
beneficial to the organization
- Provision of choices within the client’s
environment is required (such as HTML, DHTML,
use of browers, etc.)
- The use of SOA architecture is
beneficial to the organization
- The organization has determined that the
use of proprietary technology is no longer
The Benefits of Java
Java offers clients a robust, interactive environment. It is one of the most powerful Object Oriented Programming languages available and one of the most “open” technologies available. Java conforms both to its own standardized (and published) specifications as well as to other industry standards such as CORBA. JDBC (Java Database Connectivity) provides a standardized interface for relational databases that can interface, providing a greater level of database independence and portability. It also provides platform independence allowing an organization to utilize the most efficient and effective hardware available. Having choices for hardware and database software can be very liberating for an organization, deterring vendors from holding companies hostage to their proprietary environments.
Why is Java Superior?
Java is currently the only technology that provides a fully interactive GUI interface for the Web. The Java architecture was designed with security in mind and not as an afterthought. This provides a simplified and consistent means of protecting IT assets. Java also provides features that allow programming to become easier and more powerful. These include:
- Automatic “garbage collection” (for efficient use of memory)
- Standardized error trapping and detection
- Distributed processing capabilities
Java’s Capabilities for Web Development
One of the benefits of utilizing Java as a development environment is the
ability to create a user interface in several different ways:
- HTML using JSF or JSP
- Java Plug-in running in a browser
- Java plug-in running outside of a browser
When utilizing Oracle Forms, the User Interface is provided as part of Form
and is an applet running in a browser window. While this may be a good choice
for the present, in order to move forward with development technology such as
Oracle’s WebCenter, ADF, struts, spring and the Web development capabilities
Java provides many more choices and capabilities.
Java provides well-known standards that provide developers with full control of
their application environment and integration. This enables Web development of
applications to be much more flexible.
Exodus - The Steps of the Automated Conversion process
1. Oracle Forms
The Oracle Forms .fmb module, library and PL/SQL procedures are used as source files. All of this source programming is utilized by Exodus which creates a readable version of the Forms application in Java.
2. Exodus Migration
Once the key structures and functions have been organized, Exodus translates the original application's components into the corresponding Java plug-in or JSF (ADF) components as required. In doing so, the migrated application maintains the same business logic and can optionally either show the same look and feel as the original application, or convert to a specific user defined screen.
The compilation process can be performed in any IDE, such as JDeveloper, VisualAge and NetBeans to compile, maintain, and upgrade the migrated application. The Application is now 100% J2EE compliant Java code and as such can be integrated into ANY Java supporting environment or development tool.
The generated Java Code is object oriented, readable and fully maintainable, ready to be deployed on any J2EE compliant application server and environment. It can now be free of and dependency on proprietary environments and tools. The entire application can now be maintained by any Java proficient developer.
5. Maintaining the Converted Application
Exodus-VE is a visual editor that provides drag and drop capabilities to the maintenance and enhancement of the converted application. This enables clients to start maintaining and enhancing their application immediately after conversion with relative ease.
Oracle's Strategic Direction?
Oracle has been straightforward with their approach as they move towards new technology. Their goals include:
- Pooling server-side Java virtual machines to reduce the memory footprint of applications that call middle-tier Java
- Reduced application pre-starting
- Performance and scalability on the Web
- Expanding the scope and depth of the Forms management tuning and problem diagnosis facilities within Enterprise Manager
- Extensible client and middle-tier Java integration (Java Importer and Pluggable Java Component Interface)
- Development of their own Enterprise applications with technology such as ADF and JDeveloper
Oracle cites research from IDC to make the case that the enterprise market is headed in the J2EE direction:
The Options for Migration
There are several options available for migration of Oracle Forms or PL/SQL into the new Java environment. Conversions and migrations have been performed over the past 25 years as organizations move from older technology to the newest. Many lessons have been learned through these conversions. With the options available, an organization can determine the methodology that suits their requirements based on the time available before the migrated application is required to be in production. This review should include their financial restraints as well as their internal capabilities. The following outlines options for migrating the applications.
Rewrite the Application
There's a subtle reason that programmers always want to throw away code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code has problems is because of a cardinal, fundamental law of programming: “It's harder to read code than to write it”. This is why code reuse is so hard. Programmers tend to write their own function because it's easier and more fun than figuring out how the old function works.
In other words, rewriting applications from scratch is the most expensive and time-consuming option. Many organizations believe that rewriting will solve their problems. They choose to rewrite because they need additional functionality, or because they believe it will save them time and money. One of the obstacles with rewriting applications is the enormous amount of testing that has to be performed to ensure business logic is handled properly, users understand the application, and the application is applicable for the business.
This option seems to be simple. Utilize the capabilities of Forms and become Web-enabled. However, as an organization moves towards 10g, this option becomes less feasible. Some sort of migration effort is required to fully take advantage of the capabilities of 10g. There are companies who are just not ready to migrate their development to Java. This may be due to resource restraints or knowledge level, or simply because they prefer to continue to develop their applications in Oracle Forms. In this case, utilizing migration services or tools to migrate to 10g makes sense. This will provide an organization the benefits of the 10g technology as well as prepare them for a future move to Java.
This alternative is by far one of the highest risks. It is not only time consuming, but also shares the negatives that rewriting the application presents. This includes human error issues, lack of resources or skill set and disruptions to the business operations. In addition, escalating costs usually coincide with manual conversions. Many organizations have started their Forms to Java conversions manually only to determine that the time difference between manual and automatic is significant.
Automatic conversion is one of the best alternatives to migrating applications. With an effective migration tool, the conversion can be performed quickly and effectively with tremendous cost savings. Some conversion tools have benchmarked to be 90% faster than manual migration and 80% less expensive. In addition, automatic conversion reduces the risks for the organization. Functionality is maintained and users do not require retraining. There are several options for automatic conversion that enable an organization to move quickly into the new environment. It is important to note, however, that all automatic conversion alternatives are not the same.
There are presently very few tools available in the market with some venders offering a service to perform a Forms to Java conversion. In some cases, these vendors require that the client send their code “offshore” to have the conversion performed. In addition, there are questions that should be asked of the vendor to ensure that the migration is being converted to a true Java or J2EE environment. These include:
- Is my application being converted to truly compliant J2EE code?
- Are we able to purchase the tools, or is this a service offering only?
- Where is my conversion to be performed (on-site or at the client's site)?
- Are we able to discontinue licensing of Oracle Forms and PL/SQL or do I still have to license these products?
- Is the vendor available to assist with any issues and training once we migrate to Java?
- What percentage of conversion is automatic or how much manual work is involved once it is converted?
- Is the J2EE code “clean”, i.e., is it easily maintainable once I get into the Java environment?
- Does the converted code integrate with JDeveloper and utilize the ADF and BC4J environment from Oracle?
It is important that as a company asks these questions, they actually work with the vendor to provide a “sample” of the converted Java code. An organization should have the option to send in a small sample of an application to see the resulting converted code. This will ensure that the code is easily maintainable and functional as soon as it is migrated. Functionality can be added or changed during an automatic migration, as it can be more closely controlled than with other migration alternatives.
It is sometimes difficult to determine the best solution for migrating applications to new technology. The conversion of applications should not be a painful exercise, but one that provides efficient alternatives to the organization enabling the most cost efficient option.
Making the business decision to determine how to move into new environments is not always easy. Weighing the benefits to the business of becoming Web-enabled against the time and effort required for a migration process is an important part of this decision. Keeping costs and risks to a minimum, as well as causing little business interruption will ensure that the organization continues to benefit from the project.
For more information
Vice President, Oracle Practice
CipherSoft (A wholly owned subsidiary of Unify Corporation)