Re: Green field architecture.

From: Tim X <timx_at_nospam.dev.null>
Date: Wed, 13 Jan 2010 09:49:38 +1100
Message-ID: <87r5pv0whp.fsf_at_lion.rapttech.com.au>

"Ralph.in.NZ_at_googlemail.com" <ralph.in.nz_at_googlemail.com> writes:

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

I recently completed an application with a similar architecture.

Originally, the plan was to have the whole lot handled in Oracle, using either java or plsql for the web front-end. However, half-way through development, a decision was made to do the front-end web interface via Java inside a tomcat container running on a separate web cluster. I argued strongly against doing this and argued that if Java was to be used, why not do it using oracle's java support. I lost the argument.

I had many objections, not least of which was that putting java inside tomcat just seemed to be adding a new point of failure with little other advantage.

All interaction via the web interface to the database is done via pl/sql functions and procedures. Nearly all the business logic is done within the database. This is mainly because the web interface is only a small part of the application. The app also interfaces with other Oracle databases, uses Oracle streams and communicates with other apps via XML. As all these other interfaces existed, which also needed to use much the same business rules, it made sense to put as much of the business logic in the databse as I was keen to have only one representation of the business logic to avoid maintenance issues in the future.

The application whent iive in mid september. Around 90% of the go-live issues all turned out to be due to issues with the web front-end. The other 10% were minor issues that required small refinements in the business rules and some data migration issues. The Oracle side of the equation worked extremely well.

One of the main issues the web front-end encountered was due to an issue with the Java Spring framework. This was partially due to the way it was used and partially due to a bug in the java end failing to close ref-cursors correctly, which resulted in 'out of cursors' errors.

IMO one of the main benefits of having as many of the business rulles as makes sense in the database is that you can then have just one single implementation of the business rules that works for everything, plus the web developers don't need to know or udnerstand much about them. They have a well defined interface they work with and that interface can be used by any component, regardless of implementation language etc.

Of course, there are times when implementing the business rules in the applicaiton front-end tier makes sense. I don't agree with hard and fast rules that say it should always be in the database or should always been in the app/java tier. such rules are dangerous. The decision as to where the business rules live should be based on analysis and should be easily justified, though my personal preference tends to lean towards putting rules in the database.

I don't believe the portability or avoiding lock-in arguments to justify putting business rules into the application tier are very sound. Applications that do this tend to reduce database integration to the lowest possible denominator. These are usually the types of apps where the web developers complain about Oracle being a slow database - they dumb things down and do things in such a way that Oracle has no opportunity to work efficiently and then blame it on the database. If support of multiple DB backends is required, I would tend to put another database abstraction layer into the architecture and implement specialised db modules for each supported db that enables the applicaiton to take advantage of the strengths of each supported db rather than dumb everything down to the basic CRUD style interaction.

Oracle has been adding pl/sql packages, such as rule_mamager, to make definition and management of business rules easier within the database. While some of these newer features were not quite mature enough in 10g, I suspect they have gotten better in 11g and may provide functionality that could be useful. At any rate, I would recommend looking into some of these advanced features as they can make definition and maintenance of business rules easier.

Tim

-- 
tcross (at) rapttech dot com dot au

Received on Tue Jan 12 2010 - 16:49:38 CST