“If you want to span systems asynchronously in a manageable fashion you’ve got to have standard models for addressing and identity baked in.”

Indeed.

“It’s taken some time for the WS community to get round to dealing with addressing and naming, but this is key stuff for getting something done over a gateway and for me, SOAP’s value is largely in dealing with gateways asynchronously.”

Did they get round addressing and naming?

They did not yet got round the riddle of asynchrony.

In 2000 I reviewed SOAP 1.0 gateway, built a whole test case for some reinsurance network company, complete with SSL/TLS client certificate and integrated as a Python web peer and interfaced with some EDI/XML tool chain and a qmail queue. Simple, fast, cheap. It’s the only software they managed to sell when the network was disolved: it showed the London buyer how to match a team of IBM Java swiss experts with two british VB programmers and some free software.

My judgement from that experiment is that SOAP is broken.

Asynchronously broken.

The envelope is before the body, which is fine for a synchronous process, but deadwrong when handling asynchronously pipelined requests. Because:

1. the envelope is the state of the transtaction instance.

2. the body is the state returned by a method of that transaction

3. the common transaction is usually made of a sequence of calls
   that modify the transaction state

Yet there is no way to actually program an asynchronous SOAP server because the f****ing state as modified by the transaction must precede the result of the function that just happen to modify that state!

Too bad.

Really too bad, because back in 2000, an asynchronous Python server running on a 133mhz Pentium III was flooding some Java Application Server running on the kind of hardware Swiss Reinsurer can afford. Too many processes, not enough memory.

SOAP should read like this, translated in an XMLization of Python keywords:

<call arg="val">
  <return/>
  <self/>
</call>

And often, that is what most XML transported by SOAP gateways will contain if there is an asynchronous handler in the process.

Nevermind, I can see that its happening on the blogs. Cool.

“There’s no sense in trying to take bits
that were designed for a distributed hypermedia system
(Fielding’s words, not mine) and trying to bend it to fit
a problem space that isn’t distributed hypermedia. Can we
learn from the REST architectural style? Absolutely–and the
new WS-* specs, including SOAP, do exactly that, favoring
self-descriptive messages over RPC calls as the principal
abstraction to deal with. But does that mean we tie ourselves
solely to HTTP? Oh, hell no.”

IMO, Ted’s world view makes the assumption that we have the luxury of imposing an entirely new set of techniques that are on an order of magnitude more complex than what is currently being used to accomplish ~80% of what is currently possible. Elliotte’s world view disallows him from making such an assumption. Any design that suggests we are capable of causing adoption of this kind of unprecedented amount of new technology should be heavily scrutinized.

No one is arguing that these new techniques (WS-*) would not provide additional robustness when considered soley from the perspective of “an adopted distributed system”. The question is whether we have the fu required to make adoption of this stuff actually happen on the scale of “all business systems”. You must consider basic human tendencies, skill-set required for implementation, and whether previous systems in similar situations were successful. It is important that a design answer these questions fully. A design that does not will remain a design only.

How does WS-* answer these questions? “We have big companies, standards bodies, and a tech press that will spend lots of money to convince people to adopt and everything will be great.”? It’s not working. It hasn’t been working for some time now. When will we begin a real conversation about these fundamental issues?

Yep, I put in a link in to PubSub; and I’m guessing you got here because you’re using PubSub with a subscription to “pubsub” and “xmpp” ;) (incidentally you should check out the URI filter/query mechanisms being proposed for APP at the moment and see if it’ll map onto XMPP…)

While I was thinking about system integration scenarios rather than pushing feeds to users here, the one thing that bugs me about the current push setup is that IM clients… suck. They’re much too intrusive - flashing, popping up; that’s fine maybe for chat, but they could take a cue from mail clients in the case of feed subscriptions.

On the infrastructure level I see a lot of places that block XMPP and you have to argue to get the ports opened (resonating with Marshall’s point about firewalls). It really does seems that some folks find the idea of running a protocol over its correct port rather than 80 being more secure counter-intuitive.

This is precisely what we do at PubSub.com. We use XMPP with the pub/sub extensions defined in JEP-0060 to instantly notify users of updates to 16+ million RSS/Atom feeds, 50K+ newsgroups, SEC Edgar filing, earthquakes, etc. SOAP based web services and HTTP based systems are simply not adequate to this task since they either require holes in firewalls, polling or gateway services in order to get messages to desktop. To provide instant notifications, one really must have a push protocol… HTTP might be popular, but it isn’t much good for notifications.

bob wyman