Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

Java RMI 106

Posted by timothy from the spreading-things-out dept.
Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review.
Java RMI
author William Grosso
pages 545
publisher O'Reilly
rating 8
reviewer amoon
ISBN 1-56592-452-5
summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
This discussion has been archived. No new comments can be posted.

Java RMI More

Java RMI

Comments Filter:

  • Can't determine client from the server side (Score:4, Interesting)

    by atomray ( 202327 ) on Monday March 04, 2002 @11:26AM (#3105372) Homepage
    Having come from a background of Servlet/JSP development, I was quite surprised to see that RMI lacked what I consider a basic feature of distributed computing - authentication and session tracking; this forced me to develop my own, but this is obviously a common need and should be handled by the RMI runtime. I haven't worked with CORBA beyond a couple toys to learn the system, but my understanding is that CORBA does have these feature.

    The book itself is excellent - I purchased it after starting to work on a large project with RMI, and realizing that a couple online tutorials wouldn't cut it. The advanced section isn't quite as advanced as I had hoped, but overall the book is a decent reference.
    • I was quite surprised to see that RMI lacked what I consider a basic feature of distributed computing - authentication and session tracking; this forced me to develop my own, but this is obviously a common need and should be handled by the RMI runtime.


      Enterprise JavaBeans [sun.com], and Session Beans in particular, provide these services. RMI is used as the transport layer, and the application server (EJB container) handles authentication and session tracking, often along with redundancy, administration, and a host of other goodies...

      • Yes, I looked into that option (and even looked at the JBoss sources to see how they were implementing authentication/sessions over RMI), but EJB was simply too heavy duty for my purposes. The app had to run on people's computers, not on central servers.

        • Re:EJB provides this... (Score:3, Informative)

          by jonabbey ( 2498 )

          Yes, I looked into that option (and even looked at the JBoss sources to see how they were implementing authentication/sessions over RMI), but EJB was simply too heavy duty for my purposes. The app had to run on people's computers, not on central servers.

          You might look at Ganymede [utexas.edu]. We implemented a session layer using RMI long before J2EE existed. It's not really that hard to do.

    • You can hack in your contextual message passing (e.g. for authentication and sessioning).

      Try this:

      Implicit contextual info in 1.2-RMI calls

      http://www-und.ida.liu.se/~ricob684/java/ctxrmi/ do cs/index.html

  • RMI over SSL? (Score:2, Interesting)

    by nsushkin ( 222407 )
    Does the author discuss RMI security and RMI over SSL? If he does, it would be a welcome advantage to the book that probably should've been mentioned in the review. RMI over SSL (via JSSE, for example) is one of the new features that Sun offers, for which only very shallow documentation is available.

    • Re:RMI over SSL? (Score:3, Interesting)

      by atomray ( 202327 )
      The author spends a bit of time talking about Custom socket factories in RMI, which is used to make RMI calls over SSL sockets.

      Here's 'the scoop' from sun [sun.com]. It refers to JDK 1.3 - as far as I know, everything you need is in JDK 1.4 now, no need to get the JSSE ppackages.
    • Yes, from the table of contents...

      2. Sockets
      ...
      **--> Using SSL

      Of course, we are talking about RMI (streaming remote methods and parameters over a network socket) over SSL (secure socket layers). There isn't really much magick involved.

  • over complicated (Score:5, Insightful)

    by DrSkwid ( 118965 ) on Monday March 04, 2002 @11:31AM (#3105385) Journal
    I think that most of corba/dcom/rni etc. are particularly over complicated. They place a burden on the programmer in the wrong place. It's worth checking out plan9 [bell-labs.com]'s approach to distributed computing. Authentication is taken care of by an authentication server. Once you've got an authentication ticket then you can access networked resources by binding remote services into your local namespace. Rights are granted by the usual mechanisms of usernames & groups.

    The familair paradigm of users and groups has been deliberately leveraged because that's what is familiar, after all it's stood the 30 years test of time. This extends to which processors on the network you an run processes on etc. etc.

    It's worth studying if nothing else.
    • I think that most of corba/dcom/rni etc. are particularly over complicated. They place a burden on the programmer in the wrong place.

      Most but not all. Check out XML-RPC [xmlrpc.com] which is an extremely simple yet useful remote procedure call protocol. As its name suggests it passes XML documents between server and client, in this case over HTTP.

      There are good XML-RPC implementations for several languages, including Java, C, C++, Python, PHP and TCL (see here [xmlrpc.com] for a full list). I implemented the RPC part of a fairly a simple client-server Java application in under a day, without any previous knowledge of XML-RPC.
      • I like XML/RPC and I'm looking forward to doing something in it.

        However it's pretty asymmetric. It can only deal with client requests, an issue pretty much covered the other day. [slashdot.org]. The server can't delay a response or let the client know when it's finished a lengthy request. As an illustration imagine if you wanted to monitor new /. stories. With XML/RPC you need to keep polling the /. server to see if there was a new story. Using sockets you'd need to have a listener on the client end but as soon as the server wanted to tell you, you'd know.

        I'm just waiting for native java in FreeBSD (*sigh* we're told Sun is stalling, come on Sun, sort it out!!!) before I can really start exploring XML/RPC (I have an app in mind already).

        There's also the issue of tunnelling through port 80. Some people like it (hey I can get through the firewall by using port 80!) and some people hate it (if only I could stop all that goddam non http traffic on port 80, it's killing my load balancing)
        • However it's pretty asymmetric. It can only deal with client requests, an issue pretty much covered the other day. [slashdot.org]. The server can't delay a response or let the client know when it's finished a lengthy request.

          The way I deal with this is having the "client" also include an XML-RPC server so it can register with the "server" and receive callbacks that way. Of course, the server has to be coded to do this too, but its relatively straightforward. There is also asynchronous XML-RPC [userland.com] although that is mostly a polling routine that's pre-wrapped for you.

          There's also the issue of tunnelling through port 80. Some people like it (hey I can get through the firewall by using port 80!) and some people hate it (if only I could stop all that goddam non http traffic on port 80, it's killing my load balancing)

          Absolutely no reason you have to use port 80. You can specify any port for the XML-RPC server to listen on.
        • However it's pretty asymmetric. It can only deal with client requests, an issue pretty much covered the other day. [slashdot.org]. The server can't delay a response or let the client know when it's finished a lengthy request.

          Why don't you just start a new thread for each of your requests?
          • Why don't you just start a new thread for each of your requests?

            Say it takes 30 minutes, I suspect that my ISP's in-line cache might not let me keep the connection open for that long. Plus if I'm hosted somewhere the web server might also time-out the script after a few minutes (30 secs even).

            I *know* you don't have to use port 80.
            I *know* you can change the timeout.
            I *suspect* there are other solutions while keeping XMl/RPC your transport

            but there are also a finite number of ports. If each one of /.'s readers wants new story notification then there aren't enough ports to keep one each open 24/7.

            I would just use a different machanism for problems in this domain, that was my point. XML-RPC offers great marshalling of dynamic parameters.

      • As its name suggests it passes XML documents between server and client, in this case over HTTP.

        This statement is a bit deceptive. The purpose of the XML-RPC protocol is not to allow you to exchange XML documents with your own grammar between a client and server. It's purpose is to define a grammar of simple, cross-language types that can be used to marshal the arguments and return values of most simple method calls.

    • I used to do quite a bit of RMI programming. It was a pain in the butt. For any problem of non-trivial complexity, RMI becomes somewhat burdensome. Then I moved on to J2EE, mostly JSP/Servlet stuff with some JDBC, no EJB, and it was a breath of fresh air. It's like the difference between Java 1.0 AWT and 1.1 AWT. Then recently one of our projects called for data sharing between different webapps, and despite my objections RMI was dragged out, and it I found that little has changed. Classpath problems are probably the biggest offenders, even in the JDK 1.2+ "no-classpath" era. It's just not a well-designed spec. It's a shallow OO wrapper over old-school RPC, and, IMHO, is not worth the hassle.

  • Strange Review (Score:3, Insightful)

    by dnoyeb ( 547705 ) on Monday March 04, 2002 @11:32AM (#3105393) Homepage Journal
    yes, I too found little in the review preview about XML.

    I have used both CORBA and RMI. I don't know why they are shown as competitive products.

    CORBA is used when you wan't cross language compatibility. (c / Java / C++, etc.)

    RMI is used when you want Cross platform compatibility give by JAVA.(windows, Linux, Mac)

    DCOM is used when you are working on M$ Windows.(windows, C++)

    To me these 3 are complimentary, with CORBA being one of the hardest but most dynamic. So naturally I expected to see in the review a statement about where the XML thingy fit into this puzzle. Why would you mention these 3 technologies without mentioning that?

    • Re:Strange Review (Score:1, Redundant)

      by dthable ( 163749 )
      The book was written a few years ago just as companies started to see how XML could be used with the different technologies you mentioned. While the general concepts of the book are the same, I would be warry about purchasing the book and expcet to leverage the new Web Service model that both Microsoft and Sun are pushing.

  • Alternate reading (Score:1, Informative)

    by Anonymous Coward
    Also see "java.rmi The Remote Method Invocation Guide" by Pitt and McNiff, published by Addison-Wesley. (In my opinion Addison-Wesley has managed to produce a more consistent set of technical titles than O'Reilly, though to be fair standards seem to be rising again for "the animal books".)

    It covers much of the same material and may be useful reading for those less familiar with RMI as it has a longer lead in to the advanced material.

    --
    Dr David Kennedy
    Senior Software Design Engineer
    Nortel Networks
    Not so much anonymous as just infrequent at posting.

  • RMI works well! (Score:4, Informative)

    by SkyLeach ( 188871 ) on Monday March 04, 2002 @11:33AM (#3105401) Homepage
    I have been a java developer for some time. I had the opportunity to use RMI in java to write a distributed client-server pricing solution for a large telecom company. (I'll keep it quiet; I don't want to be sued).

    The problem: Run pricing routines on very large CDR (Call Detail Record) sets. This involved a very complicated process of aggregating calls into time slots and then pricing them according to very complicated long-distance contracts. Pricing very large amounts of data sometimes took as much as two days to price and discount.

    Solution: The implementation (at least in Java) of the RMI standard is simple. In order to avoid purchasing an expensive CORBA implementation we extended our c++ client program with JNI. The client program then called a local wrapper class that used RMI to spin off the pricing call on the remote RMI server. We had big-iron machines running an in-house RMI application server. The application server really just worked as a multi-threaded container that loaded RMI servers from the disk and registered them, allowing a person to order servers to be loaded and/or dropped from the registry via a console.

    The solution was cheap and worked very well.

  • Mastering RMI (Score:3, Interesting)

    by smagoun ( 546733 ) on Monday March 04, 2002 @11:37AM (#3105425) Homepage
    While I haven't read the book being reviewed, I know that "Mastering RMI" by Rickard Oberg is one of the best resources on the subject. Rickard is one of the brightest people out there, and he's made waves throughout the enterprise Java world. He's responsible for some of the genius of JBoss, among other things (he came up with the dynamic proxy trick that means JBoss doesn't require stub classes). Check his book out, it's worth it.
  • Comment removed based on user account deletion

    • Re:Bah (Score:1, Insightful)

      by Anonymous Coward
      Er, given that DCOM is/was DCE RPC, and even Microsoft themselves are sending DCOM the way of the dinosaur, I think you're remembering the past through rose-tinted glasses...
  • It's true that Sun's reference implementation on Windows doesn't scale very well(at all?) with respect to large numbers of simultaneous connections. I am unclear as to whether Sun's I/O improvements made with 1.4 will help RMI's connection handling ability. As with most things dealing with reference implementations though, one usually has to buy something to get performance improvements. Depending on how much one believes weblogic, their implementation of RMI seems to be quite the performer [weblogic.com]
  • Good to see that not everyone's waxing lyrical about XML, EJB and SOAP these days. I agree that it's important to keep up with old technologies as well as new - the computer industry does have a terrible habit of "forgetting" really important technologies.

    I am still waiting for a Common Lisp revival - many abusers of XML/XSL will kick themselves.
    • Quite right, but we should perhaps say why, e.g.
      • Scheme etc. is better than XSL because it's more consistent and more powerful - no need for escapes to real programming languages as real-world XSL processors like Saxon have to provide
      • Programs are data, and advanced IDEs like Eclipse would be a lot easier if they started from LISP heritage (hence EMACS longevity).
      • RMI can do things that CORBA, EJB and SOAP cannot, including pass-by-value and code transfer.
      These issues come up time after time on /. in the context of Dotnet equivalents, the future of Perl, best languages for web programming and so forth, but few people make the case for a one-size-can-fit all LISP-based alternative - something like Dylan, for example.

  • We are aware of this, no?
  • This is why RMI is cool: In Java when you have a local object and want to instantiate it and then call a method on it, you do something like this:

    FooClass foo = new FooClass();

    foo.myMethod();

    Now in RMI to call a method on a REMOTE class you simply do this:

    FooClass foo = new FooClass();

    foo.myMethod();

    Yes, it's the same. I admit I left over about 2 lines of code needed in your declarations (basically a URL pointing to the remote server), but this simple pseudo code example gives you a glimpse at the simplicity of working with RMI: basically all remote objects look like local objects, which makes programming EXTREMELLY simple. Try that with SOAP/CORBA/DCOM. Note that I do admit SOAP has its uses in Web Services, but for transparent programming, RMI is amazing.

    On a side note, XML and its siblings (SOAP, UDDI, WSDL, etc) are being implemented in such a way as to make working with XML/SOAP as simple as the RMI example above (another great reason to use Java).
    • While it is indeed cool that invocation of a remote call is syntactically equivalent to that of a local call, it masks the true "cost" that you pay.

      It is a fact that remote calls are more expensive in terms of network bandwidth, latency, and response time compared with a local in-process procedure call.

      The problem is that RMI makes expensive remote calls look like cheap local calls. This can lead to performance problems which are hard to find, since the offending code looks so innocuous.

      • I think raising the performance problem is splitting hairs - the fact that the syntax is the same for both remote and local calls is more handy than dangerous IMHO.

        I agree though that such syntactic sugar should be taken with a pinch of salt! The overstatement of the virtues of transparency leads many developers to believe that they REQUIRE transparency in everything, leads to (for example) lots of time wasted in writing persistence layers, O/R mappings and so forth whilst waiting for JDO to be released.
  • With an outstanding effort, the author goes for the gold and stuffs one paragraph with so many acronyms and abbreviations, it makes it barely readable!

  • SOAP & APEX are NOT RPC!! (Score:1, Insightful)

    by Anonymous Coward
    They are messaging specs (at different layers). You can do RPC over them (SOAP includes a way to encode RPC requests, but you can send any sort of asynchronous message you want).

    Come on people, stop talking about things you don't know anything about! The specs are public, READ THEM!

  • Messaging (Score:3, Insightful)

    by abigor ( 540274 ) on Monday March 04, 2002 @01:37PM (#3106145)
    One other thing to consider is messaging, like that provided by JMS (now part of J2EE). It's a good alternative to the purely synchronous world of RPC (embodied by XML-RPC, SOAP, and the like) because it gets around some of the vagaries of making calls over an unpredictable environment (the Internet). Things like publish-and-subscribe, guaranteed delivery, and asynchronous processing are pretty cool, since synchronous RPCs can get waylaid by part of the network going down, etc.

    I've only fooled around with it, never used it in a real project, since message-driven beans are pretty new. Does anyone know of a project that makes extensive use of Java messaging, particularly using message-driven beans?
    • I'll agree that asynchronous messaging and pub-sub are cool if you show me an application that doesn't require:
      • the receiver to start with a 'snapshot' of the info being updated (needs RPC)
      • the receiver to request a resend of messages because of software or other error (needs RPC)
      • a messaging system that wouldn't benefit from a 'workflow-like' monitoring system (needs RPC)
      • a JMS system with a message store able to replace any client-side or server-side message store for recovery purposes
      • a way of avoiding the order-of-magnitude slowdown on key transactions imposed by 2-phase commit across database and message store
      • a message system that doesn't act as a 'transaction fragmenter', sending messages which are meant to be ordered down separate channels (subjects) which have no concept of overall order
      In short, JMS should be next in line for attack after EJB, it's pretty useless for corporate transactional communication - just log updates in the local database and provide an RPC for clients to pull them off instead. Simpler, faster, more reliable... and cheaper!
      • OK, I'll try :)

        Example: travel agent says, "Give me current flight status information - only send changes; keep me updated."

        Use publish/subscribe; information comes in the form of SOAP; guaranteed delivery doesn't need resends; message-store is implementation-dependant, and anyway, who stores RPCs?

        This is better than RPCs because no polling is needed.

        As for your other points:

        I don't know what you mean by point 3.

        Point 5: I agree there is a performance hit with publish-subscribe. Point-to-point is better, but pub-sub has some great advantages.

        Final point: message order is not guaranteed, so far as I know. Obviously, if you're doing multi-part transactional updates where ordering is critical, don't use messaging.

        Well, we differ on a few things -- I like EJBs. Your "log updates" solution lacks a few things -- like scalability, authentication, security, etc. It's all roll-your-own; expensive and time-consuming. EJBs are around so you don't solve the same problems over and over.
        • only send changes

          This virtually never happens. The set of objects (Flights) of interest has to be communicated from receiver to sender, and an initial snapshot still has to be provided, ergo RPC still needed.

          guaranteed delivery doesn't need resends

          Formally, there's no such thing as asynchronous guaranteed delivery. Practically, one needs resends because a receiver can still lose or mis-process messages.

          message store is implementation dependent

          Any implementation which is not the same storage resource as the sender needs 2PC. This is a fundamental problem of the paradigm, not an implementation problem.

          better than RPCs because no polling is needed

          In the very rare cases where polling is a significant load on the network (basically where your Max Desired Lag Time &lt&lt Average Msg Interval) you can add a pub/sub or other notification mechanism on top. The point is that the notification is just advisory - this is a well-established event model dating back to Multics.

          point 3

          Most msging systems end up needing a state-monitoring system on top, resembling a workflow system. The problem is that a msg queue represents a black hole - you don't know whether your msg is still in the queue, or being processed downstream. Tracking the overall process state is perfectly possible, and many JMS vendors sell process mgmt frameworks on top of their basic tools, but it requires RPC between the components and the process manager, so you haven't really moved to an async model.

          pub-sub has some great advantages

          Such as?

          message order is not guaranteed

          It is guaranteed within a subject, but not across subjects. The problem is that the model encourages you to divide your transactions across subjects (customer updates, order updates), so setting you up for order-dependent problems later (cancel order, fix error in customer record, re-enter order - oops). Most apps have these dependencies, so JMS has a pretty narrow field of applicability.

          your "log updates" solution lacks a few things - like scalability, authentication, security

          On the contrary, I think it's clear that the 'receiver has control model' scales much better (can get many messages in a single call; no 2PC overhead; no need for queue to maintain each receiver's position), and can make use of standard secure transports such as SSL. Messaging, on the other hand, requires per-message signing/sealing, which is much more expensive than session-based encryption, while the pub/sub model is practically unsecurable (the message must be readable by all recipients, therefore must be encrypted under a common key).

          Well, we differ on a few thing
          I think that's a fair summary :)
  • The problems (I think) with the distributed objects approach via CORBA and even RMI are that:
    • they are bloated from both infrastructure and application perspectives
    • they expose too much 'implementation' of the remote object you're after
    • there is little connection between the design and performance perspectives of building an app
    • you cannot easily develop large-scale apps in this realm without an IDE (so you get tied to a toolset...)

    So what does this mean in shops that produce high-volume, high-throughput, high-userbase apps? You usually find that dist. object implementations have their object-to-object interactions up-levelled (artificially) to ensure that 'messages' (as opposed to granular method calls) become the implemented design-point.

    This is why RPCs (home-grown, SOAP/XML, or otherwise) make a lot more sense (to me). The technologies might be new, but the concepts are old and useful. Bottom-line (for me), is that RMI and CORBA do not implement service-based architectures very well. RPC-style solutions are a more natural fit from both the business requirement and technical design perspective.

    • I never read a post so full of rubblish. You clearly haven't done a single thing with CORBA. So you think you can write something huge with a protocol like SOAP, and not get tied to a toolset. Oh yeah, I can just see you now hand crafting those xml packaged calls. I have never used an IDE with corba all you need is idl and a compiler.
      • Not sure what 'rubblish' is, but I bet it's a bad thing. In retort: au contraire, mon frere... I started developing CORBA apps long ago (back when IBM's CORBA 1.0 SOM implementation was beta). Fact is, the CORBA 2.x spec is vague and bloated. Most CORBA implementations produce slow, bloated apps. It's NOT good for doing large-scale distributed apps that are maintainable. It's NOT good for doing granular dist. object interactions. Period. If CORBA (and other neat ideas like *nix RPC) were the right answer, we'd see much more large0-scale penetration (and marketing!) of the technology.

        I don't pretend that SOAP/XML is pretty or easy. What I AM saying is that the direction is, by and large, a saner one for IT folks to manage because it suggests a more component-based, message-oriented design-point that does CORBA or RMI. My persprective is that of a corporate IT guy who needs to architect large-scale app infrastructure accessible (and simple) for hundreds of developers. Individual mileage may vary...

  • I'm seriously considering using ACE for a cross-platform networking layer in a dstributed system I'm designing. I note that this also has an ORB thingy called TAO (which may just use DCOM/CORBA/RMI depending on the platform). So that may be another option to consider in the interim, i.e. rather than decide which ORB to back right now.

    So check out ACE (It's Open Source of course) at http://www.cs.wustl.edu/~schmidt/ACE.html
    and TAO at http://www.cs.wustl.edu/~schmidt/TAO.html
    .

    Here's some blurb:

    TAO is an open source product with zero cost licensing.(Development and run time.) TAO is a C++, CORBA 2.3 compliant ORB designed for real-time but equally applicable in general-purpose situations. TAO runs across multiple O/Ss and chip architectures enabling a wide integration capability, for diverse elements, within a single ORB implementation. TAO's baseline design for real time considerations ensures end to deterministic behavior and leverages both system and network characteristics.
    • Just to clarify, TAO is The ACE ORB and it's strictly CORBA. TAO has some very nice features and ACE (ADAPTIVE Communication Environment) provides a very good set of wrapper facades for network/concurrent programming in C++. If you want Java, take a look at JacORB (http://www.jacorb.org) for a nice, simple ORB. Disclaimer: I'm a Graduate Student at wustl and some of my friends work in the DOC group (they write ACE/TAO).

      Derek
  • www.horb.org java, open source. We have been using horb for years. Very dependable and easy to use. Fast too. And can run on single known port (of your choosing).

    • Wow! (Score:2)

      by jonabbey ( 2498 )

      I remember looking at Horb in early 1996. The design for Ganymede was inspired by what Horb was promising, but once Sun released RMI, it seemed that all the distributed object support necessary was bundled into every JDK, so why use Horb?

      Still, it's exciting to see that Horb has gained and kept an active user community.

Slashdot Top Deals

"Experience has proved that some people indeed know everything." -- Russell Baker

Close