Thursday, February 21, 2008

What will eventually replace Forms?

Someone called 'Anonymous' (that guy sure does get around) posed a question from my previous posting on Apex vs JDeveloper, which I thought could flesh out nicely into a new blog, so here it is:
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 ?

Oracle has the vision of having JDeveloper and the ADF framework as its next "best thing". They are pumping their resources into re-working their eBusiness Suite from Forms to JDev/ADF, so with that investment comes a kind of reassurance that it will not be left by the wayside. They will continue to refine and mature the ADF technology, as well as ensuring that the Support structure is there for both eBusiness Suite users and those moving from Forms to JDeveloper.

I think that Oracle is in a critical technology transition period, where the ADF technology they are promoting has not yet reached a point where it is mature as Forms. It is critical because people/businesses are going to realise that this is the case and will start to evaluate their other options more openly.

ADF Faces doesn't come close to delivering the visually appealing UI that users demand for viewing their applications, although Faces RC is getting there. ADF Swing looks like it has the capability to be a contender to a Forms UI, but Swing itself seems to be falling out of favour amongst the Java community. Even Sun themselves are not expanding the Swing framework, but are instead developing and promoting Java FX as the replacement for Swing. So we can see that there is this never ending cycle of maturing a technology then putting it out to pasture in favour the new up-and-coming solution to everything. But I guess that's how the world turns and corporations make their money.

So, I'm not really sure what will eventually replace Forms. In terms of Oracle tools, then I would side with JDeveloper/ADF for your standard application that involves not just database operations, but interaction with third-party/client-side applications. There is more emphasis on Apex for database centric applications that can be purely web-based. It depends how the application is to be deployed and used.
For non-Oracle tools, it's worth looking at Adobe Flex and Microsoft's .NET (Oracle provides a nice .NET Data Access Components plugin for rapid database-app development) to see what they offer.

Onto the second question. Apex is basically a PLSQL environment, sitting on top of (within) an Oracle database. It relies heavily on Javascript for client-side operations and AJAX functionality. I'm not sure if you can (or would want to) use Java or JDeveloper with Apex, since it is really just an application running from within the database. HTML pages are generated and served from the database, so the only Java calls would be to those classes that have been imported into the database.
So, I would say No, Apex and JDeveloper are not meant for each other - a marriage such as that would not even last through the honeymoon period, there would be waaaay too much bickering and fighting going on.

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...

Thursday, February 7, 2008

Flexing Oracle

Attempting to create a Data Access Descriptor so that I can access pl/sql via a web browser, or other simple http access. This will come in handy if/when I need to access XML data when using another UI framework (such as Adobe Flex)
First, login as SYS into my 11g database and run the following:

DBMS_EPG.create_dad (
dad_name => 'dataAccess',
path => '/dataAccess/*');

DBMS_EPG.authorize_dad (
dad_name => 'dataAccess',
user => '<databaseuser>');

Then I create a simple test procedure in my schema

CREATE OR REPLACE get_test_xml_p
lvc_cust_id VARCHAR2(10) := '1';
htp.p('<?xml version="1.0" ?>
'John Doe||

I can alter that to grab dynamic data later. Meanwhile, test access to that procedure in my favourite browser.


It brings the expected results, so let's go from there...
In Adobe Flex, I can then create a request to call the procedure:

<mx:Application xmlns:mx="" layout="absolute" width="682" height="426" creationComplete="getTestXML.send()" >
useProxy="false" />
<mx:TextInput width="100" id="custID" text="{getTestXML.lastResult.CUSTOMERS.CUSTOMER.ID}"/>
<mx:TextInput id="custName" text="{getTestXML.lastResult.CUSTOMERS.CUSTOMER.NAME}"/>

And, hey presto, the data is returned into the expected fields...
Interesting points to note:
1. The XML nodes are case sensitive, so when you are retrieving data, make sure you code it correctly.
getTestXML.lastResult.CUSTOMERS.CUSTOMER.ID is not equal to
2. You will be prompted for an XDB login, which equates to the login. I am fairly sure this can be setup programmatically somewhere along the line (and can of course be added as a parameter to the Data Access Descriptor through EnterpriseManager. Putting the username and password into the URL does not seem to want to work.