[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: A question about REST and transaction isolation

• To: "'ari@c...'" <ari@c...>, xml-dev@l...
• Subject: RE: A question about REST and transaction isolation
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Mon, 9 Feb 2004 09:07:28 -0600

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?

len

From: ari@c... [mailto:ari@c...]

You are talking about a very thick client here. It's not how much
state there is this application (not much), it's how much logic there
is (a lot). The server already knows how to do this logic. I don't
want to duplicate the logic on the client. I want to use a browser,
and I don't want a ton of JavaScript to handle the state
client-side. A full-blown Java client is a future possibility, but
again, I'd like to keep the business logic in it to a minimum. I
definitively don't want three separate codebases for business logic,
one on the server one in JavaScript (possibly in multiple versions for
different browsers) and one in a Java client.

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.

• Prev by Date: Re: A question about REST and transaction isolation
• Next by Date: Re: A question about REST and transaction isolation
• Previous by thread: A question about REST and transaction isolation
• Next by thread: RE: A question about REST and transaction isolation
• Index(es):
  • Date
  • Thread