For those of you who don’t like doing messaging in the ‘http://schemas.xmlsoap.org/soap/envelope/’ or ‘http://www.w3.org/2003/05/soap-envelope’ namespaces (SOAP 1.1 or 1.2 for the XML-impaired), here’s something exciting in the Atlas + WCF space. (via Steve)
9 responses to “POX using WCF”
Egads! When I read this there’s a little voice inside my head quietly chanting “Waldo, Waldo, Waldo”. 😎
There is no pleasing you Mark, is there? :-))
I see what you mean and i agree with you up to a point. I believe in providing technology to enable all approaches and then educate folks about which approach should be used when and why. WCF for example, could be used in many different ways (e.g. as a way to hide the remoteness of objects but also to do explicit messaging).
Now, since Waldo was mentioned… aren’t HTTP libraries in any environment inherintly synchronous given the nature of HTTP GET/POST/etc.? Wouldn’t any httpGet() operation have the same disadvantages as RPC as per Waldo’s arguments?
I’m just pickier than most. 😎
Synchronicity isn’t such a big problem in practice from a Waldo POV. And from a Gray POV, it’s a saving grace.
But the Waldo implications go much deeper than that. For example, in the WCF/Atlas example where the string is returned by the echo service, there’s an implicit assumption that the string is atomically buffered (and maybe even sent – not sure of the details of how errors are reported). Yet using a network requires exposing flow control … or else losing data. That’s at least part of the reason why most mature, general purpose HTTP libs manage responses through response objects, and not through data returned on return().
While i agree with you about the leaking of control flow semantics onto the network through the programming model, i do think that synchronicity as it is encouraged by protocol design plays a key role. Unfortunately a request-response-based design over the same communication channel makes people think in terms of a function call and hence the leaking of the control flow semantics.
WCF does offer a way to abstract through the asynchronous version of an interface which is very close to the event-based model for incoming messages i have been talking about.
Hmm, I think we’re disconnected. I didn’t mean “control flow”, I meant “flow control”.
And I don’t agree that “function call” is the problem; any architecture supporting services has to offer function calls by definition (service=function). But I agree that binding the function response to a protocol response does leak control flow as you say, and that’s not always good. On the other hand, the Jim Gray reference was to his claims that synchronicity in distributed computing reduces complexity. On balance then, for most apps, I’m happy to go with reduced complexity.
I don’t understand why you would want to build an asychronous system considering how diffcult it is to make it fault tolerant, see “Impossibility of Distributed Consensus with One Faulty Process”, http://www.podc.org/influential/2001.html.
I get confused by what people mean by asynchronous and synchronous systems – in an asychronous distributed system the only coupling in time is that messages arrive after they are sent (which leads to responses arriving after requests are sent). As such HTTP, though a request-response protocol, is not a synchronous protocol, it is asynchronous – the HTTP spec (http://www.w3.org/Protocols/rfc2616/rfc2616.html) sets no timeouts or lifetimes, in contrast to a synchronous protocol like TCP (http://www.ietf.org/rfc/rfc0793.txt) which does.
The issue of fault tolerance with HTTP is clear, if you visit a web site and the hour glass sites spinning for a while you either hit reload, give up or some browser default timeout kicks in. You cannot tell whether the site has faulted or is just really slow – the same issue which prevents distributed consensus in an asynchronous system.
Of course most sites realise this is an issue and try and get the response back in “reasonable period of time”. Google set themselves a minute to return the results of a query, if you don’t get results back in a minute you can assume something is broken – so although HTTP is an asychronous protocol but people treat it as sychronous. Nobody waits, and nobody expects anyone to wait, more than five minutes for a web page – the server can use a 202 of course.
One very cool HTTP library I have used is Perl’s LWP::Parallel (http://search.cpan.org/~marclang/ParallelUserAgent-2.57/lib/LWP/Parallel.pm) it allows you to send mutliple requests simultanously – you can either block waiting for the responses then process them or you can set up call-back functions. It doesn’t look very RPC to me – note timeouts are defined by the user not the protocol.
We also have asychronous/sychronous functional calls but that is somthing else though….
awaiting flames 🙂
Interesting post, Mark. Because HTTP as deployed is used over TCP, and unused TCP connections timeout, then parties communicating via HTTP/TCP know, a priori, that there’s an upper bound on their wait times (30 minutes was pretty common a few years ago, AFAIK). That makes it practically synchronous, does it not? I agree that the HTTP spec itself is asynchronous… though thinking about it now, if it supported out-of-order responses then that would make it more asynchronous in practice because wait times from a TCP POV would be decoupled from wait times from an HTTP POV. Hmm, not sure of the implications of that… Interesting.
Mark…
So, tcp leaks up into the HTTP spec – but thats OK cause the HTTP authors have nicely integrated them. I think this is always the case, properties of lower layers of the stack leak (diffuse might be a better word) into the upper layers – I think this is why it is hard to design WS-Stuff without thinking about the lower layers, end-to-end arguments and all that jazz.
Good point about responses must be returned in the order requests were sent, this does make it more synchronous – though the use of the same channel to send mutliple requests without waiting for responses is pure optimisation, but it works. Of course clients can open new connections for each request if they want…
Can you break the HTTP rule about responses being in the same order as responses if you are using SOAP and WS-Addressing and the MessageID/RelatesTo stuff – or do the properties of HTTP leak up the stack 😉
Why does HTTP not use a MessageID type HTTP Header in the Request and RelatesTo type HTTP Header in the response to allow out of order delivery of the responses?
Mark,
Hey, if you’re using WS-Addressing, you’re already thoroughly screwing the Web over, so what’s another one? 😎 But no, you shouldn’t, nor would I call that “leaking” (too long a story for this textbox, I’m afraid).
Jeff Mogul wrote an “ooo” (out of order) draft maybe 3 or 4 years ago which did what you suggest about using explicit messageids rather than TCP ports + ordering. The problem was that it essentially required incompatible changes to both client and server to support. Hence, nobody supported it, including my startup at the time (though it would have resolved a nasty race condition we were having). And HTTP didn’t originally use a messageid because it didn’t need to; ordered messages over TCP were good enough for TCWA (The Canonical Web App).
FWIW, Waka – Roy’s upcoming HTTP replacement protocol – will support OOO.