APEX contra ADF?

Pushing to the bank holidays, trying to get rid of the piles of work before I / we start a new year, I would almost forget to thank Dimitri and Lucas for the great session / AMIS Query (the one with the very long title: “AMIS Query – on developing Web Applications with Oracle development technology: ADF and Application Express side by side (with Dimitri Gielis and Lucas Jellema)” in which two technology platforms were explained and cross referenced regarding the “how, what, where” and the “when to use it and when not”. It was also a small “clash” between two evangelistic technology enthusiasts that, despite that this wasn’t the purpose of the evening, but also probably couldn’t be avoided, was tried to decide on humoristic merits.

To make it more interesting, a goal was defined before this evening: “Try to create a survey application in less than 6 hours using a defined small database model”. Both “worlds” encountered the same problems (for instance, imperfect physical design)  and, to their surprise, also mastered it (more or less) via the same methods. This made it actually even more interesting and a better re-presentation off handling overall day to day programmer problems in a ADF or APEX fashion.

In my view, APEX “won” pointers in respect of being a “fast”, database / repository driven framework. ADF “won” pointers, on the other hand, especially combined with JHeadstart (to increase productivity), as being very powerful, more flexible framework to create more enterprise driven software that can be more easily integrated with , for instance, BPEL driven processes or SOA architectures. To be honest, I started off with being very pro-APEX, but I was impressed with the ease of building certain components, like a master-detail window in ADF, and not being as complex or cumbersome as I thought.

If it was a realistic comparison? I don’t know. It was a clashing of worlds; a Java (with its methods) driven world against a database, PL/SQL driven world. That fact alone was already very insightful displaying and demonstrating the pro’s and con’s of those technology stacks and solutions. So thank you very much Dimitri and Lucas; Michiel Jonkers starting it all up; and of course all the people that made the event possible!.

For more information and the presentations see also:

• AMIS Query: APEX and ADF, side by side
• Dimitri on APEX (and a high resolution version)
• Lucas on ADF

Marco

Additional

I reformatted some useful comments, here directly in the post, so they are easier to read

Marco
—————————————————————————————————————————————————————————–

Lucas, Dimitri,

I like to thank you guys for the wonderful “match” of Dec 17th between ADF and APEX. The big question is off course: who is the winner?!?

Well that looks like the question that I encountered a few months ago on a forum. “What is better a screwdriver or a hammer?”
A beautiful question (and total ridiculous if you don’t know anything about environment, requirements etc. etc.).

Let us not try to answer that question and let me give some remarks/comments (even doubts) about both products:

-ADF-

I agree with Lucas that ADF has quite a long history. But compared to Designer/Forms I doubt on it productivity. May because I am a D2K dinosaur and I am (to) fresh from the ADF course but this opinion is shared with the 12 other persons from the course. Personally telling why ADF is so stabile and just mentioning Jheadstart is not quite fair. Jheadstart is not standard included in ADF. (Actually I think it should). In my honest opinion it was Jheadstart against Apex. (Lucas indicated when every thing has to be done from scratch in ADF it would be probably 3 weeks). And if we consider Jheadstart the installed base is limited to 10 a 20 licenses in the Netherlands. And if I am correct we already had several technology switches in JHeadstart (UIX->Struts->ADF). That makes its ‘stability and portability’ quite relative…

-APEX-

My mistake with Apex is that I was biased even prejudiced. Probably because of my disappointment with WebDB, I didn’t investigate HTMLdb possibilities fully. I didn’t notice that the APEX community (and product) was growing so fast. And that without Mr. Oracle is pushing… My (first) impression of APEX was, “A nice tool for simple Application’s”. Now I know that APEX is capable to handle complex applications with a lot of users and large volume data. And if we keep data related logic and business rule in the database (server concentrated or “Fat Database” to use Toon Koppelaars words). It isn’t important what level of complexity the client handles. In that philosophy we target on “thin clients”. What I do wonder about APEX is scalability! How do we scale? I don’t see solutions like additional application servers and load balancers. With the new architecture has to be done in the database (RAC?) or faster hardware (with more memory resources). If Dimitri would addre
ss this topic I would be grateful.

Basically what I am saying is: Before choosing a tool you need to know what you want to make. And what are the targets? Database independency?! Well in that case neither Apex nor ADF will be favorite I guess. But in an Oracle workshop with “Oracle techies”, I believe APEX will have its place.

Regards,

JB
 

—————————————————————————————————————————————————————————–

Just a comment on JB’s remark “we already had several technology switches in JHeadstart (UIX->Struts->ADF). That makes its ’stability and portability’ quite relative…”

It’s true that the first JHeadstart production release used different technologies for the Model-View-Controller layers than the current one. We started out with JHeadstart’s own Data Handlers for the Model layer, UIX for the View layer, and MVC Framework for the Controller layer. Then we moved to JHeadstart Data Handlers + UIX + Struts, and then to ADF Model + UIX + Struts, and now to ADF Model + ADF Faces + JSF. But one thing remained the same: the Application meta data stored in a JHeadstart XML file. The MVC technologies used by JHeadstart over time reflect the rapid changes in the Oracle Java world, but using JHeadstart you could easily upgrade the generated application. You can compare it to Designer modules first generating client/server Forms, but as the technology evolved it became possible to generate WebForms using the same module definitions.

So I disagree with JB that the changes in used technology indicate a lack of stability and portability, in fact it indicates the opposite! Using JHeadstart (and especially if you use the 10.1.3 version with a high degree of generatability) it is easier to go with the flow of changing Java technologies. See also the JHeadstart Feature List, topic Upgrading to JDeveloper R11 and beyond, at http://www.oracle.com/technology/products/jheadstart/jhsfeaturelist.html#r11.

Sandra Muller

—————————————————————————————————————————————————————————–
—————————————————————————————————————————————————————————–