Discussions

News: On Corba, DCOM, ICE, and distributed objects in general

  1. Mark Baker posted a reference to "On Corba, DCOM, ICE, and distributed objects in general," which highlights a lot of the issues around distributed objects, focusing on CORBA but also applicable to Java EE objects. His salient point is whether distributed objects are the right metaphor in the first place. Discussing the failures of CORBA (and dismissing EJB 2.x, saying it was "clearly wrong"), among other criticisms he has this point about specifications created by standards bodies first:
    CORBA came with too many extra complex services, some of which clearly never worked. There are other standards bodies which appear to be repeating this antipattern. We need implementation-first standards with test suites released simultaneously with the specifications, otherwise the first implementations come out without being tested properly, and the specification itself may prove to have untestable parts to it.
    He then points out flaws in the competing technology of the time: DCOM, pointing out that the IDL to C++ mapping "sucks," extra unneeded services (also a flaw in CORBA and EJB), lack of a centralised repository, and "atrocious error handling." His summary:
    Out there in the intra-organisation land, you either have REST, relatively simple SOAP (no WSRF, WS-Eventing, etc), or something custom, invariably HTTP based or at least tunneling over port 8080. What do we have behind the firewall? A complete mess. There's the DCE based win16 app for filling in travel expenses (trams- enemy of EU employees!), there's all the SAP based stuff you have to deal with when you are a project manager, the apps that tell you your budget and how much there is left. Then there's the various web sites to do things that somehow talk behind their back to each other. And there is stuff like Jabber, which, whatever it uses, doesn't accept ::CreateFile(8) as a valid password, even though the rest of the organisation does. Its a mess. But does that matter? And if it does, what would you standardise on, if not CORBA? You wouldn't go single platform, so RMI and WCF are out, despite the benefits that single platformness gives you. That leaves SOAP, REST on HTTP, WSRF/N/Eventing, ICE, maybe XMPP. One issue is whether distributed objects are the right metaphor for distributed computing. CORBA, DCOM, ICE, RMI, .NET remoting and WSRF all implement the idea that you are talking to instances of stateful things at the end, with operations to read/write state, and verbs/actions/method calls to tell the remote thing to do something. These protocols invariably come up against the object lifetime problem, the challenge of cleaning up instances when callers go away, without flooding the network with too much traffic to indicate client health. They also have the dealing with change problem, in which both ends of the system (assuming callbacks) have to handle the possibility that either end of the system may be suddenly replaced by an upgraded version, possibly with a changed interface, possibly with changed semantics. This is hard to deal with. REST handles it best by freezing the set of verbs to a low number, only allowing one way links, but at a price, the price of no easy mapping between REST resources and native classes, no two-way links and (currently) not very easy APIs. The question is, when will the Enterpriseys notice that this is the only thing that has been shown to work.
    His article doesn't really address Java specifically (except to dismiss EJB 2.x in the second paragraph) but almost every point after that maps across very well, in a technology environment where specifications tend to be generated before implementations and where cross-compatibility tends to be bolted on after implementation. What do you think of it? What's the right solution?

    Threaded Messages (26)

  2. Dan Creswell made an excellent reply in Steve on CORBA etc:
    The only thing that has been shown to work? Presumably that's "works from a technical perspective"? What's more important is the "at a price" comment. If you are prepared to pay the price, it "works" for you, if you aren't prepared to pay that price it doesn't "work" for you. What "works" is dictated by your viewpoint and your requirements and what penalties you are happy to pay and we don't all agree on those. If the enterprisey folk don't like that price, ain't no way they will ever sign up to REST and that doesn't make them blind or stupid, it means they're different and they have different needs and prefer to pay different penalties. And in case you're wondering, I don't agree with Steve's assertion re: best solution for versioning either precisely because I'm willing to accept a different set of tradeoffs.
  3. I don't know what 'the best' distributed computing metaphor/architecture is. I can only point to things that dont work, and that is what I tried to do. Anything that tries to model stateful objects over long distances has so far failed, with versioning, chattiness, caching, interoperability and firewalls being problems that crop up. They work well in small, enclosed clusters where you can deploy the entire system simultaneousy; I happily use RMI in this situation. But over long distances, the distributed-objects design, *as implemented in things like CORBA, DCOM and RMI* have encountered problems. Mich says that ICE solves a lot of these problems; I don't know if that is true or not, but it is worth investigating if you want the Dist Object pattern without the known flaws of todays implementations. What is important is that I dont see today's SOAP APIs/WS-* specs addressing the problem. You often see hard-coded URLs in addresses, which is something the first RPC stacks used to warn against. Then you see some Java to WSDL to Java mapping going on that tries to make SOAP look like RMI. Finally you get stuff like WS-Transfer and WSRF that try and make endpoints look stateful, and, via WS-Eventing and WS-Notification, add callbacks, which means both ends start storing up assumptions about each other. I am not an advocate of REST either; REST-over-HTTP has so many flaws, starting with HTTP itself. Yet the choice of restricting everything to a few verbs, with a model of 'remote puts and gets' appears to scale nicely, and be fairly resilient to change. The question Dan is asking is "are the limitations of REST an acceptable price to pay", for which I don't have the answer, not yet :) -Steve
  4. I don't know what 'the best' distributed computing metaphor/architecture is. I can only point to things that dont work, and that is what I tried to do.

    ...... The question Dan is asking is "are the limitations of REST an acceptable price to pay", for which I don't have the answer, not yet :)

    -Steve
    Indeed! And in case it wasn't clear, I did enjoy your post! I have used REST some and in certain cases find it works well whilst for others it just seems horrid. Thus far, I haven't figured out what the patterns for good/bad are. Just as a side-note, I'd point out that most of the distributed object technologies use interfaces to define API's but then hook them to specific stateful implementations via stubs as you've discussed. However, if you do define interfaces, you don't have to generate stubs and you don't have to relate back to a specific object with state. That is the power of the interface - implementation can vary. Of course, in most cases (but not all), the implementation follows the usual "tried and tested/failed" CORBA style model. And of course, methods on an interface needn't be granular but, even if they are, if you vary implementation beyond simple stubs you needn't be doing remote network calls all the time.
  5. I once read somewhere someone complaining about the distributed computing paradigm and advocating the use of protocols only. That way the services were supposed to last longer (examples like e-mail and the web). Unfortunately, many ill-designed protocols around are less extensible than changing interfaces (which, in fact, are the same thing if there's proper use of abstraction and remoting technologies), and that makes this point invalid. Even REST can be a maintenance burden when people don't think in advance and in this scenario someone could have all the bad aspects of CORBA (not that many in my opinion ;-) with an added CPU-stealing-damn-unoptimized-communication-XML-channel Know your requirements and choose your tradeoffs carefully
  6. I once read somewhere someone complaining about the distributed computing paradigm and advocating the use of protocols only. That way the services were supposed to last longer (examples like e-mail and the web).

    Unfortunately, many ill-designed protocols around are less extensible than changing interfaces (which, in fact, are the same thing if there's proper use of abstraction and remoting technologies), and that makes this point invalid. Even REST can be a maintenance burden when people don't think in advance and in this scenario someone could have all the bad aspects of CORBA (not that many in my opinion ;-) with an added CPU-stealing-damn-unoptimized-communication-XML-channel

    Know your requirements and choose your tradeoffs carefully

    Yep - and as we're in this area of discussion - Waldo's "End of Protocols" seems relevant: http://java.sun.com/developer/technicalArticles/jini/protocols.html
  7. My five cents worth...[ Go to top ]

    About Steve's remark on statefulness... There are well-known patterns for handling this that work very well (for CORBA and Ice). I replied on Steve's page as well. Rather than repeating it all here, here is a link for how to handle abandoned objects: http://www.zeroc.com/newsletter/issue3.pdf (Look for the article "The Grim Reaper".) The versioning issse that Steve mentions can also be solved quite elegantly. Check out the editorial and the article "Can a Leopard Change its Spots?" in http://www.zeroc.com/newsletter/issue8.pdf About doing distributed computing over long distances... I believe that the stateful interaction argument is a red herring. I can do things stateless with both CORBA and Ice and, if I'm doing stateful things, there are ways to clean up abandoned objects that are very effective. Versioning can also be solved quite elegantly. (See above link.) And, as I've argued in the past, trying to do versioning at the protocol level, as SOAP does, is to fundamentally tackle the problem at the wrong level of abstraction. Chattiness is simply a matter of granularity. If my objects are too chatty, I pay the price. But, whether I use WS or an RPC platform, I have to worry about chattiness (latency and bandwidth) too. I don't think any distribution paradigm can help me with that. (And, I'd argue that SOAP, due to the XML encoding, is far more chatty than CORBA or Ice.) Interoperability is simply an engineering issue. It's easy to make protocols that interoperate just fine, and we have thousands of them to prove that point. If CORBA has interop problems, it's due to the poor protocol, and due to poor implementations of that protocol, not due to anything in principle. How to get things cleanly through firewalls is also a solved problem. (See Ice's Glacier2 service.) The fact that CORBA has problems with firewalls doesn't mean that we have to throw out the baby with the bathwater and send everything via port 80. To me, the main thing about middleware is whether it's easy to use, efficient, and flexible. WS fails on all three counts, IMO, which is why I don't like it. Cheers, Michi.
  8. EJB 2.x was clearly wrong[ Go to top ]

    I should add that I dismissed EJB by saying it was "clearly wrong" because that fact is so well known it didn't even bother mentioning. EJB3 and hibernate give you persistence without trying to tell you how to write the networking side of your application. Admittedly, Sun now think you should export everything as a Web Service, but that is still, thankfully, optional. -Steve (returning to the problem of getting hibernate 3.2 working on Jboss4.0.4 without the cache libraries throwing exceptions)
  9. CORBA, DCOM, ICE, RMI, .NET remoting and WSRF all implement the idea that you are talking to instances of stateful things at the end, with operations to read/write state, and verbs/actions/method calls to tell the remote thing to do something. These protocols invariably come up against the object lifetime problem
    Talking to instances of stateful things means there is some kind of user session. The concept of a user session with state seems very natural to me. If you don't have a server side session, you'd have to send all user related data to the client and back to the server on each round trip. The advantages of sessions far outweigh the object lifetime problem. Imagine web applications without sessions. Store all user data in cookies? A nightmare. So, why should Corba sessions be a problem and web sessions not? Because Corba sessions have no session timeout? Concerning the problem of interface changes, everybody accepts that if a library has a change in its interface, the client code has to change, too. So, why is it seen as such a big problem, that if a part of a distributed application changes its interface, you have to change the clients, too? I see strongly typed interfaces as a big advantage, the compiler prohibits lots of errors. There must be a reason, that there is a type system in Java or C++. Of course, you could write software using only strings and hashtables. But the compiler couldn't help you much anymore. Same goes for strongly typed interfaces.
  10. Distributed objects should be regarded as the greatest anti-pattern of software design that has ever been foisted. Untold bad implementations and bad technology initiatives have resulted from this one classic anti-pattern. But people to this day continue to latch onto it with bulldog tenacity. The network is neither reliable or deterministic. Get over it. Asynchronous messaging remains the only pragmatic way to go about implementing distributed software systems. But you have to shift your mindset out of a host of bad inclinations that comes from wanting to try and use your objects directly over the network. http://www.vossnet.org/jms-links.html
  11. The network is neither reliable or deterministic.
    An in-house network is sufficiently reliable. Our Corba applications are running rock solid for the last five years. For other examples you might read TAO's success stories. As for asynchronous messaging: usually there is a user waiting for an answer from the computer. And this is a synchronous situtation you have to emulate using your MOM. Basicly you have to do at application level what without MOM is done by TCP: namely keeping the connection. Of course there are good uses for messaging, if it is fine if the message does not arrive on time and there is an input queue like your mail-in box.
  12. Reliable networks[ Go to top ]

    A network backbone in a single room may be reliable; this is cluster scope use where the latency is such that blocking rpc-style calls can work too. This is the original network that distributed objects were written for. With something like infiniband you get a network so fast that remote calls are not much slower than calls to a different process on the same host; marshalling becomes the overhead. In such situations, being able to make blocking calls saves you the hassle of async operations, which are painful, and, if you want reliable computing, means you need to do timeouts, state machine modelling, and other things. It is not fun. What is not reliable is the laptop going from room to room, the long haul link to the site abroad, the phone trying to WAP in. These are the part of modern networks, like it or not. If you have to deal with such boxes, then corba is not the tool of choice. Nor is RMI, DCOM or, arguably, WS-*.
  13. After trying most of the distributed object technologies, I tent to agree. The distribution solution that I've used that worked the best was Tuxedo, an asynchronous messaging technology like you describe (similar idea to JMS, but a lot more powerful IMO). It seems to me that Objects became the next Marketing idea at one point, and of course the vendors needed to sell it on top of the incumbent technology, hence the focus on C++. Well the inventor of Object Orientation, Alan Kay didn't intend us to be doing OO messaging using a language like C++. My view is that there is computer science and software vendors, and when the two mix, science tends to loose out. Pure OO is built on pure sychronous messaging. I don't believe that sychronous messaging has been the problem in the past, rather the dependency on remote interfaces and static binding. Tuxedo and dynamic OO systems have no such weaknesses. An approach that seems to work well is replicated objects (Croquet and Gemstone), where local OO messages are broadcasted to remote replica objects. Another approach that sounds appealing is mobile objects (sometimes referred to as Agents), where the objects themselves are transmitted across the network, run remotely before returning back to the client. Again, this approach is better served by dynamic, reflective languages. Thinking back to my experience with Tuxedo, I can't help feeling that the approaches that are proven and work tend to get the least attention. Why? Paul.
  14. Distributed objects should be regarded as the greatest anti-pattern of software design that has ever been foisted.
    Well, 'distributed objects' were before the internet age. The enormous success of 'simplistic' http/HTML swept away overweight 'distributed objects'.
  15. Distributed objects should be regarded as the greatest anti-pattern of software design that has ever been foisted.

    Well, 'distributed objects' were before the internet age. The enormous success of 'simplistic' http/HTML swept away overweight 'distributed objects'.
    HTTP/HTML had its day when the web was content centric. HTTP was good for fetching content and could scale well. HTML was good for rendering content for mass consumption. Yet now the web is evolving toward the RIA experience - where a much richer communication medium is in play (or is highly desired). In particular, RIA centric development is looking to find ways of doing effective server push of messages to clients. Then it will be possible to build true event driven distributed software systems for the web where communication is completely bi-directional and symmetric in capability. First developers were happy doing field validation in asynchronous manner via AJAX. These days folks are wanting to "subscribe" to notifications instead of being stuck with just the polling option. Bi-directional asynchronous messaging is the broad trend - as an event driven approach is the better model relative to synchronous request-response. synchronous RPC considered harmful Yes, yes, a play on Knuth's "goto considered harmful", but of course is right on! decoupling request/response Counter intuitive? Perhaps at first glance.
  16. Hi Roger,
    Bi-directional asynchronous messaging is the broad trend - as an event driven approach is the better model relative to synchronous request-response.
    I don't believe this to be true. An asynchronous message send where the sender waits for an acknowledgement is actually synchronous since the sender blocks waiting for a response. This can be done with as little coupling as the case where the sender waits for no response (think JMS). Tuxedo calls a blocking message send "synchronous messaging". In a dynamic OO language like Smalltalk the same idea is used to send messages between objects, the sender blocks waiting for an answer to the message sent to the receiver. The difference between synchronous messaging as I've described it above and RPC is that the sender knows nothing about the receiver. There is no interface coupling. If the sender sends a message to the receiver that the receiver doesn't understand then the receiver can respond with a negative acknowledgement message (I do not understand). Like I said in my post we have settled on one view of objects, largely for commercial reasons in my opinion. Tuxedo does a whole raft of message based comms (synchronous and asynchronous), but avoids coupling between the sender and receiver. IMO dynamic OO languages allow for the same possibility. Here are some examples: http://www.opencroquet.org http://www.gemstone.com I would be interested to here from anyone with direct experience with Gemstone. Everything I've heard so far has been positive, and my limited experience with Croquet has been remarkable. So IMO where we went wrong was trying to implement an essentially late bound problem (OO distribution) using an early bound language like C++. AFAIK CORBA also had a dynamic API, but I've never used it and I'm not sure that it was well supported by most implementations. My experience with Tuxedo has convinced me that dynamic messaging is the best way to go, and messaging can be both synchronous and asynchronous. Paul.
  17. Hi, A better link for Gemstone: http://www.gemstone.com/products/smalltalk/ Paul.
  18. Bi-directional asynchronous messaging is the broad trend - as an event driven approach is the better model relative to synchronous request-response.


    I don't believe this to be true. An asynchronous message send where the sender waits for an acknowledgment is actually synchronous since the sender blocks waiting for a response. This can be done with as little coupling as the case where the sender waits for no response (think JMS).
    My messaging apps are not designed that way internally. Messages are published with no blocking whatsoever. If is a GUI client, then is completely event driven internally. (Server-side are usually MDBs.) Any received msg results in an "event" that is processed. What you described is synchronous RPC. Even if one used JMS APIs to implement it - it is still effectively synchronous RPC. That's a different mind set of application design.
    Tuxedo calls a blocking message send "synchronous messaging". In a dynamic OO language like Smalltalk the same idea is used to send messages between objects, the sender blocks waiting for an answer to the message sent to the receiver.

    The difference between synchronous messaging as I've described it above and RPC is that the sender knows nothing about the receiver. There is no interface coupling. If the sender sends a message to the receiver that the receiver doesn't understand then the receiver can respond with a negative acknowledgment message (I do not understand).
    You're certainly right on about this. Loose coupling plays a major role in enabling applications to be more flexible and able to evolve with less headaches. Distributed applications that bind directly to remote object interfaces are way too brittle. Here goes a buzz word, but, loosely coupled distributed messaging applications are inherently SOA. It is much easier to go in and repurpose code and/or message flows to do new and different things. Ceaselessly my messaging based applications are being tweaked via natural IT evolution. With a messaging approach I have so many tools and techniques at my disposal to manage such evolution - starting with just doing mild things like introducing a bridge rule in the server to copy messages to other queue/topic destinations where additional kinds of processing takes place (but even this simple technique is not readily possible when doing RPC/interfaces). When I did distributed object interfaces back in the '90s, those systems were brittle and had no flexibility to speak of. The world I exist in today founded completely around distributed messaging is a polar opposite in characterization.
  19. Admittedly I've used "synchronous RPC" rather broadly. I'm actually emphasizing the "synchronous" more so than the "RPC", though. So fair enough if is desired to make a distinction between a synchronous messaging request/response vs. a synchronous RPC - where the latter additionally implies the brittle binding to a interface/method signature. The plumbing under the hood is rather similar, and the consequences of blocking are the same, but the binding to interface/method and direct end-point to end-point coupling of RPC do have additional unsavory consequences.
  20. In this discussion, I’ve assumed a synchronous, RPC-based interface. However, although that’s what I’ve described, I actually don’t think it’s always the best way of handling a distributed system. Increasingly, my preference is for a message-based approach that’s inherently asynchronous. In particular, I think they’re the best use of Web services, even though most of the examples published so far are synchronous. For patterns on asynchronous messaging take a look at www.enterpriseIntegrationPatterns.com. —M. Fowler
    Thanks for that Martin Fowler article link, Cameron. --RogerV
  21. Hi, I've read Martin Fowlers book on Messaging Architectures, and whilst it deals with the central point that Messaging is superior to RPC, I found it pretty thin on practical messaging approaches. The best book I've read on Distributed Computing using Messages is the following: The TUXEDO System: A Guide to Constructing Distributed Business Applications Even though it follows an implementation of a C/Unix based 1980's OLTP System (TUXEDO). It covers messging approaches like nothing else I've read. I no longer have access to a copy, and in fact this discussion has prompted me to buy one from Amazon. I would recommend it to anyone serious about messaging no matter what messaging platform you choose to use. Paul.
  22. Hi Roger, I think we are in broad agreement. Keep an open mind about synchromous messaging though. I've done it using Tuxedo like I say, and it is nothing like RPC which is way more brittle. Tuxedo is a powerful MOM system tackling issues like versioning which RPC based approaches don't even touch. Take a look at Tuxedo, you may come across a number of messaging design ideas that you hadn't considered. Paul.
  23. Tuxedo is a powerful MOM system tackling issues like versioning which RPC based approaches don't even touch.
    I've been using Tuxedo for 11 years - always doing SOA. I agree with all of your positive comments about it, but Tuxedo isn't a MOM. It's actually an application server. Compare Tuxedo with a J2EE application server - transaction management, connection pooling, "stateless session beans" (Tuxedo services), dynamic workload management (instantiating new instances to meet demand, deleting them when demand falls), clustering, domains, etc. Tuxedo does it all and it was the first product to do them. Want an IDL/Schema to describe your messages and to make their contents accessible by name? Use Tuxedo's FML. Want non-persistent asynchronous messaging, synchronous messaging, persistent queues (System/Q)? Tuxedo has all of that as well. Want OO? Use C++. On top of all of that, Tuxedo's ability to scale is huge, but it isn't a MOM. BTW, when I first began J2EE in late 1999 I very successfully applied my Tuxedo design patterns. They worked much better than what the J2EE consultants and vendors were promoting (zillions of chatty distributed objects).
  24. Hi
    I've been using Tuxedo for 11 years - always doing SOA. I agree with all of your positive comments about it, but Tuxedo isn't a MOM.
    Thanks for the correction. I've used Tuxedo only from a Java EAI client perspective, so not so familiar with the services available to Servers. FML and typed buffers, aren't they just great! Yet I've never seen them used anywhere else. IMO it looks as though we've gone backwards. Paul.
  25. Distributed objects should be regarded as the greatest anti-pattern of software design that has ever been foisted. Untold bad implementations and bad technology initiatives have resulted from this one classic anti-pattern. But people to this day continue to latch onto it with bulldog tenacity.
    The problem was that the technology (the ability to communicate a method invocation over the network) was abused until it became the idea of distributing a synchronous object graph across many servers. Martin Fowler has a great old article on this, in which he stated something like "there are many things that you can make transparent in a distributed environment, but performance is not one of them" :-) Even better though, he completely dissected (and deconstructed) the notions behind distributed synchronous object graphs. Highly recommended reading: http://www.ddj.com/dept/architect/184414966 Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  26. Just my 2 cents based on my little experience with CORBA. I can't do almost anything but agree with Michi Henning about all the problems it has. But there has been a great milestone achieved with CORBA 2.3 and the introduction of the POA with the distinction between the Servant and the Object. Actually this model, IMHO a MUST for a communication middleware, has been adopted only by ICE and this lack is highly penalizing Web Service. Certainly CORBA is not usable as a distributed computing framework over the internet. Neverthless, I dont' think that distributed systems over the internet ends "on the border". There is some "inside" that is a world by itself. And here CORBA has still its place. I would never use SOAP for this. Guido
  27. Hohpe and Woolf[ Go to top ]

    Since there seems to be some MOM experience here, does anyone have any comments on "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" by Gregor Hohpe, Bobby Woolf. I've found it to be quite informative; but I'm just treading the messaging waters now with Spring's JmsTemplate functionality.