Oracle Forms VS Java
Daniel Frechette
I'm currently working on a project to modify an existing system that was
developed in Oracle Forms 4.5 (Web-enabled) and Java (J2EE, JRun, Oracle
DB). I now have a new application to develop but I don't know if it should
be done in Forms or Java. The new application has to be light and
accessible through a Web browser. I'm trying to assess the pros and cons of
both approaches but I know very little about Forms. Can anyone tell me what
are the TRUE ADVANTAGES AND DISADVANTAGES of Oracle Forms? Does anyone know
of any studies or architecture comparisons that might be helpful?
Thank you,
Daniel
Hans Forbrich
Lots of architectural info and details at the Products/Development Tools
section of OTN (http://otn.oracle.com) (You'll soon be getting a lot of advice
from all directions.)
Both development environment can result in a good web-based program. A lot
depends on the effort you want to make in learning the environment. Either
way, the Java/J2EE environment is accessible - it's not excluded in a Forms
decision.
Forms was the original database-oriented 4GL back in the 80s. As such, it is
designed to put in predefined blocks of code to accomplish specific tasks such
as on-character, on-entry, on-select, etc. but Oracle has worked on the
internals over the years and these blocks are pretty efficient. Forms version
4.5 is obsolete - you would be looking at Forms 6i if you wanted client-server
& web-based or Forms9i for web-based only support. Forms9i is considerably
further ahead in web technology since Oracle decided to drop client-server and
drop forcing compatibility with client-server style interaction. (No sense in
you even looking at Forms 6i - forget 4.5)
Forms9i High level - True n-tier, it uses a middle tier server to serve up the
forms pages - you could almost get a JSP analogy except it's much richer than
JSPs. Transmits it's own JVM and class library, called JInitiator, on first
contact making the first contact slow, but that apparently is being (has been?)
eliminated. After that download, it's pretty reasonable for performance. It
has the ability to hook in your Java stuff at both the client side or the
middle tier. Understands and can leverage all of the database capabilities
without additional code consideration. Allows creation of reusable code-block
libraries. Supports look-and-feel templating.
You need Oracle's Developer Suite to create Forms - but you also get
JDeveloper, Reports Developer, Designer and Source Code Management and a few
other things. Designer (not easy to learn on your own) allows bi-directional
generation and reverse engineering.
You also need Oracle's Application Server to deploy Forms but you also get the
ability to deploy Reports, Discoverer (ad-hoc query), J2EE, and so on.
Where in Canada are you located? I can probably get you in contact with some
experienced Forms developers in your neighborhood. (my return address is in
clear).
Michael Kuznetsov
Hi Denial,
Java gives you two possibilities to create user interface:
1. HTML interface generated by JSP
2. Windows Swing that can be run as applet in browser.
3. Windows Swing that can be run as installed application
Oracle Forms gives one possibilities for web:
1. Applet in browser window (size is big).
So if you need HTML interface you can't use Forms.
If you decide that applets is OK for your system you should decide
what approach is better.
Forms is more high-level tools then Java. But it is very specific.
It's depended on PL/SQL and set of interface triggers. User interface
on forms usually is poor. You don't need think about network
communication and database. But you also don't have control for it.
Interaction with operating system is also poor.
On the contrary Java depended on well-known standards and give you
full control on program. It is allow you write perfect GUI. But it is
more low level and time to start with Java is higher.
I think Java is better and flexible solution for most application. And
Oracle supports Forms mainly for old systems.
Regards,
Michael
Brainbench MVP for Oracle Programming
http://www.brainbench.com
Hans Forbrich
Forms 4.5, but there have been many improvements. Some of the improvements are listed at OTN.
Ryan
"Michael Kuznetsov" <m...@servocomp.ru> wrote in message
news:1543a3e7.03053...@posting.google.com...
i have been told that forms has alot of network traffic over the web.. do
you know if this is accurate?
Hans Forbrich
> i have been told that forms has alot of network traffic over the web.. do
> you know if this is accurate?
Customer Testimonial: Retek - A Benchmark Comparison of Client/Server and Web
Deployment @ http://otn.oracle.com/products/forms/pdf/256631.pdf
......... http://otn.oracle.com/products/forms/techlisting.html
Ana C. Dent
> Daniel Frechette <dan...@multipro.ca> wrote in message news:<Xns938AEE055E289...@207.35.177.134>...
>
>>Good day,
>>
>>I'm currently working on a project to modify an existing system that was
>>developed in Oracle Forms 4.5 (Web-enabled) and Java (J2EE, JRun, Oracle
>>DB). I now have a new application to develop but I don't know if it should
>>be done in Forms or Java. The new application has to be light and
>>accessible through a Web browser. I'm trying to assess the pros and cons of
>>both approaches but I know very little about Forms. Can anyone tell me what
>>are the TRUE ADVANTAGES AND DISADVANTAGES of Oracle Forms? Does anyone know
>>of any studies or architecture comparisons that might be helpful?
>>
>>Thank you,
>>Daniel
>
>
> Hi Denial,
>
> Java gives you two possibilities to create user interface:
> 1. HTML interface generated by JSP
> 2. Windows Swing that can be run as applet in browser.
> 3. Windows Swing that can be run as installed application
>
> Oracle Forms gives one possibilities for web:
> 1. Applet in browser window (size is big).
>
> So if you need HTML interface you can't use Forms.
Golly, I must be hallucinating then.
Just a few minutes ago I would have sworn I was
running 9iAS R2 Forms via my IE Browser. I'm not
clear on how to reconcile my reality with the
sentance immediately above this response.
Daniel Frechette
news:1543a3e7.03053...@posting.google.com:
Thank you very much, Hans and Micheal, for your answers.
Unfortunately, I don't foresee my client upgrading to a higher version
of Forms in the near future.
Hans, what do you mean by "... Oracle decided to drop client-server and
drop forcing compatibility with client-server style interaction"? A
Web-based architecture is and will always be client-server.
My client has many applications written in Forms 4.5 and very few
written in Java/J2EE. I was originally hired to develop a Java/J2EE
solution but some Forms developers started to challenge that decision
and I'm now forced to justify it. Can you give me more input on Forms
4.5.
Thank you,
Daniel
Montreal, Canada
Daniel Frechette
Unfortunately, I don't foresee my client upgrading to a more recent
Hans Forbrich
colleagues are getting moderately unhappy about reading the same posts in
both forums. I suggest cdo.tools.
Daniel Frechette wrote:
> Thank you very much, Hans and Micheal, for your answers.
>
> Unfortunately, I don't foresee my client upgrading to a higher version
> of Forms in the near future.
That is sad. There are many, many advantages to Forms 6i and 9i, not the
least being that Forms 4.5 is no longer supported.
>
> Hans, what do you mean by "... Oracle decided to drop client-server and
> drop forcing compatibility with client-server style interaction"? A
> Web-based architecture is and will always be client-server.
Client-Server, in this context, means that the client that contains the
application - in your case the browser & the applet in the browser
freamework - communicates directly to the database, probably via JDBC or
RMI or via SQL*Net/Net8 or Oracle Networking.
In the new world there is a distinct move toward n-tier computing and
Oracle is at the head of the line marching on boldly. This means that the
client runs either a very skinny applet with Swing as primary
responsibility (eg: controlling display) or pure HTML. Thois client
communicates to a middle tier that contains the bulk of the application
logic, but little/no display logic. In the pure HTML arena, this tends
towards a JSP middle tier, whereas the applet variant tends to use a more
complete range of the available J2EE services and the full EJB suite.
> My client has many applications written in Forms 4.5 and very few
> written in Java/J2EE. I was originally hired to develop a Java/J2EE
> solution but some Forms developers started to challenge that decision
> and I'm now forced to justify it. Can you give me more input on Forms
> 4.5.
Sorry - my Forms 4.5 is too rusty, the internals to the architecture have
changed a lot (in part based on lessons learned from 4.5), and I do not
like the concept of putting an unsupported product into production.. (The
concept of the architecture is still the same, the internals and the
technology have evolved a lot.) If the customer has access to the source,
there is a tremendous benefit - including cost benefit - to upgrading. The
Forms developers should be supporting this (and I am suprirsed that your
comments about 'no upgrade soon' seems to conflict with this.)
Migration from 4.5 to 6i is almost a no-brainer and, if they have paid
support, is at minimal expense to them (aside from time to test). From
there, migration to 9i is also a a minimal jump. Even multi-language
support should not be an issue.
In my mind, your best bet is to get them to migrate to 9i and then show how
you can extend their functionality in both middle tier and front end with
your rich Java & J2EE environment. That should get the Forms guys on your
side and support a major win-win opportunity. (I happen to believe in the
benefits of Forms. I'm also very comfortable with Java & J2EE.)
You want to call the Oracle office in Montreal and ask for the manager from
the presales group. You want him & his people to provide you with a
summary of the Oracle Technology Days session about Forms9i that has been
given in various cities in North America - this gives a fair bit of detail
of the benefits arising from the combined Oracle Forms9i and Java/J2EE
skill set. It will be worth your time! (If you want, I'll give him a
heads-up as well with a bit of background.)
Ryan Gaffuri
thanks but Id prefer not to trust oracle customer testimonials...
compiled Forms still run 600KB, that is pretty heavy weight for a web
deployment.
Robert A.M. van Lopik
"Ana C. Dent" <anac...@hotmail.com> wrote in message
news:_GSBa.61081$MJ5.10434@fed1read03...
> >
> > So if you need HTML interface you can't use Forms.
>
> Golly, I must be hallucinating then.
> Just a few minutes ago I would have sworn I was
> running 9iAS R2 Forms via my IE Browser. I'm not
> clear on how to reconcile my reality with the
> sentance immediately above this response.
>
runs inside your browser. Communication with the server is either through a
special Oracle protocol, or HTTP (in the latest Forms incarnation). So, the
fact that something runs inside your browser does not mean it is based on
HTML.
hth
rob van lopik
David Segall
Daniel Frechette <dan...@multipro.ca> wrote:
My knowledge of both Java and Oracle is almost zero which is why I
bought the "Oracle9i JDeveloper Handbook" published by Oracle Press.
The section entitled JDeveloper: Past, Present, and Future says that
Oracle has "seemingly decided to pursue JDeveloper as the primary
development platform". I take this as meaning that Java is the
preferred language. JDeveloper provides a GUI design interface which
allows you to drag and drop Swing components onto a "form" and to
associate them with a database using Business Components for Java
(BC4J). You can read the relevant section of the book yourself at
http://www.amazon.com/exec/obidos/tg/detail/-/0072223847/ref=lib_rd_ss_TT02/102-4431108-3813734?v=glance&s=books&vi=reader&img=32#reader-link
Hans Forbrich
Ryan Gaffuri wrote:
> Hans Forbrich <forb...@telusplanet.net> wrote in message news:<3ED7D453...@telusplanet.net>...
> > Ryan wrote:
> >
> > > i have been told that forms has alot of network traffic over the web.. do
> > > you know if this is accurate?
> >
> > Customer Testimonial: Retek - A Benchmark Comparison of Client/Server and Web
> > Deployment @ http://otn.oracle.com/products/forms/pdf/256631.pdf
> >
> > ......... http://otn.oracle.com/products/forms/techlisting.html
>
> thanks but Id prefer not to trust oracle customer testimonials...
Are you saying you trust testimonials about Oracle products from sources other than their customers?
maybe their competitors?
No one is asking you to trust it. Without accepting the data in the document at face value, you might
find there is some valid info provided.. Or valid reasons for challenging the document.
> compiled Forms still run 600KB, that is pretty heavy weight for a webdeployment.
A pretty blanket statement. Care to expand on that a bit?
Ryan
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.
Hans Forbrich
> 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.
I get it now - somehow you correlate the size of the form with the bandwidth it
uses.
Just curious - are you trolling?
You make some interesting statements without detailing version, deployment,
etc. For example - you enter this thread with "i have been told that forms has
alot of network traffic over the web.. do you know if this is accurate?". You
are not interested in customer testimonials or testing methods, yet you say "Ive
made quite a few forms and a fair size for a medium complex form ..." And now
we somehow migrate to .net - in Oracle and Java newgroups.
Like I say, just curious.
Carsten Saager
"Ryan" <rgaf...@cox.net> schrieb im Newsbeitrag
news:8mQBa.5012$pu4...@news1.east.cox.net...
>
....
> i have been told that forms has alot of network traffic over the web.. do
> you know if this is accurate?
>
Forms over the web (aka Formsserver) application consume a lot of bandwidth
upon the very first call, since the java-Applet has to be downloaded (later
it can be kept in the cache). Same applies to client-side java.
At runtime though, Form seems to use network-resource very wisely. We have a
cutomer that runs a large Forms-application (biggest .fmx >4MB!) that makes
heavy use of stored procedures over 128kbit ISDN lines! The perfomance is
satisfying - mean response-times are lower than 1sec. They used to run it in
C/S (Net8 over ISDN) resulting in response-times topping 2 minutes(!) due to
the heavy traffic (aprox. 2000 DB-calls upon initialization, several
hundreds on record-change).
The same workstations run a "modern" Java application (a workflow-client)
which is based on J2EE. This is slowed down by the ISDN-line to the limit of
usability. It even degrades network-performance while being idle! OK, this
might be a poor designed Java application, but the point is that one cannot
generalize here.
The Forms application mentioned above ist scheduled for a redesign using
J2EE. It will use Oracle's BC4J since this framework employs many of the
bandwidth reducing techniques that come with Forms (I am not sure, but I
believe that I read something like that Forms9i makes use of these framework
itself.
The decision whether the application will be reimplemented in Java is not
made, because we are looking forward to the 9i-version and its successors
that will solve many of the current problems that triggered the discussion
about the redesign.
We regard the productivity using Forms being much higher than using Java
(considering our database-heavy application) and we have data from similar
projects to prove this. Anyway Forms is considered critical, because it is
very hard to find experienced Forms developers. There are a lot more java
programmers out there that can be trained quickly to work with the chosen
framework. Learning Forms is much harder.
Carsten
Hans Forbrich
> 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.)
Malcolm Dew-Jones
: Posted and emailed:
: Daniel Frechette <dan...@multipro.ca> wrote:
: >Good day,
: >
: >I'm currently working on a project to modify an existing system that was
: >developed in Oracle Forms 4.5 (Web-enabled) and Java (J2EE, JRun, Oracle
: >DB). I now have a new application to develop but I don't know if it should
: >be done in Forms or Java. The new application has to be light and
: >accessible through a Web browser. I'm trying to assess the pros and cons of
: >both approaches but I know very little about Forms. Can anyone tell me what
: >are the TRUE ADVANTAGES AND DISADVANTAGES of Oracle Forms? Does anyone know
: >of any studies or architecture comparisons that might be helpful?
: >
: >Thank you,
: >Daniel
: My knowledge of both Java and Oracle is almost zero which is why I
: bought the "Oracle9i JDeveloper Handbook" published by Oracle Press.
: The section entitled JDeveloper: Past, Present, and Future says that
: Oracle has "seemingly decided to pursue JDeveloper as the primary
: development platform".
That is too bad. JDeveloper (the developer environment that is) is
apparently a java application. I have found it tedious to use. On a giga
hz machine I can type faster (in small spurts) than it seems able to
handle and the application goes wonky (i.e. hangs, or goes away for a
while). Also, it does not appear to handle such minor details, on windows,
as acting like a normal windows application, so for example, you can not
double click the left close box on a window to make the window close (a
small detail, but one that became built into my psyche since about fifteen
years ago on macintosh, and atari, and then on windows for many years).
Perhaps there is an option somewhere, but its quirks seem more related to
being java based more than anything else, same issues with keyboard short
cuts... )
It is useful to ask it to set up a project to see what options or
libraries it chooses, but then it's best to use anything else and compile
directly.
Oracle forms, (the developer environment that is) though not my favourite
development environment, is a perfectly respectable tool. It performed
almost all normal operations as fast as it ever needed to on a much slower
PC, and was generaly a useful tool for almost all stages of form
development.
Greg Forestieri
the desktop. Low cost development, quick time to market. You pay for
this with a bit more "ponderous" screen, but useful and relatively
easy to maintain. No conventional object model to speak of, but you
can be the judge of whether that is something worth worrying about.
Programatically forms 6i is similar to a VB 6.0, for those of you from
an MS background.
The key issue for us with Forms was deployment of the j-initiator. If
you have thousands of desktops to maintain it is problematic at best.
Better in such a case to throw a nice jsp app at the problem.
Lightweight and best of all almost any PC out of the box will run it.
I know some people will say you can auto-deploy the initiator, which
is true, but know your costs. How much does it cost to have someone
tracking down initiator issues?
jsp simplifies your life and from a programmer's point of view is a
nicer place to develop. Drawback of course is it's flexibility as it
is object oriented and therefore all of the pros and cons of OO come
into play.
Throwing java with swing, etc. at the problem merely gets you a little
bit less code and OO. If you "need" OO that badly maybe you need to
look at your system design and let IT make the decision for you. OO
can be the decision maker sometimes. But then you could throw the
lightweight jsp at it, in most cases. Perfectly possible that some
apps won't lend themselves well to jsp, but not too many, unless they
require heavy client abilities.
We use both here, Forms with Financials and jsp for all add-on
screens. It seems that Oracle's new ERP screens are mostly jsp (web
expense, other self-service screens) though I have a hard time
imagining that they could convert to all jsp given the size of the
current system.
Remember - jsp - OO, lightweight, simple to deploy; Forms a bit
heavier, and needs initiator, no OO. Java with swing, etc., middle of
the road, deployment on a par with Forms, more powerful client than
jsp.
Not trying to gore anyone's ox, just throwing out what's worked for us
in a very simple fashion.
Good luck
Greg
Frank
Yep - version 4.5 iirc. SUrely you don't use that, do you?
--
Regards, Frank van Bortel
Frank
Why does it have to be 'light'? Whatever that means...
Anyway, here are some considerations (a lot of which have been
addressed in previous posts):
- does your/the client company have a large programming staff,
familiar with Forms?
- do you need a lot of client side validation; field wise and
cross field wise?
- do you have the need for a rich GUI
If you answered yes to the above: stick with Forms.
If you answered no to the first:
- go Java
If you answered no to the first and last:
- you could try to get it done using HTML and Javascript,
but basically lot's of validation with HTML is a no-no;
I'd opt for Java (if only I knew Java...)
And last but not least:
- do you really need a light app, capable of running on PDA's,
mobile phones: HTML
Please remember that Java apps can put out HTML - a point often
overlooked in a decision process.
Hth - there are probably more considerations - oracle has a
nice pdf on metalink
nimonic
> apparently a java application. I have found it tedious to use. On a giga
> hz machine I can type faster (in small spurts) than it seems able to
> handle and the application goes wonky (i.e. hangs, or goes away for a
> while). Also, it does not appear to handle such minor details, on windows,
> as acting like a normal windows application, so for example, you can not
> double click the left close box on a window to make the window close (a
> small detail, but one that became built into my psyche since about fifteen
> years ago on macintosh, and atari, and then on windows for many years).
> Perhaps there is an option somewhere, but its quirks seem more related to
> being java based more than anything else, same issues with keyboard short
> cuts... )
>
>
> It is useful to ask it to set up a project to see what options or
> libraries it chooses, but then it's best to use anything else and compile
> directly.
>
> Oracle forms, (the developer environment that is) though not my favourite
> development environment, is a perfectly respectable tool. It performed
> almost all normal operations as fast as it ever needed to on a much slower
> PC, and was generaly a useful tool for almost all stages of form
> development.
Welcome to the world of Java. Regardless of what anyone says the
reality is that Java is very resource hungry and slow. We have 9iAS
running with 1.2G of ram and Oracle support have told us that we
should get more. I have no doubt the reason why it's so inefficient is
because of all the Java running in it.
I've seen all the laboratory bench marks that show Java just as fast
(and sometimes even faster) than C/C++. But as the English say, "The
proof is in the pudding".