Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: choices regarding where to place code - in the database or middle tier

Re: choices regarding where to place code - in the database or middle tier

From: Andrew Carruthers <andrewcarruthers_at_cri-uk.com>
Date: Tue, 20 Jan 2004 19:06:44 -0000
Message-ID: <100qupghddk6cdf@corp.supernews.com>


I'm afraid your case is not proven.

Cache syncronisation has got to be one of the biggest problems middleware faces, most large organisations have data feeds directly into and out of the DBMS, this data needs to appear in the middleware cache at some point, so there is either a constant refresh cycle ocurring to renew data or the middleware cache become out of date pretty quickly, thus negating the preceived benefit. Why cache what is already cached in the DBMS? having 2 places to cache data is not the best architectural model I have ever seen implemented, in fact, it's one of the dumbest.

Logic should reside as close to the data as possible, in fact, data should be protected via API's to reduce the security risk, the only logic that should reside in the middle tier is the glue to piece together the API's to implement business rules - so long as there's more than one datastore involved, for a single datastore the logic should always reside with the data.

My second biggest problem with middleware is with vendors who put all their logic, referential integrity and validation into middleware as if their application is the only one of importance within an organisation and everyone will conform to their rules and methods of working. This approach works fine if the vendor is developing a stand-alone application but in the real world I have yet to see a stand alone application which has no connection to data feeds of one form or another. Implementing applications is more about integrating them into systems and this is where middleware orientated applications fail most often.

"Joe Weinstein" <joeNOSPAM_at_bea.com> wrote in message news:400C0C9E.40107_at_bea.com...
> Joe Lax wrote:
>
> > Hi -
> > Over the last several versions of Oracle, developers have been provided
with
> > a pretty revolutionary idea for a database product - namely the ability
to
> > write code that used to belong in the middle tier and store it in the
> > database. I'm referring here to the ability to write stored procedures
in
> > Java.
> >
> > Now of course, Microsoft with their SQL Server product is doing the same
> > thing. The next version of SQL Server will allow programmers to write
> > stored procedures in any of the .NET languages.
>
> Hi. My 2 cents: It's more of a reactionary idea rather than a
revolutionary one.
> The market growth and functionality growth since the early 90's has
been in the
> middle tier. The internet killed client-server, which was actually dead
when the
> DBMS vendors, even in benchmarking their products in the standard and
artificially
> DBMS-focussed TPC-C tests, began needing/using a real middle tier
transaction
> monitor/processor to get the maximum out of their DBMS. They continue to
do this
> today, and in the current top DBMS TPC-C record Oracle uses BEA's Tuxedo.
(My interest
> becomes apparent).
> Productivity during development requires the new tools, standards and
languages.
> However, that's not enough. If you really want Enterprise-class
applications
> with the performance to handle the unlimited user base that the internet
has
> provided us, you would be misled to be seduced back to a
DBMS-as-center-of-the-
> universe architecture. The DBMS vendors would like this, but the fact is
that
> the DBMS already has enough work on it's plate doing the core ACID
transactions.
> It operates in a crucial but expensive isolation model that you don't want
to
> waste on catalog browsers. Think of a restaurant, and the DBMS as the
chef.
> If you want to scale beyond the 6-stool beanery, the customers don't
interact
> as-a-rule directly with the chef. There is an efficient middle tier of
waitresses
> to concentrate 'chef-access' to a few high-volume channels. Furthermore,
for the
> percentage of frequently-requested items, there is an independent cache
which
> the chef fills asynchronously, and the waitresses tap this cache to serve
customers
> without ever involving the DBMS except to occasionally say "Gravy's out!".
> If you want to get to "Millions served" you would be wise to develop a
> powerful independent middle tier to do all it can to serve those millions,
and
> to control/optimise the load on, and output of the DBMS. Lastly, consider
the
> world where transactions involve more than one independent resource.
Customers
> nowadays tend to want the best of everything with one click of a mouse.
This is
> like a catered wedding where she wants the soup from "Chez Fancy", and the
canapes
> from "Chin's Canape Castle". You really need that caterer guy with the
funny
> accent as an independent middle tier to handle the logistics to make it
one
> transaction.
> Render unto Caeser (the DBMS) that (only) which is Caeser's. Sure, do
your
> heavy data grinding where the data is, in the DBMS. You build your saw
mills
> where the trees are, but: Let's say you're in Guam, and you want a box of
> toothpicks and a dining room table. It is silly to call the Great North
West Mill
> for logs, but it is also silly to call the Great North West Mill for the
toothpicks
> and table. Something smart and independent in the middle, like
www.walmart.com
> is where the money, efficiency and solution is.
>
> Joe Weinstein at BEA
>
> > I'm interested in looking at the increased choices developers now have
> > because of these new features in more depth ,developing some best
practices
> > on the subject, and possibly publishing an article on the topic.
> >
> > I personally am more experienced with SQL Server than with Oracle. I am
> > therefore looking for someone who has been involved with making these
> > choices in the Oracle environment who would like to collaborate with me
on
> > the subject.
> >
> > If you are interested, please contact me at joelax_at_dbdirections.com
> > Thank you
> > Joe Lax
>
Received on Tue Jan 20 2004 - 13:06:44 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US