Overview Map of WS-* specifications

This is an impressive mind map of the various Web Services specifications, complete with hyperlinks the specification documents.  It’s organized by the committe or organization who published the spec, which gives some idea of just how many standards bodies have their toes in these particular waters.

I wish I knew who the author of the mindmap is or the background on why it was created, but it looks the parent website is in Japanese or something.. Oh well.

Here is another overview, this one does a better job at putting the various standards into the context of what they’re intended to accomplish.

More on the WS-* vs REST debate

A few days ago I blogged a bit about the debate between proponents of the WS-* and REST styles of web services. I’ve been thinking about the debate since then, and I’ve come to the realization that part of the problem with the WS-*/REST debate, part of why the two sides can never reach any concensus, is that it’s really three debates in one.

  • Message oriented integration vs connection oriented integration.
  • WS-* suitability as a message oriented integration method.
  • REST’s suitability as connection oriented integration method.

WS-Security and SSL

Over the holiday season I’ve been catching up on a (few) of the unread posts in my feedreader, which is how I stumbled rather belatedly onto a set of back and forth blog rants between Peter Lacey and Gunner Peterson. The subject of thier discourse is the relative merits of the WS-* and REST Web Services stacks.

The REST/WS-* debate is shaping up to be another of those dogmatic, eternal flame wars (like vi vs. emacs). I usually avoid these kind of black hole discussions like the plague, but I feel compelled to comment on this particular one.

Specifically I’m quite disturbed by Peterson’s repeated attempts (this being the most blatent) to claim that SSL is insecure or is somehow less secure than WS-Security. This is of course totally bullshit.

Message oriented security technologies (like WS-Security) provide *additional* security functionality beyond that provide by transport security (like SSL or IPSEC), but they also introduce significant additional risks. Message oriented security technologies in general expose a much greater attack surface than transport oriented security.

The WS-Security specifically is also a very new, very immature spec that is *very* complicated. It would be incredible naive to assume that current generation WS-Security libraries are sufficiently hardened. The complexity and flexibility of the spec itself is also cause for concern, just take a peek at how many non-obvious pitfalls have to be avoided to securely use the username/password token in WS-Security! Any implementation of WS-Security is also dependant upon the security of the XML parsing library used, and securing against XML based attacks is still a discipline in it’s infancy.

The obvious truth is that WS-Security and SSL are complementary, not competing technologies. I’ve never seen a WS-Security protected web service exposed to the Internet without SSL, nor do I ever expect to see one. (or at least, to see one survive 🙂 )