Abandon all hope, Oracle Forms developer shops
Apps built in Oracle Forms should be rewritten in company's new Application Development Framework
- By Joab Jackson
- May 13, 2009
Organizations now running applications built in Oracle Forms should start thinking about rewriting them in Oracle's new Application Development Framework (ADF), advised Vgo software chief technology officer Robert Nocera. The transition does not have to happen immediately — and shouldn't be done on a whim — but information technology managers and architects should keep the potential switchover in mind as they embark on modernization plans.
"Overall, switching from Forms to ADF is a good idea, though it will take some doing. It is not a one-to-one crossover," said Nocera, speaking at the Independent Oracle Users Group annual meeting, Collaborate 09, held last week in Orlando, Fla. "You should be jump [between platforms] for the right reasons."
Oracle has offered Oracle Forms since the mid-1980s. The client-server technology has long allowed developers to easily create enterprise applications that can read and write into Oracle databases.
Although Oracle has not announced that it will be discontinuing Oracle Forms — extended support will be offered at least until 2013, Nocera said — it is clearly a legacy technology for the company. Nocera added the IT research firm Gartner has advised its customers to move from Forms.
Oracle is shifting its own software stack to its Fusion middleware, a standards-based service oriented architecture of reusable components, such as Java Enterprise Edition-based application servers and the Business Process Execution Language (BPEL). Oracle itself is in the processing of rewriting its enterprise applications in Fusion and is recommending their customers, in order to maximize interoperability with the Oracle apps, build Fusion applications as well by using the ADF framework.
Nocera pointed to a number of reasons for jumping from Forms to ADF. Chiefly, it will be increasingly difficult to find qualified developers, as those entering the IT workforce will probably not study the legacy technology. Also, as new platforms emerge, Oracle will probably not adopt Forms to these new environments.
In another conference session, Oracle Principal Product Manager Dana Singleterry explained that Oracle is encouraging customers to use its free JDeveloper to build applications. An upcoming version of that integrated developer environment will contain the tools to link front-end user interfaces with businesses services and databases. ADF apps can be built as thick clients, Web clients or to be run on other platforms, such as mobile phones. The business services, or the logic that processes the data, sits in between the user interface and the database. Web services can be used to connect with other applications, such as PeopleSoft. The stack includes BPEL to handle workflow duties.
While Nocera urged Forms users to consider switching to ADF, he also said that the switch should not happen until there is a compelling reason to do so, because the transition will not be a straightforward or an inexpensive one.
Such a compelling reason might be the need to integrate with other applications, for instance. This is a job that is difficult to do with Forms, but is fairly easy with the ADF's open framework. Another reason to switch is if your organizations' business logic has undergone some change, and the change in workflow affects the Forms app. At this point, the switch would be feasible.
On the other hand, if your budget is limited, you may want to hold off on the switchover.
"Many aspects of a Form application can't be replicated" through a Web browser, Nocera said. For instance, any custom extensions that were made for Forms, for instance, will have to be recreated from scratch in ADF. A Forms app could use the Windows client machine registry to store user preferences, but this is not possible using a Web browser. Also, an ADF application will lock the database in a different fashion than a Forms app. As a result, the order in which records are committed are different in ADF.
With the change in technology also comes a change in practices. Whereas the Forms developer worked with tables, the ADF programmer must use view objects. Triggers in Forms must be rendered in task flows, in ADF, they are done by Java methods or Groovy expressions. Instead of libraries, ADF apps use application modules. On the server side, external calls in Forms applications must be mapped to BPEL or Enterprise Service Bus conduits in ADF.
In addition to technology issues, an organization will also face staffing issues when switching from Forms to ADF, Nocera said. Not all Oracle Forms developers may be willing, or even able, to learn ADF. A shop will have to recruit ADF developers, or at least Java developers who could probably get up to speed on ADF fairly quickly.
Joab Jackson is the senior technology editor for Government Computer News.