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 middletier

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

From: Joe Weinstein <joeNOSPAM_at_bea.com>
Date: Tue, 20 Jan 2004 16:28:05 -0800
Message-ID: <400DC795.7070804@bea.com>

Daniel Morgan wrote:

> Joe Weinstein wrote:
>

>> However, that dbms-specific level should be as narrow and 
>> controllable/switchable
>> as possible. J2EE standards help there.
>> Joe
>>
>>> Just my 2 cents
>>>
>>> Daniel

>
>
> I appreciate your opinion and your honesty that your perspective comes
> from selling that middle tier but I completely disagree.

cool.

> The 'lets push more bytes down the pipe and across all those routers'
> thinking is not going to lead to performance. You may be scalable but
> performance will suffer. And you will be no more scalable than a thinner
> client.

Well, I actually want thin clients, but from DBMS perspective, the application server is not a thin client. I do believe that no bytes should leave the DBMS that aren't needed at the end client, but once they've left, they should be retained and milked/reused for all they are worth, and this can be intelligently and profitably done. Performance and scalability follow, according to the nonvolatility  of the data, the relative proximity of the clients to the middle tier as opposed to their distance to the DBMS, and the relaitve lightness of the communication protocol between client and middle tier as opposed to the protocol between DBMS and any of it's clients.

> Render under to database everything you can do in the database and let
> the middle tier do what it does best ... fail-over, load levelling, and
> serving up the front-end.

Sure, and protecting the DBMS from uncontrolled ad-hoc connections and mindless repeat queries, and acting as a transaction monitor/controller to get the best performance out of the DBMS, etc. Otherwise you should explain why Oracle chooses to use BEA as middleware when it simply tries to demonstrate it's own performance potential in TPC-C benchmarks.

> Try tuning all that rotten SQL coming from those fat front-ends sometime
> and you will understand why those here that have experience with
> PeopleSoft, SAP, Baan, and Siebel are remarkably unhappy.

Well, sure. I have done so, in fact. The stupidities are legion. Many of these applications are ridiculous 'ports' of 70's era COBOL/ISAM applications to 'client-server' by simply swapping in row-by-row cursor fetches to the DBMS instead of the previous ISAM call. Intelligent client-server architecture (as I've said) puts the sawmills where the trees are, not in the client. However, client-server is dead, at least to the extent that now everyone in the company or the internet may want the info in the DBMS(s), and transactions now involve serveral DBMSes and other resources. Thats where the middle tier makes it's contribution, and depending on what's done, and what degree of concurrency, isolation, atomicity etc that particular data requires, it can now find a profitable home in either the DBMS or the middle tier, at least as a cache. As an example from the Baan suite, they really did architect their application so it queried the DBMS for a list of the countries in Europe hundreds of times a day for each user. A current state-of-the-art application would have a generic browser as one of it's clients, and in such a case, the middle tier is ideal for caching the list of the countries in Europe, and making is available to all clients, and given the political instability in Europe, maybe refreshing it's list once daily from the DBMS? It saves a lot of DBMS cycles... IMHO...
Joe Received on Tue Jan 20 2004 - 18:28:05 CST

Original text of this message

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