Re: Oracle Forms VS Java

Ryan wrote:

> Ive made quite a few forms and a fair size for a medium complex form is
> about 600 KB. That is quite a bit of bandwidth.
>
> Talked ot a project lead about why they chose .Net over forms. Basically for
> that reason.

Following diatribe addresses why the size of the form executable is not related to the network traffic.......

In today's Forms deployments, a form is loaded into the Forms Server in the middle tier. The business logic is run at this level and not sent to the client. The display logic is (of course) sent to the client where it provides a much richer (and customizable) interface than traditional HTML.

Due to the old Microsoft-Sun Java wars and historical delays in getting browsers to support current certified JVMs, Oracle supplies it's own JVM and class library to ensure operability. Downloading that initial plug-in is just as painfull & slow as geting Flash, Real Player or any other plug-ins. (Based on the recent Tech Days presentations in North America, I understand Oracle is looking at a solution to this.)

After that initial download, the network traffic is largely reduced to connect and draw screen which heavily uses the class library; on-events to communicate with the middle tier (not the database); loading up lists; and custom Java. (Loading up lists can be a network burden if set up badly.) The on-events tend to be things like passing the contents of a field to the middle tier and allowing it to do the validation. Some very simple validations such as numeric and case sensistivity can - or soon will - be done at the client.

The size of the form or .fmx should not have any real impact in the network traffic unless it has an extremely complicated front end (and then you need to compare to the HTML equivalent). The form should be run in the middle tier, and only the client interface should get to the client machine.

One benefit of this 3-tier operation is that any chatty database interaction is isolated to the back 2 tiers where you have control and the ability to resize the network as required. This chattiness is where most applications lose out and have huge network requirements (and it one of the reasons for going away from client-server.)

In the Forms 4.0/4.5 days - Oracle's first crack at trying to make Forms run both client-server and 3-tier with no developer's code changes - there was significant network overhead and Forms got a bad rap. (In addition, for a while there was a huge outcry about downloading plug-ins in a corporate environment.) Oracle has spent a lot of time and energy in reducing that overhead to a very reasonable amount - the results are described in the customer document I referenced ... it is worth a look even if you take it with a grain a salt. I have used Forms-based apps on a 56K modem line and achieved acceptable response times (wrist-watch timing under 2 sec.)

Using Forms does not preclude Java at the front end or the middle tier (or both). So you should be able to leverage J2SE and J2EE - no personal experience on this, though.

IMO, the biggest advantage of Forms is that it has about 20 years of rapid application development history. As a result, productivity can be very high - in my case I always felt I could develop and deploy in 1/2 to 1/5 the time of any other language I wanted to use. The biggest disadvantage I think is the lack of experienced developers (apparently since the name hasn't changed a lot over 20 years, some developers think it's old and not worth learning.)

Would I use Forms everywhere? No! Just where I expect the users to have an interaction with my system daily or at least once per week/month. And where each interaction requires significant data checking and busienss logic.

Would I stack up a Forms app. against a .net or J2EE app? Yes - if I include time to deploy and the cost of maintaining the app over 2+ years, especially allowing for a database change every 3 months. (I hate spending significant time re-learning my old code to add a new column.) Received on Sun Jun 01 2003 - 11:33:20 CDT