« What's in a name? | Main | SpanDotted »

Distribution: confusion heaped on confusion

Damn, I love XML over HTTP.

There's a twisty maze of conversation around an entry from Dan Creswell that was picked up by Dale Asberry. Dale:

I think the discussion is pointing out some very big reasons why Jini isn't taking off: people don't get distributed computing. They just don't get it.

Dale again:

Never claimed that there were any magic bullets. Only that distributed application design isn't really as hard as most people think [..].

So it's not that hard, but people don't get it. Ok, I guess they're not mutually inconsistent statements. But they don't explain much; it's not like Jini is the only distributed technology at hand. I would agree that distributed computing doesn't have to be as hard as people think, given the right technology. But I think people think right - with industry standard frameworks (DCOM, CORBA, J2EE, WS, CUPS) distributed computing is hard.

Todd Blanchard is close:

Probably the root cause of the unfortunate disconnect you bemoan is the modeling of services as objects. Objects have state (ivars). Services, ideally, don't. Objects without state are just bundles of functions - which is a much better model for a service than a class. I rather suspect that this is the source of much bad design - services are NOT best modeled as objects.

Services do have state, but they don't expose it, they accept it. Which Dale had pointed out:

This means to me that any state needed by a service will be included in the request either directly by including it as a request parameter, indirectly through a parameter containing a global reference, or implicitly through some asynchronous mechanism.

But then:

My practical solution to this is to perform remote method calls, or groups of calls, within a Jini transaction that also contains any and all JavaSpace entries representing service state. This buys me consistency in state for all distributed participants AND fault-tolerant fail-over for when a service becomes unavailable.

Aka a transactional blackboard. Which is maybe about as well as you can do for object invocations. In all this discussion, it seems objects are an artefact of Java, not the nature of distribution. Nonetheless, if we were doing Java middleware over tommorrow, Jini/JXTA would be where to start, not J2EE.

You see, when it comes to distributed computing, I think all object oriention does is obscure matters. We end up talking about transactions, parameters, references, interfaces, when we should be talking about messages, state, names, protocols. And if that doesn't fit with object thinking, so much the worse for it - distribution and decentralization is becoming the norm.

But object wonks might object because that separates behaviour from data - bad, bad, bad. Which is what Todd is talking about when he says objects are not a good model for services. I've yet to me a J2EE advocate who didn't see DTOs and the like as essentially latency optimization/workaround instead of proper network design (DTOs being degenerate messages) [utter bunk, sorry about that...]. I even see object advocates today insinuating that a service layer is some kind of dirty hack.

I haven't even talked about how you're supposed to manage or integrate the arbitrary interface signatures an object model allows. Or versioning. And I'm not going to either.

I don't know. I just wouldn't start with an object model and then figure out how to negotiate their consistent state once I'd flung them around the network. I'd look for an application protocol that fitted my needs. The closest I'd get to an object model is a generative or associative model (a la JavaSpaces, or content based routers). But for that I don't need objects in the design - I need data tuples.

[calexico: whipping the horse's eyes]


April 22, 2004 01:11 AM

Comments

Bo
(April 22, 2004 03:55 AM #)

Haha, Bill, you've met me and I'm a J2EE advocate. I've been saying it for years: DTOs are NOT objects they are documents. Not sure what you mean by integrating arbitrary interfaces... I get the feeling this is some more of your RDF prejudice sneaking in. As for versioning it's not that hard a problem to solve. Versioning at the internet-application level is hard; versioning at the enteprrise-app level is doable.

Bill de hra
(April 22, 2004 11:00 AM #)

"Not sure what you mean by integrating arbitrary interfaces... I get the feeling this is some more of your RDF prejudice sneaking in."

Nah, that's REST prejudice. It's easier (I think) to network a 100 objects with a single interface that 10 objects with 10 interfaces.

Jon Hanna
(April 22, 2004 05:41 PM #)

Well PUT is RESTful and it affects the state of the service. What one doesn't have in this case is *shared* state between the client and server.

I don't like the port 80 t-shirt, I don't think 80 should be considered a hard-coded value :)
I do like http://www.cafeshops.com/rest.2592837 though.

Bill de hra
(April 22, 2004 10:17 PM #)

"I don't like the port 80 t-shirt, I don't think 80 should be considered a hard-coded value :)"

ROTFL!

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1253

Listed below are links to weblogs that reference Distribution: confusion heaped on confusion:

» Objects and Services - Nouns and Verbs from Rishon Rishon
Bill de hra talks about the use of Objects and Services in distributed computing. He comes down clearly in favor of services, and against objects: You see, when it comes to distributed computing, I think all object oriention does is... [Read More]

Tracked on April 22, 2004 12:49 PM