Re: Green field architecture.
From: Frank van Bortel <frank.van.bortel_at_gmail.com>
Date: Wed, 13 Jan 2010 10:28:16 +0100
Message-ID: <27d6d$4b4d9231$524ba3af$29815_at_cache2.tilbu1.nb.home.nl>
Ralph.in.NZ_at_googlemail.com wrote:
> Hi,
>
> I am involved in designing the architecture for a green field web
> application. Oracle 11g on the back end, tomcat at the front. No fully
> fledged apps server in the middle tier. I can't see why the business
> logic can't be handled by pl/sql in the database, with the
> functionality exposed to tomcat via stored procedures. It makes sense
> to me to do the business logic in the database (very close to the
> data) rather than to drag data back and forth between the apps server
> and the database. I have investigated all the custom context stuff for
> dealing with these lightweight database users comming in via
> connection pools and it all seems to work a treat.
>
> The Oracle database is so rich in functionality for using web
> services, messaging etc that I am really struggling to see the point
> of a J2EE Apps server. Of course portability is one argument, though
> in my experiance just because your app is completely written in java,
> doesn't make it portable. Plus we will be really trying to take
> advantage of oracle specifc functionality, so wont be wanting to port
> from there anyway.
>
> Before I went too much further I thought I would run this idea past
> those on this group, to see if I have missed any obvious problems with
> this architecture.
>
> Any comments gratefully recieved.
>
> Ralph
Date: Wed, 13 Jan 2010 10:28:16 +0100
Message-ID: <27d6d$4b4d9231$524ba3af$29815_at_cache2.tilbu1.nb.home.nl>
Ralph.in.NZ_at_googlemail.com wrote:
> Hi,
>
> I am involved in designing the architecture for a green field web
> application. Oracle 11g on the back end, tomcat at the front. No fully
> fledged apps server in the middle tier. I can't see why the business
> logic can't be handled by pl/sql in the database, with the
> functionality exposed to tomcat via stored procedures. It makes sense
> to me to do the business logic in the database (very close to the
> data) rather than to drag data back and forth between the apps server
> and the database. I have investigated all the custom context stuff for
> dealing with these lightweight database users comming in via
> connection pools and it all seems to work a treat.
>
> The Oracle database is so rich in functionality for using web
> services, messaging etc that I am really struggling to see the point
> of a J2EE Apps server. Of course portability is one argument, though
> in my experiance just because your app is completely written in java,
> doesn't make it portable. Plus we will be really trying to take
> advantage of oracle specifc functionality, so wont be wanting to port
> from there anyway.
>
> Before I went too much further I thought I would run this idea past
> those on this group, to see if I have missed any obvious problems with
> this architecture.
>
> Any comments gratefully recieved.
>
> Ralph
You are absolutely right: all this application server mumbo-jumbo is really just another way of getting more hardware to do the job, and disguising the fact nobody give a penny about writing efficient, scalable code anymore.
I have see many projects with web interfaces that in fact did not need java at all.
I do acknowledge the fact, your GUI may be much richer with java than with flat html - but that is eye-candy. Just look at the disturbance MOS makes. If you really, really need full GUI, go back to Forms.
If you want a fast, lean application, stick to pl/sql, possibly java, but all in the database, and learn CSS!
I wish you strength in your battles. Received on Wed Jan 13 2010 - 03:28:16 CST