savas parastatidis

Web Services are RPC?

Continuing the exchange of comments with Michi Henning here are some more thoughts.

Michi argues that "WS is *RPC*, by definition" . This is a definition that I haven't come across. I personally see a big difference between a request-response message exchange pattern and a Remote Procedure Call. The SOAP processing model and the focus on messaging allow us to move beyond RPCs/RMIs and do so much more. Jim and I have tried to illustrate some of the thinking and possibilities with MEST and SSDL. I definitely don't equate Web Services and SOAP with RPCs. This topic has been exhausted and there are so many smart people out there telling us that RPC systems are not good for inter-organisation and scalable solutions or even for distributed computing (e.g. Waldo's paper ). There is nothing RPC-like in the SOAP processing model. Yes, SOAP can be (mis)used as a way to implement RPC systems but that's not inherent in the protocol. Which reminds me... we don't treat SOAP as a transport protocol but as a message transfer protocol. That's why we have to talk about SOAP over HTTP or over TCP/IP etc.

I don't understand why we should treat the issue of SOAP performance in isolation from everything else that it has to offer. Wide-adoption is a very important aspect of XML and SOAP. As I asked in my previous post, why doesn't anyone complain about the performance cost of C++/Java/.NET over assembly programming? There is a huge advantage in modularisation, productivity, maintenance, reuse, etc with high-level programming languages/runtimes. That's why we accept the added performance penalty from moving to new levels of abstractions for building systems. The same applies to distributed computing. Yes, one could build fast distributed applications using CORBA and ICE and sockets. Put enough care and such systems could even scale. However, how about cross-organisation integration? How about new abstractions for building distributed systems? How about tooling? Do we care if a protocol implementation can saturate the network if the organisation next door doesn't understand it. When compared to the cost of communicating over the high-latency Internet, is the difference between SOAP processing and an optimised communications protocol so relevant given the interoperability, wide-adoption, tooling, etc. benefits? (Please note that I am not arguing in favour of completely ignoring performance). Yes, inside the firewall it may be possible and beneficial to build using CORBA or ICE or sockets solutions. If everyone had agreed on a very fast binary protocol, I would have been very happy. Would it have happened had XML not been around? I seriously doubt it. XML is here to stay, at least for the next decade or so.

Am I "running with the herd" as Michi suggests? Perhaps. But when that herd is the larger part of the industry I am happy to do that. And yes, the fact that even hardware vendors are investing in the XML processing solutions tells me how serious the industry is in making this SOAP thing work. So, I am happy to go to new places with the rest of the herd. I don't want to stay at the old valley with no grass. I am excited about the opportunity to find new grass, help in making the herd larger, and get to know new places. The herd shows me that there is enough interest in investing to make sure that we reach the new destination so I can come up with new ways of building distributed applications. If I had believed that the herd was going towards a swamp, I would have said so. I have gone against the flow in the past 🙂

BTW... Michi, please have a look at Indigo . You'll see why I made the comment about Microsoft and SOAP. Also, I suspect that other companies may be doing something very similar for their distributed computing platforms. It absolutely makes sense.

Is it irresponsible to support that document-centric solutions based on XML (either MEST - or REST -based)? As things stand at the moment, I don't believe so. However, history will show us how wrong the SOAP advocates have been.

UPDATE (5 July 2005, 23:38 BST): This is Michi's response to the above post sent to me via email with a request to publish it here rather than as a comment given my weblog's limitations of accepting formatted comments (will try to correct this soon).

Savas, could you please explain to me how SOAP is *not* RPC? With SOAP, a client takes some parameters, invokes a service on a remote endpoint, the service processes the data, and eventually returns results. (Typically, the client blocks until the results are available, although it could use async invocation.) How is this different from CORBA or Ice? Or, to ask the question differently, what exactly is the the "request-response message exchange pattern" you mention and what exactly does SOAP do to support this that CORBA or Ice do not?

As to SOAP performance, it is atriocious, and unnecessarily so. We could have everything WS and SOAP can do, but much faster, if we didn't use this idiotic protocol.

I also disagree with the assembly programming analogy. In fact, to me, it seems that many aspects of WS are much more complex and tedious than CORBA or Ice. Take WSDL-I wrote about some of its problems in issue 2 of our newsletter (http://www.zeroc.com/newsletter/issue2.pdf).

"And yes, the fact that even hardware vendors are investing in the XML processing solutions tells me how serious the industry is in making this SOAP thing work."

No, I don't see it like that at all. What has really happened is that the industry was silly enough to adopt an incredibly inefficient encoding. So inefficient, in fact, that a market window has opened for hardware vendors because software isn't good enough to get the performance. The fact that people build hardware to support XML processing in no way vindicates the technical choices that were made. Rather, it does condemn those choices.

"Is it irresponsible to support that document-centric solutions based on XML (either MEST- or REST-based)?"

No, of course not, and that is not what I said. But it *is* irresponsible, IMO, to tell people that SOAP is fast, that everyone should be using it, and to dismiss arguments that show it to be an extremely poor protocol.

There are only a few distributed computing experts in the world. The whole industry looks to these experts for leadership. To me (counting myself as one of these experts), that imposes a moral obligation to judge things openly and honestly, taking past experience, research, and best practice into account to the best of my ability. As an expert, I cannot honestly recommend a protocol that requires a hundred times the bandwidth, CPU cycles, and latency of other protocols, especially when there is no functional gain for all that overhead.

7 responses to “Web Services are RPC?”

  1. Mark Little
  2. Mark Baker
    I agree with Michi if he’s trying to say that all interactions necessarily have a contract; I ask that you do something, and you either do it and tell me the results, or don’t do it and tell me so. I disagree with him if he means that all systems necessarily require services to have unique interfaces. I expect he means the former though.
  3. Michi Henning
    I meant the former, but I would also say that all services ultimately have to have a unique interface. It’s just a matter at what level I choose to express and enforce that interface. The classic example is a service that requires an integer and a string as input. If I send it two doubles instead, things won’t work. I can enforce this type requirement at various levels: very early, using WSDL or IDL, or very late, in the application. For example, I can change the early contract to simply require a single string, and then parse that string at run time, to see whether it successfully decodes into an integer and a string (or incorrectly into two doubles). That’s essentially the idea of using XML as an encoding. The question is whether that’s a good thing or a bad thing. The past thirty years of language and systems development seem to show overwhelming evidence that early typing is better in the majority of cases. So, in some ways, we can view the OO-RPC vs WS debate as a debate of early vs late typing and granularity. My point is that I can use late typing and coarse granularity with any RPC system, whether that’s CORBA, Ice, or WS. But I fail to see why we had to choose a protocol as atrocious as SOAP to do it with. And I also fail to see why we had to go and reinvent a completely new wheel with lots of corners (SOAP, WSDL, and slew of other things), when we could have built service-oriented architectures all along… Cheers, Michi.
  4. Mark Baker

    I hear you, Michi. As the guy promoting (re)using the Web for large scale integration, I can emphasize with your desire to see more reuse of existing systems … we just disagree on which systems to reuse. 😎

  5. Steve Vinoski

    From a purity perspective (which has to be relevant given that this entire thread is all about technical purity), RPC and request/reply messaging are not the same thing. RPC is really about the programming language level. The original insight of RPC was, of course, that your code calling that remote function could look just like it was calling a normal local function (which we now know, of course, is not entirely true due to the partial failure semantics of the network). RPC has request/reply semantics, because that’s how local procedure/function calls usually work. However, you can have request/reply without having RPC. For example, you can support request/reply with an asynch message queuing system by setting up two queues, one for requests and the other for replies. The code for dealing with that doesn’t look at all like it’s calling a local procedure.

    SOAP is certainly not a programming language issue; therefore, technically, SOAP is definitely *not* RPC.

  6. Steve Vinoski

    Oh, and one other comment. Savas is right, and Michi is way wrong, regarding the fact that people are building hardware XML processors. Michi claims it’s a reaction to SOAP’s slowness, but that’s not it at all. It’s not as if someone said, “Gee, this stuff is slow, so I’ll throw some hardware at it to speed it up.” I have some friends in that business, and they started a number of years ago, well before anyone had deployed enough applications to know whether performance was an issue or not. Rather, hardware approaches in this space are driven mainly by the fact that there’s such broad agreement on this stuff across the industry that it makes deploying solutions in hardware a viable business.

  7. Arno

    I think many Webservice evangelist have failed in explaining when to use Webservices (and when not), and how to achieve loose coupling by SOA and document-oriented approaches.

    I know of several projects where – thanks to all that hype around it – Webservices are completely misused, and serve as nothing else than just another intranet / single platform RPC protocol (where IIOP or DCOM would be much better suited).

    Webservices are for integration, not for inter-tier distribution!