Monthly Archives: August 2005

Dispatching "weakness" with doc/lit in WSDL

On axis-user, somebody just posted a link to an old but interesting article titled “Which style of WSDL should I use?”. I had a chuckle at one part, when the author was describing the pros and cons of doc/lit. He used this example message;



… and then wrote this as one of the “weaknesses” with it;

The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.

Yes, heaven forbid that you might have to go to the extreme expense of minting a new endpoint (URI)!

For those playing along on the home-game, that’s now at least two folks who’ve stared truly document oriented services right in the face, but blinked.

Microformats by any name

I can’t recall where I found this, but here’s a really brain-dead simple interface to Google Maps (details here).

What this is, is a microformat-style, HTML-based declarative front-end onto Google Maps. Check out this sample code for placing labelled markers;

<div class="GMapEZ GSmallMapControl GSmallMapTypeControl"
    style="width: 300px; height: 300px;">
  <a href=",-85.144740&spn=0.006130,0.009795&t=k&hl=en">

  <a href=",-73.937988&spn=6.276505,5.552490&hl=en">
  <a href=",-87.637939&spn=6.169597,5.552490&hl=en">

  <a href=",-118.179932&spn=6.874500,5.552490&hl=en">


So the labels become the content of the anchor element. Neat. A better microformat design might have been to use “ol” (ordered list) with some styling (“list-style-type: upper-alpha”) to get the incrementing-letter result (at least for that simple case). And I’m not sure the G* “controls” really fit best in “class” (though nothing better comes to mind – hmm, what’s good for annotation-like semantics?). But this is definitely in the spirit of microformats (even if the word isn’t mentioned), and very well done.

This approach is going to be huge.

HTTP fails SOAP?

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 been so in the very early days, but browsers have used multiple outgoing connections for some time. I just checked Firefox, and its property for this – network.http.max-connections-per-server – has a default value of “8”.

Also, if you’ve ever written one, a browser is far from “simple”. In fact, the most complex code I’ve ever worked on was a browser.

To back up its claim that SOAP/HTTP can’t scale in some circumstances, the article describes a scenario;

For 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.

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

That’s not to say that I disagree with their conclusion that “a standards-based protocol that allows for request interleaving is needed”. Indeed, I do agree with them. It’s just tricky to deploy, as the community discovered when the ability to remove this constraint from HTTP was specified. As it turns out, extensions which require the reimplementation of both client and server connectors don’t get much love – go figure!

What’s needed is a replacement protocol. And any which provided the value of HTTP, but without this ordering restriction, would be fine with me.

Unfortunately, they mis-read the HTTP spec when summing up;

This 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.

Nope. What the spec says regarding pipelining and POST is;

   Clients SHOULD NOT pipeline requests using non-idempotent methods or
   non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
   premature termination of the transport connection could lead to
   indeterminate results. A client wishing to send a non-idempotent
   request SHOULD wait to send that request until it has received the
   response status for the previous request.

That’s “SHOULD NOT”, not “MUST NOT”, and the reason is to avoid the partial failure problems that would result from the pipelining of non-idempotent/unsafe requests. It’s not a matter of interop.

And FWIW, this isn’t “interleaving”, which generally refers to the use of logical streams within a single physical stream. Pipelining introduces no logical streams.

It’s good to see them reference Waka too though, but it’s in a very odd context where they discuss protocols such as IIOP, JMS, and MQSeries. Note to authors; those are not HTTP replacements, because they are not application protocols. If somebody offered you a carrot for your Ferrari, would you take them up on it? Didn’t think so.

It’s clear the authors did their homework, which is wonderful. Unfortunately though, they fell right into that “protocol independence” trap, along with much of the rest of the industry.