AXDC – Don Box and WS-Why?

Intro by Chris Sells, everyone in the audience already knows who Don Box is.

The original title of the was “WS-Islands.” He’s going to walk through the various standards in the talk, and attempt to explain and justify each one.

WS-DesertIsland best describes the architecture. If you had to put 5 specs on a zip drive before heading off to a desert island, which specs would you take?

• XML or lisp, one or the other. Sticking with LISP might have been better (aside to Tim Bray, why didn’t you guys just use LISP? Tim: Uh, uh, uh, Uh. Uh Uh!). All I need is a simple way to write down structured data. Hard to imagine life without one or the other. Both of these systems make the absolute minimum commitment to abstraction; they are just data. With no idea where an XML document has been, can walk through it, process it, munge it, and so forth, without bringing along any code. The data outlives the code in many situations.
• SOAP, after somewhat of a struggle. SOAP 1.2 part 1 is a pretty reasonable place. Needed better extensibility mechanism other than “throw shit anywhere you want.” SOAP constrains the top-level elements and defines this mechanism, basically a header extensibility model. This model seems to hold up. .Net serializer is adopting this model, all logically SOAP based without a SOAP envelope. This produced some good code synergies. SOAP 1.1, Section 5, went way too far, “the work of the devil, a Linda Blair experience.” Had to prohibit PI’s because processing model was ill-defined — was it aimed at any intermediaries or the ultimate receiver? Also removed DOCTYPE so that they had an atomic unit of transmission — the SOAP envelope. SWA (SOAP With Attachments) went a bit too close to the edge. Mixed content model was horribly naive. All in all, a good place to be. Most of what SOAP gives us is actually pretty good.
• WS-Addressing, since SOAP contains as little policy as possible. Build simple & reliable mechanisms and layer policy atop that. SOAP over HTTP buried too much addressing in the transport. This made it impossible to store a message and process it later since it got in the way of end-to-end guarantees. Putting it in the SOAP envelope allowed for digital signatures, XPath, and more. This turned out to be very useful. 2 controversial points. First, the Action URI. Message is just data, but since it was sent to an endpoint, want to assign names to semantics instead of just a POST to a proliferation of addresses. Best to capture intent of original sender. Second was the endpoint reference. He notes that this is a platform (extensibility hook) for the future, with lots of stuff to be layered atop. This will require cleanup later on. “I strongly discourage you from reading all of these specs.” Defined specs as “minimum progress required to declare victory.” IBM has figured out how to turn complexity into a business model — IBM Global Services. Specs which embedded the intent and expected usage would never converge. So just agree about what’s on the wire, and spec that. Pretty clear that IBM and Microsoft are the only two elephants contributing to these specs based on his description of how the spec development process works.
• ws-mex, they forgot to do this earlier — Metadata Exchange! Perhaps will be fixed in 2007, 9 years after the first SOAP spec was written. Don introduced Omri, who owns all of the WS- specs at Microsoft. ws-mex is IProvideClassInfo for services!
• XSD WSDL, not separate in his mind. Both equally onerous and full of bad, stupid, committee-thing within. Relax-NG would be better (and the Amiga too).

So, he could live with the above plus a transport as a basic kernel.

If we get to choose more, which ones:

• ws-security, difficult but necessary in the context of MOM-based systems. SSL and the like don’t work with store and forward systems. Security must go along with the message as part of the data. Web economy requires SSL and TLS. ws-security is the simplest thing that could work, given a bunch of other requirements — XML Dsig and encryption. This is a pain point right now. ws-security 10x slower than SSL!
• WS-Trust, metadata exchange for WS-Security.
• WS-Reliable Messaging, little to add over raw TCP unless you are going through relays or intermediaries where things could get reordered or delivered more than once, or dropped. Doesn’t give durability or queuing, just reliable end-to-end messaging. Don’t use it if your transport already does this.
• ws-policy, fkirst one way too complicated. New one is simpler and even implementable.
• ws-NewZealand, a lovely place to visit exactly once per lifetime. Here are specs lke that. ws-eventing, strictly speaking it is not needed. But there’s a desire to do pub-sub. Microsoft ships a simple version, IBM ships WS-RF, a three volume spec. ws-atomictx, good for the three people building transaction managers. ws-enumeration.
• ws-IslandOfDoctorMoreau, the ugly stuff. UDDI, bad spec, terrible marketing, horrid overall. Spec is better than WSDL ,less crazy-ass features and less non-determinism. Put way too much business in there. ws-businessactivit, bpel4ws. mtom, cleanup after SWA, ws-transfer, published to tempt the RESTafarians.
• ws-fantasyIsland, stuff he wants. ws-data (isn’t this just XML?, asked someone). SOAP over TCP, being built for Indigo, binary XML, XSD 1.Noah. Retire NG (a WSDL replacement in the spirt of Relax NG)