Tuesday, February 19, 2008

Apex vs JDev - first impressions

Following on from our JDeveloper/ADF workshop, we also reserved some time to compare the benefits of Apex (formerly HTMLDB). We brought in Penny Cookson from Sage Computing to give us a 3-day run-down. Now I feel that I can give a quick first-impressions comparison between the two development approaches. Here's a quick overview, in no particular order.

  • Apex seems to be very good at rapid development for simple every-day data and database actions.
  • Apex does not seem to be very good at calling and interacting with third-party applications (except through webservices).
  • Apex allows rich data displays, although it is restricted to browser-compatible constructs such as HTML, Javascript and Flash charts.
  • JDev requires a larger learning curve than Apex, but allows separation of layers (MVC), making it easier if a differing (UI) technology is to be introduced later on down the track.
  • Apex simply requires the database (which can be scaled), and does not require separate Application Servers for distribution.
  • Neither Apex nor JDev's ADF Faces would allow us to reproduce our current Forms application look-and-feel as it stands.
  • JDev's ADF Swing may come close to providing the same Forms application UI, but requires a larger amount of Java programming skills.
  • Oracle is using Apex on its subdomains Metalink and AskTom, and seems to be quite productive with the experience.
  • Oracle is using JDev/ADF for re-developing its eBusiness Suite.
  • (As an aside, Oracle also uses Adobe Flex on Metalink - and it looks good.)

To explain where I am coming from, and the users our application has to appease, our current Forms application was met with a furious uproar when we moved from Forms 6i to Forms 10g. The users were very keen to retain all visual aspects (even down to the specific shades of grey), and also expected to retain productivity using either keyboard or mouse. In most cases we were able to provide a one-to-one match, but we had to fight the code to allow interaction with some client-side third-party apps.

If we are to attempt to reproduce Oracle Forms usability with a new technology - be that Apex, JDeveloper, or something else entirely - it has to allow the users to be as productive (or more so) based on how they already operate using the current Forms application. But we also have to consider developer productivity, and whole range of other factors.

As it stands, it seems that Apex would only be suitable for reproducing a small subset of our security/maintenance screens, or for our internet-facing applications, but could probably not cope with the demand from our internal users. JDeveloper (ADF Faces) may eventually be a candidate for our internal application development, but still does not seem to be mature enough in regard to rich UI components (note that I have not had a chance to review the offerings of ADF Faces RC to any extent).

So, the search is still on for a development approach that achieves that fine balance between developer productivity and user satisfaction...

7 comments:

Patrick said...

Thanks .. good article.

Patrick

Anonymous said...

Marc what do you think will eventually replace Forms Jdeveloper/ADF? Also, can you use Java/Jdev with Apex or is it basically PLSQL environment ?

Marc Thompson said...

For an answer to your questions, see my new post 'What will eventually replace Forms?'

Dimitri Gielis said...

Hi Marc,

Can you explain further:

"Apex does not seem to be very good at calling and interacting with third-party applications (except through webservices)."

What 3rd party applications are you talking about? What do you want more than using webservices or the database features to get to the data?

"Apex could probably not cope with the demand from our internal users"

What is that demand then? Rich UI?

I'm interested in this as I gave a talk about APEX vs ADF before (http://dgielis.blogspot.com/2007/12/apex-vs-adf-round-1.html) and will give it again in June at ODTUG.

Thanks,
Dimitri

Marc Thompson said...

Hi Dimitri,
Our current Forms application calls out to MS Word via OLE2 and Host calls, as well as our document management system (also via OLE2). It also makes system (Host) calls out to specialised printers connected to local client machines. So, we need to ensure that we can continue to provide this type of functionality.
So, it's not the 'getting to the data' that is the problem, it is passing data (both from the database and directly from the user) along to applications outside of Apex that is the area we have to wrestle with.

Our application users are also used to a Rich UI, with fast responding tree controls, tabs and multiple windows (amongst other things). Now, while Apex can provide these types of mechanisms to some extent you must take note of the following restrictions when attempting to reproduce them on a web page:
* tree controls are usually not PPR-aware, meaning that if you expand a node, then a Submit event occurs;
* tabs relate to separate pages, which result in slow loading times (again, a Submit event occurs);
* multiple windows (especially modal windows - can you even have modal windows in Apex?) are difficult to manage.

So, while I can see the obvious benefits of a tightly bound UI-to-database application, Apex doesn't allow the same local machine interaction and performance and, quite rightly, is probably not too concerned with.
This would be fine for 70% of our current Forms application, but a separation of areas into two applications written in 2 UI technologies would be a burden of re-development that we could not justify at this time.

Now, don't get me wrong, I am still keenly interested in Apex and all it has to offer - I would love to turn around to our users and present them with a fully fledged Apex application, but it would take some time to work out how to fit their current business processes into something that Apex could manage.

Cheers,
Marc.

Anonymous said...

I use about 40 forms6i client-server applications to collect and view medical data. I don't know if APEX is to small or JDevelper ist to big ( in case i don't want to learn Java). Is the JDeveloper interface similar to the forms6i developer, with drag und drop and menu-Buttons to produce full forms?

Marc Thompson said...

For a 40-form application you might want to do a pilot using a couple of those forms and re-write them using APEX. This will probably lend itself fairly well to your application since it is just used to view and collect data.
Meanwhile, the JDeveloper interface has parallels to Forms Developer, but takes a while to get used to, especially if you have not had any Java exposure before. Having said that, you may find that its wizard-based development will provide you with everything you need to produce a workable application.

It is definitely worth having a play around with both of the tools, and see how they compare based on your own programming experience.

Good luck!