AMIS Query: The Future of Oracle Designer (and other tools)

Oracle’s Development Tools – Current Status and Statement of Direction

After welcoming the audience, I did an overview of the history and current status of the Oracle development tools. This was inspired of course by my own experiences – starting 1994 with Forms 3.0 and CASE 5.0 – and also by much of what I learned during the most recent ODTUG conference, the Statements of Direction for Tools and Oracle SCM on OTN and other publications and statements. My presentation can be found here.

The PL/SQL Development toolstack under scrutiny in this session looks as follows:

Oracle Designer

Some of the conclusions for the current situation are (indicative, no hard figures):

• Perhaps as many as 25% of the Oracle Designer users is still on 1.3.2, even though support stopped quite a while ago
• Around 20% is already on 9i/10g, though that group is growing fast according to the Oracle Consulting experience
• Roughly 70% of Designer users uses it to generate applications; a small group among them only generates Web PL/SQL applications. Generation of Reports is not seen very often anymore. Around 50% of Dutch Oracle Designer users also uses CDM and Headstart (some 400 companies). Some 40% of that group also uses CDM RuleFrame.
• Versioning (Oracle SCM in versioned mode) is used in some 25% of the cases where organisation already are on Designer 6i, 9i or 10g
• It makes no sense to migrate to the 9iDS suite; at this point you would immediately go to 10g (which is in fact 9.0.4, compared with 9.0.2 of the 9iDS); apparently – and I will try to get verification for this on Thursday – Oracle Apps will go from wherever they are right now to 10gDS R2 – to be releases in a few weeks time. Anyone considering a tools-migration would probably make a smart move to stabilize on the same release Oracle Apps takes

New functionality for Oracle Designer has been scarce since the initial release and subsequent stabilization of Release 6i, in 2000. The latest additions have been: improved Server Generation capabilities to support Oracle 8i, Generation of Portlets with the Web PL/SQL Generator and most prominently the Repository Object Browser (previously known as Oracle Designer Web Assistant and developed as part of the iDevelopment Accelerators Suite). One other piece of functionality is the Designer-to-BC4J generator, although that is shipped as part of JDeveloper 10g. Basically, Designer has been a flatliner in terms of functionality (some say: maturity) since 2002.

The Future for Oracle Designer
Oracle is quite clear in its Statement of Direction: no new functionality (“read my lips…”) . This can be seen as a formalization of a situation that for all intents and purposes has existed for quite some time already. However, very importantly: Oracle guarantees new releases of Oracle Designer, certified with new releases of Forms and the RDBMS for installation and generation, for a long time to come. The current 10g release will be supported until January 2010 and new releases that will be supported far beyond that time are promised. That basically means: Oracle Designer as it is today will be around until far into the 2010’s. I have no problem betting anyone a good bottle of wine that in 2015, we – that is, some of use… -will still be doing development with Oracle Designer.

Some comments: the capabilities of Designer in terms Forms generation as well as Server Generation will increasingly fall short of the functionality available in both Forms and the RDBMS. Note that his has always been the case to some extent – and never really was a serious issue. However, the gap will widen. Later in the session we discussed the notion of a Forms Post Generator that we could apply to bridge that gap between the OFG in Designer and current and future Forms releases. Also note that currently there is no serious alternative in the Oracle toolstack for Database Design & Generation as Oracle Designer provides it. Oracle suggests that JDeveloper will play that role in the future; some Table Design and Generation is offered by Oracle 10g JDeveloper – it looks promising but is nowhere near the Designer Capabilities.

Ton tol dhe had composed a web-page in Dutch (?) that tells it all about Oracle Designer. Go to http://www.oracle.com/start and enter keyword Designer. The resulting web-page has links to all statements of direction (soon also the one on Headstart) and many more resources on Oracle Designer.

Oracle SCM

Oracle Software Configuration Manager has its own Statement of Direction. It is pretty damning: “All existing users of Oracle SCM should carefully evaluate the features of the product and decide if its functionality is likely to meet existing and future needs. ” Oracle suggests that File Based Source Code Control can much better be done using CVS than Oracle SCM. No new effort will be put into Oracle SCM. The suggestion “Users yet to decide on a software change management solution for JDeveloper should consider Oracle SCM, but should be aware that as no new features are planned it may fall short of requirements in the future and so may wish to consider alternatives.” cannot really be taken seriously in view of the former.

However, Oracle SCM will stay an integrated part of Oracle Designer – and therefore continue to be released and certified. And for version control of Designer elements such as Table and Module Definitions there simply is no alternative. Besides, Oracle SCM does a fine job of managing those elements. However, the awkward integration between JDeveloper and Oracle SCM will not be improved. Best to shy away from it then – use JDeveloper with CVS. However ideal a single integrated repository with all project deliverables sounds, it is not viable. It will be better to have Oracle SCM for Designer elements and a dedicated Source File system such as CVS for files.

Oracle Forms

Some of the conclusions for the current situation are (indicative, no hard figures):

• Perhaps as many as 35% of the Oracle Forms production applications are still on 4.5 – a small percentage even on 3.0. Around 20% is on 9i or 10g and that number is growing fast according to Oracle Consulting. The percentage of production systems on a WebForms architecture was estimated at 30 to 40%.
• In The Netherlands, 85% of Forms users also uses Oracle Designer; worldwide, that percentage is much lower.
• It makes no sense to migrate to the 9iDS suite; at this point you would immediately go to 10g (which is in fact 9.0.4, compared with 9.0.2 of the 9iDS); apparently – and I will try to get verification for this on Thursday – Oracle Apps will go from wherever they are right now to 10gDS R2 – to be releases in a few weeks time. Anyone considering a tools-migration would probably make a smart move to stabilize on the same release Oracle Apps takes

New functionality for Oracle Forms has been substantial in the recent year. The most important development in my view is the rise of Java in the WebForms development and run-time environments. The JDAPI (Java Development API) allows very interesting opportunities for automated manipulation of FMBs – see further in this post for an application of the JDAPI. Even more important are Client-side and Middle-Tier Java integration features – Pluggable Java Components, Java Callouts etc. This means that WebForms applications do not have to be a class of their own, an island within Java/J2EE architectures but instead can be completely integrated in Java/J2EE environments. With unparallel development productivity and a feature-rich, powerful end-user interface, WebForms is for many applications far superior to what plain Java can offer. It is important that (If you cannot beat them, join them) by absorbing Java and opening up to the Java/J2EE world, WebForms has a much wider playing field.

The Future for Oracle Forms
Oracle is quite clear in its Statement of Direction: “Oracle Forms and Oracle Reports will continue to be enhanced and will introduce new features in the future versions of the application server. ”

If you have doubt for whatever reason that Oracle does indeed intend to seriously continue work on Oracle Forms, here is your assurance: “Oracle Forms, Oracle Reports, and Oracle Designer have a large and very active install base, with applications developed with these tools being the cornerstone of many businesses including Oracle’s own E-Business Suite. Oracle recognizes this considerable investment and remains committed to the long-term support of these products.”

Oracle has an incredible volume of Forms-code in Oracle Apps and absolutely no intention of migrating that to some other technology. There simply is no business justification for doing that. Note however that while Oracle Designer is listed in the statement above, Apps makes no substantial use of Oracle Designer, and where it does only for Database Design and Generation.