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). 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]...
Previous Topic
