{"id":886,"date":"2005-08-08T11:11:00","date_gmt":"2005-08-08T15:11:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/2005\/08\/08\/http-fails-soap\/"},"modified":"2005-08-08T11:11:00","modified_gmt":"2005-08-08T15:11:00","slug":"http-fails-soap","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2005\/08\/http-fails-soap\/","title":{"rendered":"HTTP fails SOAP?"},"content":{"rendered":"

Via Steve<\/a>, a link to an article on\nWhere HTTP Fails SOAP<\/a>.<\/p>\n\n

My comments…<\/p>\n\n

\nSimple Web browsers have been the de facto HTTP client to date, and they are in essence single-threaded clients as far as the server is concerned, making only one request at a time over a given connection.\n<\/blockquote>\n\n

Hmm, that might have been so in the very early days, but browsers have\nused multiple outgoing connections for some time. I just checked Firefox,\nand its property for this – network.http.max-connections-per-server –\nhas a default value of “8”.<\/p>\n\n

Also, if you’ve ever written one, a browser is far from “simple”.\nIn fact, the most complex code I’ve ever worked on was a browser.<\/p>\n\n

To back up its claim that SOAP\/HTTP can’t scale in some circumstances,\nthe article describes a scenario;<\/p>\n\n

\nFor example, assume we have an online banking system with support for up to 4000 concurrent users. The Web tier comprises a cluster of application server instances behind a hardware HTTP load balancer. In order to fulfill the online banking business function, there are three Unix-hosted services and a mainframe-hosted service utilized by the application server. In a world where SOAP\/HTTP is the only protocol, the application server will have to support an incoming connection from the browser, and one additional connection out to each of the four back-office services for each concurrent user. This is because HTTP demands that you wait for a response before you send your next request over that same connection. It has no concept of a request identifier, which is a core requirement to enable connection sharing.\n<\/blockquote>\n\n

First, what’s so hard about 8000 (or even 10000) connections<\/a>?\nSecond, HTTP doesn’t demand that you “wait for a response before you send your next request”, all it\nrequires is that the server not send a response to a request before the responses to previous\nrequests are sent. But a smart Web server could facilitate processing of requests in parallel in\nsome situations. And thirdly, who’s to say this has to be synchronously, and some AJAX couldn’t\nspice up the UI to save on long-lived connections?<\/p>\n\n

That’s not to say that I disagree with their conclusion that “a standards-based\nprotocol that allows for request interleaving is needed”. Indeed, I do agree with them.\nIt’s just tricky to deploy, as the community\ndiscovered when the ability to remove this constraint from HTTP was\nspecified<\/a>.\nAs it turns out, extensions which require the reimplementation of both client and\nserver connectors don’t get much love – go figure!<\/p>\n\n

What’s needed is a replacement protocol. And any which provided the value of\nHTTP, but without this ordering restriction, would be fine with me.<\/p>\n\n

Unfortunately, they mis-read the HTTP spec when summing up;<\/p>\n\n

\nThis problem has been solved in the past with connection concentrators, but because we cannot interleave HTTP POST requests, HTTP-based communication cannot be concentrated. Clearly, HTTP is not capable of scaling in such an environment.\n<\/blockquote>\n\n

Nope. What the spec says regarding pipelining and POST is;<\/p>\n\n

\n   Clients SHOULD NOT pipeline requests using non-idempotent methods or\n   non-idempotent sequences of methods (see section 9.1.2). Otherwise, a\n   premature termination of the transport connection could lead to\n   indeterminate results. A client wishing to send a non-idempotent\n   request SHOULD wait to send that request until it has received the\n   response status for the previous request.\n<\/pre>\n\n
That’s “SHOULD NOT”, not “MUST NOT”, and the reason is to avoid the\npartial failure problems that would result from the pipelining of\nnon-idempotent\/unsafe requests.  It’s not a matter of interop.\n\n
And FWIW, this isn’t “interleaving”, which generally refers to the\nuse of logical streams within a single physical stream.  Pipelining\nintroduces no logical streams.<\/p>\n\n
It’s good to see them reference Waka too though, but it’s in a\nvery odd context where they discuss protocols such as IIOP, JMS,\nand MQSeries.  Note to authors; those are not HTTP replacements,\nbecause they are not application protocols.  If somebody offered\nyou a carrot for your Ferrari, would you take them up on it?  Didn’t\nthink so.<\/p>\n\n
It’s clear the authors did their homework, which is wonderful.\nUnfortunately though, they fell right into that “protocol independence”\ntrap, along with much of the rest of the industry.<\/p>","protected":false},"excerpt":{"rendered":"Via Steve, a link to an article on Where HTTP Fails SOAP. My comments… Simple Web browsers have been the de facto HTTP client to date, and they are in essence single-threaded clients as far as the server is concerned, making only one request at a time over a given connection. Hmm, that might have […]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-886","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-soap"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/886","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/comments?post=886"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/886\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=886"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=886"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=886"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}