> Given that the research and implementation of this project has taken> over a year already, with the purchase of *5* extra computers for an> application not 5% as large (or complex, or accessed) we seem to be> heading in a very dangerous direction.

You started going in a very dangerous direction as soon as your
management bought into the "J2EE is scalable" bandwagon.
Thereby falling into the fatal mistake of confusing "scalable"
with "performant".
Whatever you do, stay away from EJBs for db access. The rest of
j2ee is not that bad, it's the database access through "beans"
that kills the whole thing.

> I would say that the need for the server to generate and serve the> entire application is what is "broken." We need to split the http> serving and the data access.

That has nothing to do with your SQL, has it? So why is your
management so worried about the scalability of the database?
Ah yes, I'm thinking here: your http is coming off the pl/sql,
isn't it? So, your database is doing the job of a database
service, an application service and part http service.
Yup, that would be the problem: hard (read: expensive) to scale
all that from one box. Am I correct?

> the application *or* a java application could initialize the object and> display the application using "print."

Assuming I understood your dillema, this makes eminent sense.

> I suggest the benefits of this are:> Very simple Java component - that can be deployed on another server to> handle the web serving of the application.

Yes, very much so. You're going about it the right way.

> Does this make anything clearer? As you probably can tell I'm> grasping...

As far as I can see you're going into it in a most sensible
fashion.

> > Assume the server is at maximum capacity, what would Oracle say about> our dilema? Buy a bigger server? Buy Oralce-AS? Both options would> appear to be out of the quetsion for our company.

Get an open-source app server that is j2ee compatible and a free http
server, start a model/pilot system using these and a test database.
Stay away from ejbs for data access. Above all, resist the temptation
of making it too modular and "scalable": there is a price to pay for
that and it is performance on smaller systems.

KEEP IT SIMPLE is the old chestnut I suspect applies in your case.
There is no need to develop an entire portable framework: you are
not fundamentally interested in portability, you are interested in
TCO and performance.

I'd basically create a number of pl/sql packages that access/manipulate
the basic data needed by your application (before it becomes http),
interfacing to Java through simple basic data access objects (which
map to pl/sql objects quite nicely via the magic of jdbc).
Then let the Java mob partition and split work into as many
components as the business requires: each can then run anywhere with
access to an app server and a db connection. Your db is now free of
the complexity of mapping the data to http via business rules, something
it is not really designed to do.

So, you gain spare performance back on your db server side. Which Java will
gobble quite nicely but at least you can plonk additional cheap boxes for
that - up to a limit.

Or so the theory goes. Famous last words and all that, without really
knowing the details of your particular situation. Therefore, take
the proverbial amount of salt with what I said and HTH.