Re: Green field architecture.

From: joel garry <joel-garry_at_home.com>
Date: Tue, 12 Jan 2010 09:22:47 -0800 (PST)
Message-ID: <e11685d3-f315-4de8-bee6-7fece5be78e2_at_34g2000yqp.googlegroups.com>

On Jan 12, 7:27 am, "Ralph.in..._at_googlemail.com" <ralph.in..._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

Personally, I think this is the reason things like apex work so much better than apps like MOS.

Theoretically, you could make things work better by offloading to an apps server, but the practical reality is most solutions are architected with the business logic too far away from the db, flopping around like fish dumped on a boat deck. Unless you are really scaling up huge, you are probably doing the right thing - run out of horsepower, just buy a bigger horse.

The downsides tend to revolve around updating code (ie, cursor and library invalidations) and the difficulty of expressing some business rules that close to the db. The former is minor and easily controlled with general source control procedures, and the latter becomes less of a problem as your developers become more experienced with the apps idiosyncracies and analysts refine the rules. It's nearly impossible to avoid having a situation at some point where "we need to get into production and fix the problem now!" no matter what you do.

There may also be issues on the tomcat side, I wouldn't know about that - but I've seen problems with developers being too cute or too macho at all layers of code. Give developers source, they will modify.

jg

--
_at_home.com is bogus.
“The quiet majesty of human violence” - John Oliver

Received on Tue Jan 12 2010 - 11:22:47 CST