This post originated from an RSS feed registered with Java Buzz
by Jason Carreira.
Original Post: Re: Do you need Remote Objects?
Feed Title: Jason Carreira
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Personal Aggrandizement
I don't WANT remote object lookup. If I start thinking about accessing remote objects, I've already failed :-)
This strikes me. It goes totally against the "distributed computing" trend we've seen on the latest years, which basically boils down to a lot of incompetent people using EJBs either because they're standard or because they think that, some day in the future, their application will need to scale to a humungous number of concurrent transactions and they'll need to scale to something like a Google supercluster. Did I mentioned they usually do uninteresting intranet applications? Oh, no, I didn't. Yeah, I've heard this kinda talk when designing an intranet app - and it was no marketing dweeb talking to me - it was a senior developer/architect, with a straight face, looking at me suspiciously like if I was asking him to go back to the Clipper/xBase era.
Really, how many systems do you see everyday that need remote objects? Systems that need to scale to the multi-gigabyte database, to the hundreds of concurrent users? How much simplicity are you throwing away just because your crystal ball told you that you'll need to scale? I'm not talking about sacrificing manageability or mantainability here, as they are, indeed, important to most systems that's going to be put into production out there, because you actually need them from day one. I'm talking about choosing the extreme scalability path 'just because'. 'Just because' is definitely no excuse for anything on software development, unless you're doing an experiment, trying new things out, looking for a cool solution to a problem or something along these lines.
What Jason was also saying is that, for his needs, local/remote transparency is highly desired. I think that's what he meant by "If I start thinking about accessing remote objects, I've already failed".
Nope... I really meant that I don't want remote distributable objects. Actually, I think local/remote transparency is a falacy that falls into the "Leaky Abstractions" category. Scaling doesn't have anything to do with whether your objects are remote. How often do you really have one web request cross JVM boundaries? The whole Servlet-tier and Business Object tier topography has been pretty well discredited. It doesn't scale to have to make remote calls. The only place I can really see calling another JVM as worthwhile is in using a cluster like Cameron's.
Think about where we really have a bottleneck... the database. Pessimistic concurrency doesn't scale, so we push concurrency down to the database. This means our requests are handled front-to-back by the same process and different processes finally meet up at the database, which is the final arbiter. I do a lot of asynchronous batch processing, and we have a message handled the same way, all in one local process. Multi-JVM horizontal scaling is handled by the load-balancer, either a front-end hardware load balancer for Web requests or JMS handing our messages to MDBs as they become available. Where's the need for remote objects?
Remember Scott Ambler's first rule of distributing objects: Don't.
Previous Topic
