Update: Stu has a good response in the comments.
Stu says there are some good things in ws-* that could or should be translated into the Rest world. That may be true, but I cannot tell just from his descriptions. The missing pieces that would help are really the missing pieces that had led to my doubts in ws-* all along.
Those pieces are really good examples.
I can see that WS-Security, WS-Trust, WS-SecureConversation, and Security Assertions Markup Language specify a *lot* about security and trust, very little of which (admittedly) I do not have much of a grasp of. Why do I need them though? Are there really clear examples of real world usage that I can follow to understand why these were used over other capabilities, and how they were used in a complete path to production, and evolution in production over time, and what else was needed to provide all the security and trust of the complete solution?
Multiply that by the rest of Stu's list: transactions, "coordination", "choreography", BPEL. That's a whole lot of stuff that needs explaining. I am a reasonably bright person. I can even curiously dig into things I don't understand and begin to make sense of them, when I put my mind to it.
Years after first being turned off of the seemingly impenetrable ws-* specs, and years after first (of many times) being told that as an application developer, I simply don't need to understand much of the specs because the vendors understand them on my behalf, I still cannot rationalize why I would need anything on Stu's list, let alone anything on the rest of the ws-* heap (because ws-* is way messier than a "stack" from my observations).
Lists of capabilities are insufficient for me. Maybe that's just me, but oh well, it still frustrates me because I feel as a fairly experienced developer I keep getting the sense that I *should* at least understand these things better even if I am still opposed to them.
Good examples would help me. I can find all kinds of them in the Rest world. I can figure out how to write my own without too much time or effort. Why can I not say the same thing about even Stu's abbreviated list?
3 comments:
Can you say a little more about what a good example might look like?
And could you cite a few for REST?
Dan --
Three books are high on my list...
1. The Restful Web Services book
2. Building Scalable Web Sites by Cal Henderson
3. Release It by Michael Nygard
Arguably, 2 is not about Restful Web Services per se, but clearly lends itself to Rest/HTTP for 'web services' as well as for 'web apps'. This book does touch on the soap, not nearly enough to grasp ws-* in any sense.
#3 is not just about the web, but is about integration and large, distributed systems, including Restful Web Services. Arguably this book applies as well to ws-* as to RWS. But one of my arguments with ws-* is that it attempts to obscure for application developers the kinds of problems presented in this book.
Going beyond these top three books, there are discussion groups and email lists, blogs, and web sites where I have found people discussing concrete, immediately applicable information about Rest. I've not found similar sources for ws-*. I spent months on the SOA yahoo group and could not really grasp onto anything applicable, though I felt I expressed that desire reasonably well a few times.
I would agree with someone claiming Rest is short on good examples, but those I've found so far greatly exceed what I've found for ws-*.
BTW, Dan, I think you'd be a great author for a Release It kind of book, based on our past conversations. Just saying.
I wrote the entry mostly as a "feature/function" list. Obviously there's a lot more to say. :-)
Many of these specs are valuable NOT for their properties but for their political significance, driven by fears. Though some have some good application. The problem is that many of these areas that are used as political weapons are founded on very complex & esoteric subjects -- especially security, but also reliable distributed systems. I follow Matasano, for example, to keep my eyes open at how unbelievably scary the security space is these days.
That's what gives these features their power: they are hard to challenge because they are hard to understand. It would be wrong to assume they're unnecessary because they're hard to understand. But it would be wrong to assume that "the experts" are right when they say it is necessary. I'm not sure what the way out is.
Some examples:
Message-level security, like PGP, S/MIME or WS-Security, for example, has good application. The alternative, transport-level security (SSL/TLS), makes the message opaque to firewalls and intermediaries.
So, a big problem is "how can I tell someone is attacking me or is legitimate"? Especially when they're using SSL, a monitor can't actually see what's going on. That's a big risk.
Message-level security allows parts of the message to be encrypted, parts to be unencrypted/signed. That way, my firewall or intermediary has improved visibility of what the message is "doing", so I might choose to block it.
Here is a counter-example of where one should NOT adopt message-level security, though usually people use it as a big reason: "non-repudiation"!
The idea is, because I have the signature in the message itself, I can actually persist the data + signature for future reference. The problem with this is that it doesn't prove much of anything (someone could have hacked your keystore). Scheneier has written about the problems here with real world examples.
WS-SecureConversation is only about taking WS-Security and making it work like SSL. I think we have some good understanding about why SSL is useful: it is computationally expensive to use public-key cryptography for each message, and arguably a security risk. So we add layers & negotiation to it to mix both expensive PKI and cheaper symmetric crypto.
As for SAML, I would say Dick Hardt's Identity 2.0 gives very real-world examples of the idea. SAML is one of several alternatives.
Transactions get into reliable distributed systems, which is a big hairy ball onto its own. So, to simplify, the default political assumption is just "use transactions if you want to be reliable", which is so empty a statement it isn't even wrong. On the bright side, the mainstream seems to have figured this out to some degree.
Post a Comment