|K. Ari Krupnikov||Feb 8, 2004 4:59 pm|
|David Megginson||Feb 8, 2004 5:42 pm|
|K. Ari Krupnikov||Feb 8, 2004 8:58 pm|
|Seairth Jacobs||Feb 9, 2004 5:46 am|
|Seairth Jacobs||Feb 9, 2004 5:51 am|
|David Megginson||Feb 9, 2004 6:22 am|
|Bullard, Claude L (Len)||Feb 9, 2004 7:07 am|
|Bullard, Claude L (Len)||Feb 9, 2004 7:44 am|
|David Megginson||Feb 9, 2004 8:19 am|
|Bullard, Claude L (Len)||Feb 9, 2004 8:27 am|
|K. Ari Krupnikov||Feb 9, 2004 11:35 am|
|K. Ari Krupnikov||Feb 9, 2004 1:01 pm|
|Bullard, Claude L (Len)||Feb 9, 2004 1:45 pm|
|K. Ari Krupnikov||Feb 9, 2004 2:43 pm|
|Bullard, Claude L (Len)||Feb 9, 2004 2:52 pm|
|Jim Ancona||Feb 9, 2004 3:04 pm|
|David Megginson||Feb 9, 2004 4:46 pm|
|Seairth Jacobs||Feb 9, 2004 6:25 pm|
|K. Ari Krupnikov||Feb 10, 2004 9:54 pm|
|K. Ari Krupnikov||Feb 10, 2004 10:14 pm|
|Pete Kirkham||Feb 11, 2004 2:27 am|
|Julian Reschke||Feb 11, 2004 2:54 am|
|Klotz, Leigh||Feb 11, 2004 10:18 am|
|Robin Berjon||Feb 11, 2004 10:21 am|
|Chiusano Joseph||Feb 26, 2004 6:19 am|
|Michael Champion||Feb 26, 2004 7:29 am|
|Bullard, Claude L (Len)||Feb 26, 2004 7:51 am|
|Subject:||RE: [xml-dev] A question about REST and transaction isolation|
|From:||Bullard, Claude L (Len) (clbu...@ingr.com)|
|Date:||Feb 9, 2004 7:07:28 am|
What about an approach where the business logic middleware is distributed to the client hardware such that the shared server hardware doesn't bottleneck? It turns out that scaling up for concurrent clients without operating server farms is somewhat dicey for certain relational databases. For example, robust locking is not as good as advertised and once again, customers are buying based on advertisements, not experience.
Thick vs thin isn't the issue. One can have a thin client and still put the middleware on the client host. Would that help?
Client does presentation, server does business logic. Is that not in line with REST?
This approach would work for, say, a movie database, where the user might check out a full movie description to change the director's name, then check the entire description in again. It might not work so well for, say, a geographical database, where a modification to a shoreline may also require corrections to landuse data, roads and railroads, and so on, in no easily-predictable way.
It is entirely possibly that your project is one in the second category, but I wouldn't give up on the simpler approach until it were proven inadequate. Stupid-and-easy usually wins: moving 50K of XML each way once can be much more efficient than many 100 byte transactions.
It's not about reducing redundant traffic, it's about reducing redundant logic. One node should know how to do a process, be the final authority and bear the ultimate responsibility for that process.