Re: Re(8): "The First Rule of Distributed Objects is..."

[exussum0]

feh, i thought i replied once. Went back, and here we are :)

I think that's actually a different deal. Optimizing and profiling are about improving the efficiency of the most important pieces of code, reducing the amount of resources needed. Here we're just talking about allocating resources.

Ah, but allocation of resources in terms of this isn't he simple, "I need 5mb more ram" ordeal. It's about CPU resources. It's about routing requests to more capable systems.

Good load-balancers do solve the problem of isolating specific URLs to run on specific groups of machines, and I wouldn't consider load-balancers or mod_proxy any harder to deal with than J2EE deployment and configuration stuff.

Absolutely right, but don't think of it in terms of stateless page requests either. Think about a cohesive application, like AOL. Client makes lots of requests, and you get certain data. So you'd prolly load balance to a certain machine. But that's an arguement for or against stateless connections.

Truth of the matter is, segmentation on a load balancer may work really well, but a config option which tells an aplication, "the preference changing utility pool is there" and "the forum service pool is here", is a one time persistant thing. With url evaluation, the url has to re-evaluate every time and redirect your traffic. It has a less .. general feeling for me. If it was done on the back end to a connected pool, url gets evaluated once, a message is sent to a ready mady pool, waiting for requests.

But you are right on with J2EE and mod_proxy in ease of configuration. It's the performance and ability to be quite modular with things without frontal impact. What if you had a front page that hits many resources. You can't split that up w/ mod proxy easily, but your calls can hit multiple pools. Also, it's not about J2EE alone... it's about RPC, and SOAP, and XML-RPC.. it's about distributed objects :)

Hmmm... Java was created for programming toasters and refrigerators. It's a good general-purpose language, but the whole business slant is just marketing.

Maybe, maybe not. Let's take ASM. It's a great system language. Same with C. The problem with C and ASM is, that you can't create stuff for easy reuse. Same with Fortran. Great for math, shitty for system programming. Java.. it's really shitty at system programming.. but this isn't an argument in elimination of types. Java has a good way of describing by architecting, business oriented tasks and acting upon that architecture. It's strong on patterns and reuse.

[perrin]

What if you had a front page that hits many resources. You can't split that up w/ mod proxy easily, but your calls can hit multiple pools. Also, it's not about J2EE alone... it's about RPC, and SOAP, and XML-RPC.. it's about distributed objects :)

I think this is just our fundamental disagreement: I believe that splitting up parts of a single request will work against you in terms of performance and scalability. The only good reason I can see to segment things is in order to isolate bad parts that you intend to leave under-powered and slow. Splitting up a single request doesn't work, since all the parts have to finish before the response can be sent, i.e. the response can only be as fast as the slowest part.

As far as SOAP/XML-RPC is concerned, they can be useful for interop with systems in other languages but they are not an efficient way to distribute load within a single system. They have serious overhead, with all the extra XML creating/parsing and network traffic.