Re: choices regarding where to place code - in the database or middle tier
Date: Tue, 20 Jan 2004 11:57:02 -0800
Message-ID: <400D880E.4000709_at_bea.com>
Andrew Carruthers wrote:
> I'm afraid your case is not proven.
Hi! Thanks. 'Proven' needs a definition, but if there exist many large enterprises with worldwide distributed applications in successful service, then they at least stand as support for the case...
> 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.
The virtue of caching data is as described, making it available in a lighter, faster way than if the DBMS must be consulted. The refresh of cache benefits from it's being not necessarily synchronous with user requests. This architecture allows for varying transactional isolation as a user interaction wends its way unpredictably from a browse mode to a possible binding transaction. You want to limit the strict costly centralized ACID transaction part to the final DBMS-involved part. The speed benefit of having customers all over the globe perusing a locally cached catalog is worth the occasional retry necessary when they commit a purchase that fails because the DBMS changed relevantly since the cache was updated.
Cache synchronization is an issue, but so is DBMS synchronization. One is more costly than the other, based on the guarantees it is designed to provide. The point is that the user experience defines a 'session/transaction' that lends itself to a varying level of concurrency-vs-isolation, and intelligent distributed caches provide the desired spectrum.
> Logic should reside as close to the data as possible,
I agree, but some of this data can be cached, with logic in/around a fast intelligent cache that resides between the millions of users and the very busy DBMS(s).
> in fact, data should
> be protected via API's to reduce the security risk,
Always true...
> 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.
Unless/until one sees the value of cached data. Not raw cached data, but an intelligent middle tier.
> 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.
I agree. Simple non-volatile referential integrity constraints should certainly be in the DBMS. It is a mistake to treat the DBMS as a dumb generically replaceable file system. However, this criticism of yours can also be applied to the DBMS-biassed, who think that all the logic needs to be in the DBMS, and that everyone must conform to DBMS ways 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.
Interesting! I see mor often that middleware exists to integrate applications into unified internet-wide access, and integrating multiple standalone DBMSes. Integration is hard. This is where middleware succeeds as well as fails (GIGO). However, I wouldn't put the job of integration of applications to {the/one of the} DBMS(s). Joe
>
>
> "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
>
[Quoted] [Quoted] >>>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. >>> [Quoted] >>>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. >>> [Quoted] >>>If you are interested, please contact me at joelax_at_dbdirections.com >>>Thank you >>>Joe Lax >>
>
>
Received on Tue Jan 20 2004 - 20:57:02 CET