Re: Oracle Object Types and Java (migrating from mod_plsql)

Thanatos apparently said,on my timestamp of 21/02/2005 10:09 AM:

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

-- 
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k_at_yahoo.com.au.nospam