APEX and/or ADF – demonstrating two similar yet different applications

Last Monday, we organized an AMIS Query on APEX and ADF. Dimitri Gielis, APEX specialist, joined us and presented his ideas on APEX. I took on the role as ADF champion and introduced ADF to the audience. We explicitly did not have the intention to make it a competition, a shoot-out or even a head to head comparison. We wanted to show APEX as well as ADF, discuss some their respective strong points and relative weaknesses and then have the audience decide for themselves what tool they would use in which circumstances. Also see APEX and/or ADF – demonstrating two similar yet different applications – part 2 for an illustration of the demo applications Dimitri and I had created in APEX and ADF respectively.

There was huge interest in this session – for the first time since we started organizing AMIS Queries we actually had to disappoint people: we were completely booked!

The session was great fun! As you can read on several reports in the blog’o’sphere:

• Dimitri himself
• Marco Gralike
• http://tonguc.wordpress.com/2007/12/20/apex-vs-adf-study/  
• Douwe Pieter van de Bos (Dutch) 

You can download the presentations at: http://www.amis.nl/tech_artikelen.php?id=570  

It was also clear from the many energetic, sometimes even heated debates in our presentation room as well in the corridors, the bar and on the way out, the discussion really appealed to the audience, in several ways I suppose.

An important part of the presentations and demonstrations Dimitri and I did, was the Online Survey application: based on a data model with six database tables and an extremely brief functional description (two lines of text) we both were faced with the challenge of developing an application in our favorite development technology stack in less than six hours. During the session, we presented both the application as we had been able to develop it in six hours, as well as the time bookkeeping overview, to make it clear what had been the real challenges in developing the application.

The classic trap

I now realize that I feel in to the same old trap I myself and so many ADF developers fall into over an over again, when presenting ADF: I focused on functionality and largely forgot about look & feel! I was able to demonstrate a functionally quite rich application – certainly not bad for 6 odd hours of development time. However, the overall impression the application seemed to make on the audience was damped I believe by their unexcitement at how it looked. Yes, it did a good job functionally, but it was not appealing in any way! If I, like Dimitri had done, had taken some time to work at the layout, the UI, to create something less ‘boring old ADF’ and perhaps more like the un-ADF like application I am creating for my current customer (see for example

) I could have made ADF make a far better impression. Dropping one or two of the most advanced functional enhancement would not really have made a big difference, as the application was quite rich as it was.

I think this is typical of the way we frequently tend to develop ADF applications (as we did in the past and sometimes still do with Oracle Forms): too little focus on appearance, attractiveness to end users, visual likability and too much focus on (data oriented) functionality, creating pages with lots of complex functionality, very unlike your average website.

Some of the trends I spotted during Oracle Open World 2007 last month will help us to find a better way. The focus on task oriented UIs, embedded social networking and Web 2.0 concepts, development using reusable building blocks (such as Portlets) will force us to create more consistence, visually attractive and focused pages. The ADF 11g Rich Client Components will go a long way in supporting that visual attractiveness.

Balanced Story

I have been asked by quite a few people ‘why I was so meek, so humble almost’ during the session. Dimitri, passionate about APEX and after having established himself as David against Goliath free to use every dirty trick in the book, had no qualms about positioning APEX as the smart, agile alternative to the dinosaur-like ADF stack and Java as the stuff only realistically usable for the nerdiest of developers, too complex for normal, reasonable people. Dimitri went to the extreme (I think) in suggesting that there is no situation where he would not recommend using APEX – unless perhaps in organizations with scores of Java developers. In addition, Dimitri was very charming and funny, almost seducing the audience with an image of perfect world with a perfect development tool.

 
On the other hand, perhaps like a scientist or conscientious politician, ever looking for the nuance, trying to present a balanced views of the world, afraid of too strong, general statements, I by comparison may have appeared a little hesitant. I certainly did not push ADF as the best solution in every circumstance. And I can perfectly accept or even propose conditions where APEX is the optimal choice. As an example of my lack of polemical skills: when asked what the development of the Online Survey application (more on that later) would have taken without the use of JHeadstart, I suggested that might have been as much as three weeks (rather than 6 hours). What I meant to say – but utterly failed to explain- was that the application I had created with ADF and JHeadstart was so rich in functionality and generic infrastructure – from database error-handling, advanced search capabilities, complex List of Values to full NLS support including runtime customization of boiler plate text, built-in (declarative) AJAX functionality, client and server side validation and many more integrated functions, that to create an application with similar generic plumbing and all the runtime facilities provided by JHeadstart would take that long. I failed on two accounts: developing really everything that JHeadstart brings to the runtime application would take far, far longer than three weeks. However, developing an application that is fully comparable to the APEX application – RAD style, data(base) oriented, basic functionality, … – with only ADF would probably not have to take any longer than 6 hours. Maybe even considerably less. And of course the audience heard me say three weeks and could not possibly guess what in my mind that three weeks consisted of.

Well, I can only hope that not all subtlety was lost on the audience, and an impression survived that does justice to both APEX and ADF.

My ‘balanced’ opinion

Before we went into this event, I had had some encounters with APEX. However, they had not been too successful. I had been a little overwhelmed by the many options and settings, and the somewhat unstructured way I found them organized. I liked some of the APEX applications I had seen, including the World Cup Football application Dimitri had created. However, I had not been able to quickly create something very useful myself.

To a certain extent, that impression has not been changed: Dimitri’s demonstration showed the same long long pages with tens of dozens of options and settings for an item that he of course knew his way around bu
t overwhelmed me somewhat. Howe
ver, the structure of the way of working and the types of properties to define for Blocks (Regions) and Items became clear. And it turns out to be quite similar to the way of working with JHeadstart/ADF.

The ability of very rapidly developing and publishing a web based application is unsurpassed. Literally within minutes you can have simple applications with full database integration running. Typically, I would expect, on your company’s intranet. I have some reservations about publishing an APEX application on the internet, unless the database underpinning that application is detached from the corporate database infrastructure and just a standalone application serving database.

In situations where a web application with serious data reporting or data manipulation requirements should be up and running in a matter of days, I would certainly consider APEX, as it can perfectly do that job. For users with little programming experience, it should be possible to declaratively create a functional application, that may not be visually top of of bill, but may even look decent enough. As such, it can be a replacement for ‘development tools’ such as Access and Excel.

You need nothing but a browser and an account on an Oracle 10g/11g database (even XE will do) to start developing, managing and deploying & using the application. This extremely low threshold for using APEX is a huge boon!

I consider the Repository based character of APEX a big plus! Dimitri almost shyly (quite unlike him!) admitted to that fact and thought people would regard it a disadvantage. However, having benefited from the Multiuser Repository infrastructure of Oracle Designer for many years, I am well aware of the many advantages such an environment has. Team development is much easier in such an environment than it is in a (local) file system oriented setup. The very limited support for versioning is more of an issue. That will hamper more complex, larger scale and longer term maintenance cycles with APEX. The solution Dimitri described with creating exports, splitting them into smaller files (per page for example) and managing them in an external, file based versioning system sounds somewhat complex and error-prone.

It is undoubtedly a smaller step for a ‘classic’ Oracle developer to start developing web applications using APEX than it is to become an ADF developer. I can see a danger in that: classic Oracle developers seem to be getting the impression that their current Oracle Designer/Oracle Forms skills may not last them for very much longer and they seem to feel a push towards web based applications. While the main push from Oracle is towards Java – and implicitly ADF – they may feel that APEX is good alternative. After all, APEX is web too – and HTML, JavaScript and CSS based, just like Java Web Applications. And to do APEX, you can work with your existing SQL and PL/SQL skills. So why bother to get into all that overly complex Java stuff?

I like APEX. I will wholeheartedly recommend APEX in certain circumstances. By the way, I will also recommend using Oracle Forms for many more years in certain circumstances. However, I do not believe in APEX as a strategic application development stack for developing mission critical, long term, enterprise level applications. Any application that is intended from the onset to be used for more than a few years in my opinion should not be created using APEX. While APEX perfectly complements core development platforms, such as Oracle Forms, .NET and Java/J(2)EE (for example ADF), it is no replacement for them. In addition: I am not convinced of Oracle’s long term strategic commitment to APEX. Fusion Applications and large sections of Oracle E-Business Suite are being built using ADF. More strategic commitment is hardly possible for Oracle to show.

Some other hesitations with APEX: using the database as application server, lack of integration/support for crucial concepts such as WebCenter, SOA (BPEL, Workflow) in general, E-Business Suite and Fusion Applications; scalability; security – especially outside the corporate intranet.

Some people suggested that ADF and APEX can perhaps be used within a single application. Both Dimitri and myself do not really see the benefit of combining the two, at least not on a permanent base. Perhaps APEX can be used for a quick solution to an urgent challenge that ADF can provide a more lasting, robust solution for.

Others proposed APEX as a good first step for Oracle developers in their make-over to ADF developers. I personally do not really find a lot of value in that approach. Getting to know HTML and JavaScript is useful for ADF developers and APEX developers alike. But moving to APEX when you know the next destination is ADF seems to be step in the wrong direction. Not one I would recommend.

One thing Dimitri and I both stressed, several times and with a lot of vigor, is the importance for any type of web development with either ADF or APEX of up-to-date database skills. Knowledge of the latest features of both SQL and PL/SQL can be a tremendous help in developing applications. We both prefer to make extensive use of the database for all the things it is good at. We do not believe in database independence or portable (cross database) applications. Since databases typically survive (several generations of applications), the more (data oriented) functionality can be provided by the data layer in the application architecture- note that APEX applications may be in the database physically but are not part of the data layer logically – the better.

Conclusion

In a subsequent article, I will discuss the Online Survey applications Dimitri and I developed, showing how to very distinct technologies can be used to create rather similar applications with almost the same solutions for the same challenges. 

In this article, I hope to have clear that I consider APEX to be a valuable tool in the Oracle developer’s toolbox. To be used under specific circumstances (tactical applications, very short time to market, short to mid-term life expectancy, Oracle skilled development staff).  But in my opinion not to be seen as a strategic, core development technology stack.