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

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Do We Need Another OO RPC Mechanism? 92

Posted by Cliff from the variety-is-good-when-it's-necessary dept.
Paul68 queries: "I am looking for an RPC mechanism for a project. Granted, there are many to choose from, yet there seem none that meet my requirements! When one has toyed with the requirements the solution generaly becomes obvious. So, yeah sure, I can set out and create the next RPC mechanism, but it is a lot of hassle. But does the world need yet another OORPC, or have I simply not looked in the right corners?"

"My requirements are:

  1. object oriented
  2. extensible
  3. platform independent
  4. supports signatures for integrity and sender checking
  5. supports privacy of the message contents (i.e. encryption)
  6. time sensitive: I should be able to detect a dead server and do failover while the user is waiting for the response
  7. bandwidth efficient, as I am looking to deploy it in wireless environments
Now #1-3 are no problem, #4 and #5 can be found, and #7 rules out anything XML-based. #6 seems to be the killer, as this rules out anything over TCP, and at that point the list gets pretty short.

Does anyone have any options that I may have missed?"
This discussion has been archived. No new comments can be posted.

Do We Need Another OO RPC Mechanism? More

Do We Need Another OO RPC Mechanism?

Comments Filter:

  • It's time to stop (Score:5, Insightful)

    by Anonymous Coward on Wednesday December 31, 2003 @06:44PM (#7849611)
    And ask yourself, "What am I really trying to do?"

    • Re:It's time to stop (Score:5, Insightful)

      by mystran ( 545374 ) on Thursday January 01, 2004 @05:35PM (#7855189)
      Well, I've done CORBA for work, play'ed around with all kinds of other RPC systems, programmed with a quite a lot of languages, and after some hobby research and all kinds of strange projects, I've come to the following conclusion personally:

      There is one good RPC system, and it's called HTTP. It works wonderfully when you can generate stuff from a database into some text-representation.

      There are a lot of bad ones, which mostly have the same thing in common: It is NOT a good idea to make a remote resource act like an object. It just doesn't work well. To get an impression that it works well, you need a huge bloated library, so you can pretend that everything works, until your network breaks and you have to deal with all the shit yourself anyway, but now add the complexity of the RPC system to the mix.

      The thing is, when you design to work with a very simple system, either HTTP or something similar built on top of TCP directly, you end up with design, where the network is a natural part of the system. When you build something on top of a generic RPC system, you just add a layer of indirectness, which makes a good design much harder to get. In addition, when you restructure your data into text-representation (or other simple representation), you usually end up doing it in the right place, because it's usually the only place where such representation can be handled in a sane way.

      That's my 1 cent about RPC. The other 1 cent deals with objects. Objects are nice, if you don't have 1) database or 2) proper functions. When you have a (relational) database, you end up with something like objects anyway, when you build a good database access layer. For many things this is what you would want to do anyway, with the added benefit that you never need to care about object references. You just tell the system how to find/alter what you need.

      For the functions, as soon as you have first-class functions, objects no longer make much sense, as it takes about 15 seconds to build an object system on top of these functions. Most of the time you don't want object anyway, as you usually want functions and data instead. Learn LISP. It is more useful today than ever before. If there's something wrong with existing dialects, then help build a better one.

      As for your requirements: You could use TCP directly, but you need encryption, so add ssl or something. Authenticate the connection or something, the encryption should handle rest of the integrity (this is pretty much a cipher question). Build a simple protocol with no tweaks and leave the extensibility there. If you want, you could send XML anyway, if you use zlib or something to compress it. Depending on your data, it might be the easiest thing to parse anyway. Separate the protocol layer, have it timeout and catch TCP failures, and automatically reconnect (same or other server), and you have the time-sensitivity. If you need more, send requests to multiple servers, and handle them with the one that answers first. Aim for stateless protocol, and it becomes easier. TCP and SSL are pretty platform independent, so unless your protocol is really bad that shouldn't be a problem. Now, you basicly want this all for every application in existence.

      Forget the objects, they just make life a lot harder. Use cookies and numerical identifiers if you really need to. A lot of things look like they needed OO-RPC, but to this day I've not seen a single one where it really made sense. Doesn't even speedup development in the long run..

      • There is one good RPC system, and it's called HTTP. It works wonderfully when you can generate stuff from a database into some text-representation.

        The people behind REST [conveyor.com] seem to agree with you, I think.

    • Re:It's time to stop (Score:4, Insightful)

      by duffbeer703 ( 177751 ) * on Friday January 02, 2004 @09:46AM (#7859780)
      The AC speaks the truth.

      A million years ago, a caveman spent alot of time developing the wheel. Don't replicate his work. You're likely to make lots of mistakes when you reimplement RPC or yet another master framework product, particularly with the encryption and signing part.

      I know of people working on a similar project using Java Jini. Check it out.

      Also, base your decision on the actual architecture of your application, not the buzzword-compliance of the glossy brochure or website.

  • Does 7 really rule out XML? (Score:5, Insightful)

    by forsetti ( 158019 ) on Wednesday December 31, 2003 @06:50PM (#7849666)
    How much overhead do you expect XML to incur? Or more importantly, what do you expect your data/(data + XML) ratio to be? With large amounts of data, the relative amount of XML is relatively small.

    Of course, if you are sending many packets, each with small amounts of data, perhaps strewn across many XML tag sets, then the XML "noise" ratio may be high. How about gzipped XML-RPC ?

  • Something XML-RPC (SOAP) doesn't have (Score:5, Informative)

    by SteveX ( 5640 ) * on Wednesday December 31, 2003 @07:03PM (#7849750) Homepage
    ...that bugs me is that there's no way to make a call that will return multiple pieces of data over a long period. Like, I want to connect to a server and say "tell me every time the price of IBM stock changes". I can use SOAP for most of a trader type UI but for streaming the data back to the client, you have to use another protocol (unless I'm missing something).

    The dude asking the quesiton here is, I think, a little too worried about overhead - the overhead of XML is fairly tiny, and the overhead of TCP/IP isn't that great either - if both of those really are too much then you're probably on your own as there isn't likely to be a "general purpose" solution that will work for you.

    - Steve
    • What you are looking for is more along the lines of an asynchronous publish subscribe style architecture such as JMS, MQSeries, or Tibco.

      SOAP is designed for easy synchronous communication, and while you can fake synchronous over asynchronous, it can be more challenging to go the other way.

    • Re:Something XML-RPC (SOAP) doesn't have (Score:4, Informative)

      by ThenAgain ( 627263 ) on Wednesday December 31, 2003 @07:18PM (#7849857)
      I once implemented a web interface that used XML-RPC to communicate with a search engine back-end. Each request lived in a state machine on the server. When the server received a request it would start processing and if it took more than a few seconds it would return an object with a status report and a request ID. The client would send a browser meta-refresh that would check on the status of the request every few seconds until it was done or returned an error.

      If you're looking for something closer to real-time (a way for the server to initiate contact with the client) check out the BEEP protocol [beepcore.org].

      From the BEEP web page:
      BEEP is a turbocharger for Internet applications that offers advanced features such as:

      • a standard application layer that supports dynamic, pluggable application "profiles" (protocols)
      • peer-to-peer, client-server, or server-to-server capabilities
      • multiple channels over a single authenticated session
      • support for arbitrary MIME payloads, including XML
    • What you describe is possible using XML-RPC or SOAP. Simply have the data source make calls to the "client" when it has new data. And when that happens, the "client" processes the data, whatever. A setup that did this automatically would probably not be much different than this underneath. Simply have the client register itself as wanting the data, etc etc.
      • I was going to post a suggestion similar to this one. Basically, you would need to allow the client to make an RPC call to register a callback function. I've done similar things when I call into a DLL giving it a function pointer so the DLL can call me back and notify me that something has happened. You might need to have the client listen on some port.
    • You could have the XML-RPC client make the XML-RPC call to the server, and simply not have the server return a response until it wants to send data back to the client. Of course, this will only work if the XML-RPC client and server implementations do not have a timeout value. Fortunately, most XML-RPC server implementations do not. You can use Apache's HTTP KeepAlive [apache.org] option to help implement this.
    • > that bugs me is that there's no way to make a call that will return multiple pieces of data over a long period.

      With a SAX-based XML parser, you can stream data back in as leisurely a pace as you want and have your client react immediately to whatever tag delimits your message boundaries.

      As for overhead, I'm in agreement there: the overhead of TCP/IP is definitely minimal compared to the cost of marshalling RPC data to begin with. TCP/IP can be tuned anyway, and it'll almost certainly be faster and m

      • Re:Something XML-RPC (SOAP) doesn't have (Score:5, Interesting)

        by Doomdark ( 136619 ) on Thursday January 01, 2004 @11:38PM (#7857497) Homepage Journal
        As for overhead, I'm in agreement there: the overhead of TCP/IP is definitely minimal compared to the cost of marshalling RPC data to begin with. TCP/IP can be tuned anyway, and it'll almost certainly be faster and more robust than something that tries to reinvent it over UDP.

        Perhaps I misread original points, but it seemed like he wasn't so much worried about overhead, but about time-sensitivity aspect. TCP tries really hard to get all the data get through (with re-sends etc), without worrying at all about delays. It's good for bulk transfers, and things that simply have to get through, but for real-time (or in general time sensitive) data it's pretty useless to get anything that is late. And worse, since there's no way to really know what's going on (from TCP POV, "app shouldn't care"), it's difficult for the app to try to failover or other sensible action to resolve the (likely transient) problem.

        Trying to figure out information about why and how data just isn't getting back, via socket (or whatever) API is next to impossible... thus, protocols such as RTP were developed. It's been a while since I followed what was happening there, but there was definite need for something that would give better control over timing information; at the very least for apps to be able to find out if there are timing problems, and do the right thing whatever it is (mark server as likely being down, find alternatives etc).

        As to overhead, I'd agree; esp. due to HTTP being so ubiquitous, all stacks are ridiculously optimized, and handle "non-optimal" usage of TCP (simple request-reply) rather fine, all things considered.

    • Grid services, which extend SOAP based web services, does provide for this sort of subscriber model.

      Check out: http://www.globus.org/ogsa/ and the globus toolkit.

      Anm
    • I've implemented systems like that, using xml-based asynchronous messaging. A good Service Oriented Architecture (SOA) will do the job for you. Got to be careful though, lots of companies use these buzz-words to describe their existing synchronous products that they've been selling for years (not looking at anybody in particular, Oracle and BEA!)

      You're dead right about the size overhead of XML not being a problem. But the problem with XML is the performance of the standard parsers. XML parsers need to unde

  • You don't mention... (Score:5, Informative)

    by ThenAgain ( 627263 ) on Wednesday December 31, 2003 @07:04PM (#7849758)
    what you've already looked at. Whenever I've been tempted to implement my own RPC mechanism I've found that XML-RPC [xmlrpc.com] meets my needs perfectly.

    It's easily capable of representing objects, platform independent, encryptable (via SSL), compressable (via gzip [and probably SSL as well]), and textual.

    The advantages of being textual in your protocols is well laid out in Eric Raymond's [catb.org] book The Art of Unix Programming [faqs.org]. He even treats it as a case study [faqs.org].

  • NML (Score:5, Informative)

    by kinema ( 630983 ) on Wednesday December 31, 2003 @07:17PM (#7849847)
    You might want to take a look at the Neutral Message Language, NML [nist.gov]. Developed at the Intelligent Systems Division of the National Instute of Standards and Technology is was intended from the start for use in real-time/time critical situations. I know that it currently has support cor C, C++ and Java.

  • Does 6 rule out TCP? (Score:5, Interesting)

    by jrstewart ( 46866 ) on Wednesday December 31, 2003 @07:25PM (#7849898) Homepage
    I think you'll find that in practice a UDP-based solution isn't going to make your life any easier than TCP. You may want to use TCP in conjunction with an external timer to fail the connection well before TCP gives up though. If you tend to do multiple RPCs to the same host the overhead of TCP should be minimal, and you get a lot of functionality (retries, backoff, etc.) for free. There's RFCs for transactional TCP which solves some of the overhead problems for small exchanges but I don't think they're widely implemented.

    If you do end up writing your own UDP-based protocol, take some time to study TCP as well as other UDP based protocols and make sure you write something network friendly. There are a lot of naive protocols which fail spectacularly in less-than-perfect conditions.
    • I'd like to chime in support of this. Having gone down the exact road of implementing something in UDP, make very sure that you absolutely need it.
    • UDP is not connection based so you have no idea a connection was made on the other end. Its kind of a send a forget protocol, unless you want to write your own handshaking in the application.
      Also udps message size limit of 64k might be limiting..

  • #6 is not a killer (Score:2, Interesting)

    by Anonymous Coward
    Just because TCP provides a sequenced, reliable byte stream with no need to transfer data past connection setup does not mean you can't use it to implement your application level requirements. Simply implement a null request with the client demanding a response within X seconds or you declare the peer dead (or effectively dead) and try another (yes this is a little simplistic and can result in livelock under heavy load but adaption, making X depend upon the peer's load and possibly dynamically measured res
  • I am biased, but I think Gled [gled.org] is a very network-efficient and fast GPL'd OO RPC soulution for C++.

    It is in early stages of desing and development, but is fully fucntional and comes with a complete toolkit and devloping framework, including a C++ interpreter (ROOTCINT [root.cern.ch]), visualisation, object collection introspection and streaming interfaces from ROOT [root.cern.ch], autogenerated GUI for system and user C++ classes, object-collection monitor, cluster infrastructure using a hierarchical OO RPC system and visualisation w

  • RPC is rarely worth the trouble. (Score:3, Informative)

    by tyrecius ( 232700 ) on Wednesday December 31, 2003 @07:54PM (#7850085)

    RPC causes untold security/authentication headaches and is often hard to program with besides.

    See ESR [faqs.org]

  • Try Twisted maybe (Score:2, Interesting)

    by LesFerg ( 452838 )
    If you arent scared of 'scripting' languages,
    http://www.twistedmatrix.com/products/ twisted

    Haven't used it myself yet, but from the specs it seems to cover everything you could need.

    • Maybe an even better idea is Pyro [sourceforge.net]?

    • Twisted is Python-oriented. If you need it language-independent then try Jabber. It has all XML-RPC good things, and it's more reliable on a transport layer. Someone will suggest you IBM MQ - functionally it's same as Jabber, just costs lots more dollars.

  • Clue (Score:3, Insightful)

    by Markus Registrada ( 642224 ) on Wednesday December 31, 2003 @08:03PM (#7850151)
    The number of different RPC mechanisms extant should be a clue that
    • none of them are really satisfactory (else people wouldn't feel compelled to keep inventing new ones), and
    • they don't really work out, in practice (else people would be satisfied with one of them).

    The problem with RPC is that, to be useful at all, it has to be used where the function-call abstraction fails. In inter-process communication and (more so) in network communications, there are too many failure modes that just don't fit that abstraction, but that a reliable application needs to handle anyway.

    The whole point of RPC is supposed to be that the code invoking them looks just like regular function calls. To be reliable, though, they need to be decorated with so much error handling junk that any such benefit is usually lost. You're better off with explicit message passing and a documented wire protocol. You need the latter anyway to have a debuggable application.

    • The kind of RPC and IPC problems you mention is what systems like .NET have been designed to solve.
      • The kind of RPC and IPC problems you mention is what systems like .NET have been designed to solve.

        You're not paying attention. Lots of "systems like .NET have been designed to solve" the problems. Those systems always fail. The next person comes along and finds the same problems, and says "I'm designing an RPC system...". That's why we have so many.

        Clue.

    • If you want to have two completely anonymous, very large systems talk to each other, SOAP isn't a bad way to go. But how many of us are working for giant firms that require building hooks into our system for a completely anonymous client?

      Do note that you can also substitute "anonymous client" with "corporation with a heck of a lot of red tape".

      As another post in this thread [slashdot.org] has already well put, SOAP is the compromise product of a number of these giant corporations. It doesn't do nearly so well when you

  • Take a look at CORBA (Score:3, Informative)

    by (H)elix1 ( 231155 ) <slashdot.helix@nOSPaM.gmail.com> on Wednesday December 31, 2003 @08:08PM (#7850177) Homepage Journal
    It has been a long time for me, but CORBA [omg.org] might fit the bill.
    • Ugh, except CORBA is a huge pain in the ass compared to SOAP or XML-RPC. Does a lot more, though. Shame there isn't something inbetween, more power and flexibility but as easy to use as SOAP or XML-RPC. Languages with decent introspective/reflective capabilities should make it relatively easy to implement such a system.

  • SunRPC ;) (Score:3, Interesting)

    by noselasd ( 594905 ) on Wednesday December 31, 2003 @08:10PM (#7850201)
    Well I reccomend the good old time SunRPC.
    It doesnt have 1. though that depends on what you mean by
    "object oriented". I sense you want do export your C++ objects ;) There are other ways of doing OO..
    It is somewhat lacking in 4 and 5 , though GSS-RPC will give you both. It is also not that difficult to implement authentication providers for sunrpc.. And for those that hate the portmapper, you don't have to use it. Another + is that it's small and fast. And you can do rpc over unix domain sockets, easing the pain to create custom protocols for interproces communication on the local box.
  • Have you looked at Java RMI or Jini?

  • Do We Really Need Another Program? We have so many already... thousands... millions!

    I do not think it is a good idea to try to create one "mechanism" providing options along the dimensions of security, performance, reliability, simplicity, portability, expandability, elegance, extensibility, etc, etc. If "separation of concerns" and "aspect oriented design" is still trendy, then I use that as proof by reference.

    Larry

  • #6 (Score:3, Insightful)

    by sohp ( 22984 ) <snewton.io@com> on Wednesday December 31, 2003 @09:58PM (#7850677) Homepage
    Effective dead connection detection and failover is a Hard Problem in general. Asking for a general-purpose RPC mechanism that solves this problem is asking quite a lot. Perhaps it would be worth re-examining the requirements for the system that lead to asking for failover, and considering what other solutions to those requirement there might be other than robust failover.

  • The problem is your requirements (Score:3, Insightful)

    by mnmn ( 145599 ) on Wednesday December 31, 2003 @10:33PM (#7850828) Homepage
    RPCs are inherently insecure and introduces a balancing act of keeping the algorithms secure while keeping an eye on inputs and making sure nothing gets memory-leaked.

    All this overhead also will take resources. So whats is it exactly youre working on that needs RPCs? Most networked applications Ive seen doesnt need RPCs, especially ones that are secure and efficient.

  • Try zeroc's ICE (Score:1, Informative)

    by Anonymous Coward

    You should have a look at zeroC [zeroc.com]. I haven't used it but have had very good reports about it. Plus the licensing is purely volume based or free if your product is open source.

  • #7 rules out wsdl / SOAP, but using this kind of concept, it may be a role your own. Use binary or text transfer. HMMM DNS query rings a bell? SMTP / POP3 protocols are cross platform, and all text, and all can be secured using ssl. Yes they work over tcp, but I'm sure one could code the connections over udp instead.

    Something like:

    COMMAND: getStockQuote
    PARAM COUNT: 1 PARAM 1: MSFT END COMMAND

    This is the basic principal of POP3 / SMTP and could be extended to allow for RPC. Each side would have to know

  • Why does it have to be OO? You could put OO wrappers around it on your own, no? It is hard for inter-language communications to be OO anyhow because OO is mostly about behavior wrapping data; but you will generally need "naked" data between two potentially different languages and/or systems for them to communicate. Making language-specific protocols is generally tougher because it reduces the number of users/testers/buyers, etc. than a multi-language multi-paradigm-friendly approach.

  • ICE? (Score:1, Redundant)

    by AtrN ( 87501 )
    Have you looked at ICE [zeroc.com]? The developers are long time CORBA gurus who set out to fix some of CORBA's problems. It looks quite promising but then I haven't used it in anger.

  • Message Queuing Server? (Score:4, Informative)

    by psykocrime ( 61037 ) <mindcrime@cpphacker . c o .uk> on Thursday January 01, 2004 @02:20AM (#7851495) Homepage Journal
    You could probably implement what you want using
    some type of message queuing server, like IBM Websphere MQ, or equivelant.

    As a mental exercise, and to make sure I'm not talking out my ass, let's run down your list of requirements:

    equirements are:

    1. object oriented

    Well, in the case of Websphere MQ, I'd say "yes" to this one, at least partially. There is a C++ based client library, IIRC, a (IBM specific) Java client library, and a JMS client. And even if the client libraries weren't OO, you could write OO wrappers for procedural calls more easily than writing your own RPC mechanism from scratch, I think.


    2. extensible

    Check. If you use pub/sub messaging instead of point to point messaging, even more so. And if you use a message type (MapMessage in JMS) that is based on name / value pairs, it's easy to extend your messages without breaking backwards compatibility.


    3. platform independent

    Not completely, but with both Java and C++ clients available, you should be able to support most everything.


    4. supports signatures for integrity and sender checking

    Not sure if it has native support for signatures, but a signature can always be added to a message as a property.

    5. supports privacy of the message contents (i.e. encryption)

    Again, using Websphere MQ as an example, it does support the use of SSL for communications, if that helps meet your requirements.


    6. time sensitive: I should be able to detect a dead server and do failover while the user is waiting for the response

    You're right, that's the tricky one. I think there are ways to achieve this goal using message passing servers, but it might take some work.


    7. bandwidth efficient, as I am looking to deploy it in wireless environments

    I think this requirement is met as well. Most messaging products support a message type that is nothing more than a stream of bytes that you interpret as you will... and even if you use a slightly move involved message type (MapMessage or StreamMessage to use JMS types as examples) you're still not carrying a lot of overhead.


    Now #1-3 are no problem, #4 and #5 can be found, and #7 rules out anything XML-based. #6 seems to be the killer, as this rules out anything over TCP, and at that point the list gets pretty short.

    Depending on just how "time sensitive" #6 really is, I do think you could come up with a solution using a message passing server. If you're able to use Java for the clients, JMS makes doing an RPC style messaging very easy, using the QueueRequestor and TopicRequestor interfaces. And even if you can't use Java, it shouldn't be to hard to cook up your own request / reply mechanism, built on top of the messaging system.
    • and go as far as to say JMS would probably achieve exactly what you want to do, and using Java is a good idea. JMSExpiration, JMSPriority and JMSTimestamp are some of the header fields that might help with the time-sensitivity. In addition, JMS can provide some delivery guarantees, and persistence.
      Check out openjms:
      http://openjms.sourceforge.net/
      or the JBoss impl. for starts. Plus it's more fun that CORBA/DCOM/RMI.

  • Messaging (Score:2, Informative)

    by kruntiform ( 664538 )
    I think that messaging is nearly always a better solution than RPC, especially for wireless where the network might not be very reliable. I've been playing with Spread [spread.org] recently. It looks pretty good.

  • binary RPC (Score:2, Informative)

    by Ooobles ( 698677 )
    It's true. There has been very little research done in RPC mechanisms. In November I attended three different conferences (two on distributed computing) to see what work was being done. Most research is in either building on top of CORBA or XML and web services. Infact, I was disapointed at the lack of research in the low level guts of RPC mechanisms.

    The reason I attended the conferences is that I have spent a lot of time developing a binary RPC mechanism. The method I use can be used in messages (eg
  • Hi,

    You're looking for an Object Oriented RPC language but you forget to tell us what language you're actually coding for. Objects in C++ are very different from Objects in Java, Python ... you get the picture!

    Also, to get better input it'd by nice to know why exactly you need an RPC! Perhaps you have chosen to have one to solve your problems?

    Regards!
    • The RPC mechanism should be independent on the platform, which for me includes the language. So the object description should come with the mechanism and map to the language. Maybe I should have stated this explicitly.


      I need the mechanism to communicate between nodes in a distributed telecommunications-type application. I opted for looking at one RPC mechanism rather than invent a slew of new protocols.

      • The RPC mechanism should be independent of the platform
        Why? (if this is a special-purpose kind of project). Are you going to be using different programming languages or OSs for this task? Why would you program the various nodes in different languages or on different platforms?
        • This is to be an open system and probably end up to be quite large. I will not create all nodes. As the system grows it will aquire nodes from different sources. Each source will choose their own OS and language.
          • Well, I guess binary XML is a serious option as someone already said. Possibly combined with any reliable datagram protocol (TCP may not be slow if combined with some form of multiplexing and reusing of individual connections). Have you considered this?

            It would have been really great if you mentioned the protocols you have already ruled out and the ones you are considering. Best of luck to your project!

  • CORBA or RMI/IIOP (Score:3, Informative)

    by Hard_Code ( 49548 ) on Thursday January 01, 2004 @11:06AM (#7852739)
    CORBA fulfills essentially what you describe (not sure about #4). However, the CORBA spec is fairly large and baroque, so you are going to eat some overhead in complexity (not necessarily performance!) if you choose CORBA.

    RMI is also a nice spec. Contrary to popular belief RMI is not a wire protocol but simply a spec for an RPC interface. The standard implementation uses a specific wire protocol and is tied to Java. However, RMI/IIOP also comes standard and is transparently interoperable with CORBA. I'm sure if you wanted to you could write your own transport implementation.

    XML-RPC and SOAP are not really OO RPC mechanisms (despite SOAP containing the word "object" in it). SOAP is a bloated compromise spec created by committee by a few large players in the industry to satisfy all their requirements, and hence does not really enforce any sort of object or typing system. Already I see people addled by XML-think outright proposing this protocols. If it fits your project go for it, but XML is not the panacea people think it is.

    • Re:CORBA or RMI/IIOP (Score:3, Informative)

      by joonasl ( 527630 )
      XML-RPC and SOAP are not really OO RPC mechanisms (despite SOAP containing the word "object" in it).

      Actually it doesn't contain the word "object" anymore, since W3 realized that the original name "Simple Object Access Protocol" was a bit misleading and the newest version of the spec does not expand the acronum anymore. So now SOAP is just SOAP :)

  • Take a look at Ice (Score:2, Redundant)

    by be-fan ( 61476 )
    You can find Ice at this page. [zeroc.com] From what I've seen, it's everything CORBA should have been, and easy to use to boot!

  • Endian-ness (Score:3, Interesting)

    by Nynaeve ( 163450 ) on Friday January 02, 2004 @09:20AM (#7859580)
    Keep in mind that if you are truly cross platform and your communications are pure binary, then endian-ness will be an issue. I had to deal with this once when passing messages from a MIPS SGI to an x86 PC.

    It can be a real pain when the underlying communication protocol blindly assumes endian-ness is the same on every machine. I prefer text-based protocols because they alleviate that problem.
  • Disclaimer: I'm a Team RO member.

    Check out RemObjects [remobjects.com]. It's really a brilliant piece of software and is the first RPC development system I've used that's been a real joy to work with.
  • I rather like QNX messaging, which is a good, low-level mechanism, and one that's much faster than most of the alternatives.

    QNX messaging reliably passes an arbitrary-length string of bytes from a client to a server, waits for a response, and returns another arbitrary-length string of bytes from the server. This is the basic primitive of the QNX operating system. Everything, including I/O, uses it. It's integrated with scheduling, so if you do a MsgSend to another process that's waiting in a MsgReceive,

  • What you're looking at is a client/server set accompanied by a custom protocol. If you're wanting to work with keeping the client synched up with a server, you could look at SyncML.

    Alternatively, you could use HTTP and set the refresh time-out to automatically poll the server for refreshes. Send your data in HTML/WML/xHTML/cHTML/whatever and let the client deal with interpreting it. Mod your client to provide a default error page if the refresh times out.

    Done.

  • CORBA (Score:2, Informative)

    by BeerMilkshake ( 699747 )
    I am a big fan of CORBA, though I admit it has some issues.

    > 1. object oriented

    CORBA is definitely object-oriented. Much better than XML and SOAP (SOAP is -NOT- OO at all). I love the fact that once you have a reference to an object, it does not matter where that object is.

    > 2. extensible

    Yes. There are many useful (and optional) services available for CORBA. You don't pay for what you don't use with CORBA, so if you don't require a Naming Service or a Transaction Service, you don't have to include
    • > - complexity. It is definitely not for the beginner and has a large initial learning curve. If you write client-side stuff, it is heaven. If you write server-side stuff, prepare yourself. If you want to do CORBA-compliant fault tolerance or security, don't call me :)

      I wouldn't say "heaven" myself :) There are *many* issues around CORBA's complexity:

      - the insanely complex C++ mapping
      - bloated and complex run-time APIs
      - inefficient protocol
      - far too complex type system
      - missing features
      - inefficient a
  • Perhaps you find this article interesting: "A New Approach to Object-Oriented Middleware [zeroc.com]". This article appeared in the IEEE Internet Computing magazine, and compares Ice [zeroc.com] with CORBA [omg.org].

Slashdot Top Deals

"The only way for a reporter to look at a politician is down." -- H.L. Mencken

Close