Issues & challenges facing Oracle® Forms to J2EETM evolution
Learn what you need to know to perform a successful (and cost-effective) Oracle Forms to J2EE migration. by Federico...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Zoufaly & Paul Dermody
|Toolbox: Oracle Forms, Oracle 9i AS, Oracle 9i JDeveloper, Business Components for Java (BC4J), SQLJ
Knowledge of Oracle Forms and J2EE; knowledge of programming languages in general
Moving away from a familiar environment to another, though a more promising one, tends to cause a lot of uncertainties. This seems to be a common dilemma faced by lots of organizations that have developed their applications in Oracle Forms, as there is a growing trend toward moving them onto the Java 2 Enterprise Edition (J2EE) platform for reasons of standards, scalability, flexibility and global reach. However, organizations must carefully analyze the business and technical reasons and implications of such an undertaking. Equally important is a thorough understanding of the variety of evolution approaches available in order to be able to weigh their pros and cons objectively.
This article starts with a brief analysis of Oracle Forms and J2EE, as well as some of their most significant capabilities. It will then discuss why even successfully built Forms applications should benefit from a move to J2EE. Finally, it will examine the main Oracle Forms to J2EE evolution options – from quick fixes to more long-term solutions – in order to help the reader decide which tool and development style can best adapt to their specific business needs.
What is Forms?
Oracle Forms is a 4GL rapid database application development environment plus a runtime environment where these database applications run. The development environment provides numerous wizards, sophisticated graphical components with easy database binding, drag and drop, and WYSIWYG editing. The runtime provides transaction control, record locking, validation, query by example, master-detail coordination, etc.
Forms is proprietary and is accompanied by an interpreted procedural language called PL/SQL. This is a high level language designed primarily for database access, which also contains features for working with the graphical side of Forms applications. Oracle has also added a new feature called Forms Services, providing a mechanism for publishing Forms applications on the Internet.
What is J2EE?
J2EE can be thought of as a runtime environment, conceptually similar to the Forms runtime, though much broader in scope and, of course, substantially more open. J2EE defines a set of Java Application Programming Interfaces (APIs), which provides applications with common services required for scalable, secure, distributed, transaction-oriented, Internet applications.
The J2EE runtime environment is called an application server. One of the most attractive features of J2EE applications is that they can usually be deployed in any of the numerous application servers available. The most popular are IBM WebSphere, BEA WebLogic, and Oracle 9iAS. There are even some good free application servers available like JBoss, and Enhydra. In addition, Sun recently started distributing its Sun One Application Server free of charge.
Differences in architecture
The most significant difference between a Forms and J2EE application platform is probably in architecture, i.e. the physical elements of each platform and how the logical components of the applications are distributed on those elements.
Oracle Forms has a two-tier (or client/server) architecture: the GUI and the application logic are stored on the user-machine, and the database is usually stored on a second, centrally located machine. The components of the application located on the user-machine in this architecture make up what is known as the client-tier. The database used by the application is usually referred to as the database-tier or server-tier.
J2EE, on the other hand, has a 3-tier architecture: the GUI is stored on the user-machine, whereas the majority of the application logic is stored on a second, centrally located machine. The database may be stored on the same machine as the application logic, though it is normally found on a third machine close to the application logic. This architecture is often referred to more generically as an n-tier architecture because the second (or middle) tier tends to be further divided into other logical and physical tiers.
An important advantage of the 3-tier approach is the possibility to share the logic stored on the middle-tier between different types of client. For example, Java and HTML clients could both use the same application logic. True migration to a 3-tier architecture means somehow identifying the application logic in the Forms application, separating it out from the client-tier and moving it into the middle-tier. Any migration must include close attention to this separation if the new application hopes to take advantage of the reusability benefits normally associated with this architecture.
Differences in platform
Part of what makes programming in Forms relatively easy is that some things are done for you behind the scenes. Certain services are implicit in the Forms programming environment, and much of the Forms code assumes that these services exist. For example, Forms defines triggers associated with datablocks that are executed when certain events occur. The logic in Forms applications often depends on those triggers being executed at the right time. Often these triggers are attached to events that are not part of the normal Java event-handling mechanism. For example, the POST-INSERT trigger is executed just after a new row is inserted in the database.
Another example is the fact that Forms will lock the appropriate record in the database as soon as you type anything into a field even though you have not performed any commit yet. Of course you have caching and other optimizations that are handled by the record manager in Forms.
Master-detail relationships are handled mostly transparently. Special wizards exist for this and most other common activities when building a database application.
All this means that you will have to either redesign your application in Java or use some kind of framework that already provides a lot of the same functionality. Oracle's Business Components for Java (BC4J) is one such framework. BC4J comes with many features that Forms developers will be familiar with (at least conceptually). It also provides many optimizations to enhance the performance of Internet-based applications. The best part of this framework is that it's free.
BC4J has its drawbacks. It depends greatly on XML for its configuration information and metadata. Editing these XML files by hand and keeping them synchronized with their associated Java files is not for the faint-hearted. Luckily, Oracle's JDeveloper comes with a wide selection of wizards to help you maintain these files quite easily. Unfortunately, JDeveloper is the only tool around right now that has such a capability. This means you are effectively tied to a single IDE if you develop your application using BC4J.
There are many other such frameworks available that you can look into, for example, Wakesoft and RealMethods. (See footnotes)
When migration makes sense
Change for the sake of changing can be quite risky. Remember New Coke? Pepsi Co. was so "impressed" that it gave its employees a day off to celebrate the event! There are, naturally, enterprises that are satisfied with their Forms performance, as they can find no current compelling reason to move and see no future bottlenecks since Oracle seems to be committed to the further development of the product.
For example, if your only reason for considering migration is getting your applications on the Web, then you might want to consider Forms Services. This framework from Oracle allows you to publish your Forms applications on the Web without making any modifications at all to your original applications. It works by running your Forms application on the Web server and emulating the graphical user interface in a generic applet in the client. This type of solution is sometimes referred to as a "screen-scraper". Your application remains an Oracle Forms application, though.
However, not recognizing or acting upon market trends can be equally damaging to your future business success, which is why a careful examination of the current drive for moving our Oracle Forms applications onto J2EE should prove extremely productive.
First of all, it may be the case that your end-users no longer require a heavy data entry application due to the fact that your business is moving towards a self-service model - where your partners or clients are using your applications directly. In this case, it would make better sense to move them from a Forms or Java user interface to an HTML front end. Another important factor can be your IT department's preference to develop in Java rather than PL/SQ, using J2EE standards. They simply feel more comfortable and are capable of developing in one of the most advanced development environments.
Furthermore, your strategic business needs may drive you to Java because of its intrinsic benefits such as portability, flexibility and standards compliance. Many companies are building specialized and heterogeneous internal infrastructures consisting of a variety of platforms: Windows, Macintosh, Unix, etc. They want their systems to run and be accessible by all these platforms.
However, before you pass the verdict on moving your Forms applications to J2EE technology, it is important to be aware of the costs involved in such a migration. These obviously include the cost of migrating the business logic and the more expensive user-interface. In addition, you should be aware of some of the hidden costs that also need to be considered, i.e. integration costs.
How to move Oracle Forms to J2EE
There are a variety of options available for wholly or partially moving your Oracle Forms to the J2EE platform. Techniques range from quick fixes such as screen scraping and wrapping to permanent, though more complex, solutions such as automatic migration or replacing the whole system.
This is the option when the intent is basically to deliver Web access on the current Forms platform. Because it is non-intrusive, it can be deployed in days and sometimes hours, and it is extremely cheap. The main obstacle here seems to have been scalability, though Oracle appears to have made certain headways in this area with their Forms Services product. The two most common Frontware categories are described below:
- Screen Scrapers As mentioned earlier, this is the type of solution provided by Oracle's Forms Services. The client sees an application that looks like their original application, but it is in fact emulating it in Java. This technique provides Internet access to your Forms applications without making any changes to the underlying platform. Oracle has put a lot of work into this solution and many companies have claimed great success in implementing it.
However, it should be mentioned that your application continues to be a Forms application. Although there are mechanisms for accessing Java and other languages from PL/SQL, many people want to avoid the added complexity of having different components of their applications developed in different languages.
Wrapping usually involves integrating your new Java applications with your older applications by building Java APIs that can access the business logic or other important elements of your older system. This does not make as much sense in the case of Oracle Forms, which is primarily a graphical application. It could be argued that this might be a way to get at business logic in PL/SQL libraries; however, to the authors' knowledge no tool currently provides such a possibility.
The German company, InformatikAtelier, has a novel approach that is a form of wrapping. They have a tool that automatically embeds the PL/SQL code directly into the Java using a technology from Oracle called SQLJ. The advantages here are that your Forms programmers will recognize much of the code in the migrated application and will have little difficulty maintaining it since it is still very similar to the original PL/SQL.
Again, this might not be an ideal solution if what you want is to move to a pure Java solution. Also, your programmers will need to be comfortable with both Java and PL/SQL.
Rip & replace
In some cases it is possible to update your systems by simply buying third-party software to replace it. This approach is especially worth looking into when the original application has outgrown its usefulness, it has become outdated, and it supports processes that are no longer of use in your business.
However, despite continuous development efforts by ERP firms to add new tools to help their applications adapt to their customers' specific needs, one should note that the software usually has to be customized in order for the company to continue taking advantage of its unique business processes.
Whilst the "rip and replace" approach to integration has many drawbacks including cost, risk, timeliness, service disruptions and acceptance amongst others, the other much touted approach "adapt and embrace" (keep adjusting to support the new business model and accept all the consequences) also has drawbacks, like middleware complexity and maintainability of supporting both new and old technologies. This last integration approach can be easily implemented using wrappers. Even though it produces quick results, it arms the maintainability time bomb for the future. Some vendors are only too happy to propose approaches that arm a time bomb for the future as they hope to be able to provide the disarming mechanism later on. In many cases this mechanism will be rip and replace, only later, much more expensive, and far more painful.
A more viable solution lately has been automatic migration. This involves the use of specialized software to accelerate the rebuilding of an application in a new language. These tools effectively rescue and convert the important elements of your old application and generate code that does the same thing in the target language.
Migrating to a 3-tier architecture involves identifying the application or business logic in the Forms application, separating it from the client-tier and finally moving it into the middle-tier. This separation is of vital importance if the new application hopes to take advantage of the reusability benefits normally associated with this architecture.
ArtinSoft, for example, has developed a two-step approach to handle the separation and movement tasks. First, using automatic migration tools, those elements of the Forms application that are good candidates for the middle-tier are identified. This identification is based on certain criteria that can be created by the customer or can be chosen from pre-built sets of criteria. The criteria are based simply on the type of work being done by the code. As an example, code that is changing the color of text in the display would belong on the client-tier, while code that alters a table in the database probably belongs on the middle-tier. Once each element of the application has been categorized in this way, you can override any of the decisions based on your own knowledge of the workings of the application. Then the tool will automatically move the code to the correct tier while it converts it into Java.
There are many migration tools available now, and all seem to take different approaches to the migration of the other important element of your Forms applications: the user interface. Churchill Software, for example, has a framework that includes a technology called NativeForms, which they say provides an identical Oracle Forms look-and-feel "at HTML speeda". Ciphersoft takes a different, and quite interesting approach. They generate XML files which can then be interpreted by a Java client or a Web client – depending on how you deploy your new application. In the case of the Java client, you see a regular Java GUI, whereas in the case of the web client you see a lightweight HTML GUI.
Rebuilding your application, even with automatic migration tools, can be a complex undertaking, second only to rewriting your application from scratch. However, it makes a lot of sense if your old application is still very stable and accurately implements critical business processes.
Automatic migration, as opposed to rewriting, reduces development time because it involves moving to a new system based on business logic, requirements, and functionality that is already well defined.
Testing should also see impressive reductions in required effort if the code is generated automatically–based on the original source code–since the inclusion of new bugs will be very low. Of course, existing bugs may well be migrated to the new system, too.
Automatic migration makes for a relatively low risk development project because of the reduction in time and the usually well-defined results that these migration tools produce. Migrations offered as services can reduce risk still further by guaranteeing results but at the same time involving the client in all aspects of the project.
It should be understood, however, that these tools accelerate only the production of code. Otherwise, the migration project is just like a normal development project implying that the other phases will be performed as with any development project. For example, after the application has been rebuilt in Java, acceptance testing, integration, and usually customization must be performed.
The common reaction to rewriting code does not tend to be very positive, though it might be worth looking into depending on the application's size and type. This is usually a possible choice if your current system is too unstable or too outdated to be of use anymore and there are simply no third-party packages around that are specialized enough to fulfill your needs.
Building a new system from scratch (design, develop, test and integrate) can lead to a unique and even ideal solution. However, the high risk of failure associated with any large software project, as well as budget and schedule overruns, lessens the chances of success. In addition, the need for the source and target systems to inter-operate via data gateways during the migration process adds complexity to an already complex development process.
Nevertheless, small-scale projects may be better candidates for such an approach and are definitely easier to handle. For example, if it is determined that there is a section of the code whose functionality or behavior is poor, the opportunity to rewrite that specific, manageable section can save the organization a lot of future headaches.
Despite Oracle Forms certain business and technological strengths, there is definitely a growing business trend and/or need to move to open, scalable and Internet-based platforms such as J2EE. This article has dealt with some of the more significant reasons why such a move by enterprises in search of a more competitive edge in a changing world can and should be firmly justified.
Equally important is the article's detailed analysis of the wide variety of viable approaches to moving Oracle Forms applications to J2EE. This includes wrapping, rewriting, replacement and automatic migration, all of which are capable of adapting to specific needs and making perfect business sense under certain circumstances. The availability of such a wide range of approaches and tools should additionally minimize the systematic risks involved in successfully moving applications to J2EE.
In summary, it is hoped that after going through this paper, the reader should have a better understanding of the advantages of such a move and be in a position to further investigate the pros and cons of each of the development tools and evolution approaches discussed here in order to arrive at the most feasible solution that best meets their requirements.
Migrating Forms Applications to J2EE at Oracle
Issues & Challenges Facing Legacy Migration
About the authors:
Federico Zoufaly is a PhD candidate in Computer Sciences, University of Florida, and is currently an executive vice president in charge of operations at ArtinSoft. He has researched extensively into alternative ways of migrating and upgrading applications to modern platforms and is a regular presenter on the subject at important technological events in North America and Europe.
Paul Dermody holds a degree in Mathematical Sciences from the Trinity College, Ireland, and has been working professionally in the software industry for 12 years. Paul is currently a product manager at ArtinSoft.
Dig Deeper on Microservices and DevOps