SOAP/HTTP Scalability

, Aug 6, 2005

Steve Vinoski points to this article about the issues with scaling up SOAP/HTTP. The arguments about HTTP are valid, but I disagree with the conclusions:

  • The connection sharing problem seems to be a non-issue for most real-world use-cases — if the client runs on the end users’ computers, I find it hard to believe that someone would argue that HTTP doesn’t scale; if it’s server applications that communicate, I don’t think one would have a need for more simultaneous connections than in the client/server case.
  • SOAP is not restricted to use HTTP POST, so optimizations available for GET over HTTP 1.1 are available.
  • Finally, I can see the point in using SOAP in conjunction with a reliable transport, such as JMS. But using SOAP over IIOP is probably about as interoperable as rolling your own protocol. But given who’s their employer, it’s not entirely unobvious why the authors suggest it …
On August 10, 2005 9:57 PM, Eric Newcomer said:

Stefan,

I look forward to seeing you at the DP SOA days next month…

Just to point out though that IIOP is indeed interoperable, and multiple interoperable implementations exist. This includes multiple CORBA implementations of course, RMI/IIOP in the J2EE world, and even .NET IIOP from the open source world:

http://iiop-net.sourceforge.net/

Using IIOP achieves better interoperability than JMS, since JMS is only an API (and only for Java at that) and doesn’t specify a wire protocol.

So I would turn the question around and ask what other fast, reliable, multilanguage, standard enterprise quality wire protocol would you run SOAP over, instead?

I suppose the reason that SOAP, WSDL, WS-Addressing etc. have been designed for use with multiple transport protocols is that most Web services vendors anticipated using SOAP over at least one other proprietary transport. And most likely for the purpose of bridging HTTP to MQ or JMS or something similar when you “cross the firewall.”

But architecturally there is no reason why you can’t run SOAP as a data format over multiple transport protocols in a transparent fashion — not just as a bridge but as a switch and therefore eliminate such “barrier” thinking — and of the choices available IIOP has a better chance at interoperability than anything else I know of in its class.

Eric

On August 10, 2005 11:12 PM, Stefan Tilkov said:

I’m looking forward to continuing the discussion face to face as well ;-)

I have nothing against IIOP — in fact I think it’s a nice protocol for what I perceive to be its intended use case, namely distributed object computing. I just don’t see the benefit of using SOAP over IIOP, given that this combination is only supported by very few vendors (as far as I’m aware, please do correct me if I’m wrong).