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

From: Andrew Carruthers (andrewcarruthers_at_cri-uk.com)
Date: 01/20/04

  • Next message: HK: "Re: choices regarding where to place code - in the database or middle tier" 
    Date: Tue, 20 Jan 2004 19:06:44 -0000

    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@bea.com> wrote in message
    news:400C0C9E.40107@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@dbdirections.com
    > > Thank you
    > > Joe Lax
    >

  • Next message: HK: "Re: choices regarding where to place code - in the database or middle tier"

    Relevant Pages

    • Re: choices regarding where to place code - in the database or middle tier
      ... enterprises with worldwide distributed applications in successful service, ... > DBMS, this data needs to appear in the middleware cache at some point, so ... Why cache what is already cached in the DBMS? ...
      (comp.lang.java.databases)
    • Re: choices regarding where to place code - in the database or middle tier
      ... enterprises with worldwide distributed applications in successful service, ... > DBMS, this data needs to appear in the middleware cache at some point, so ... Why cache what is already cached in the DBMS? ...
      (comp.lang.java.programmer)
    • Re: choices regarding where to place code - in the database or middle tier
      ... Cache syncronisation has got to be one of the biggest problems middleware ... Why cache what is already cached in the DBMS? ... > powerful independent middle tier to do all it can to serve those millions, ...
      (comp.lang.java.programmer)
    • Re: MemoryMappedFile
      ... Hier läuft so eine Art Middleware und der Client ruft Funktionen auf, deren Ergebnisse automatisch vom Server, der das eventuell nochmal weiterleitet, kommen. ... Middleware cachen und gegebenenfalls eben aus dem Cache beantworten. ... "Parmesan und Partisan, wo sind sie geblieben? ...
      (de.comp.lang.delphi.misc)
    • Re: more dimensional method like a query...
      ... > Ans i because of database and middleware i need to cache the stock.... ... Application developers should not generally be writing caches. ...
      (comp.object)