November 12, 2007
@ 04:01 PM
Comments [14]
OpenID + OAuth is the Final Nail in the Coffin of the WS-* vs. REST Discussion

Although the choice of whether to pick between WS-* and REST when deciding to build services on the Web seems like a foregone conclusion, there seems to be one or two arguments on the WS-* that refuse to die. You can find a them in the notes on the talk by Sanjiva Weerawarana at QCon, WS-* vs. REST: Mashing up the Truth from Facts, Myths and Lies 

  • history: why were WS created? people were doing XML over HTTP in 1998/1999
  • everyone invented their own way to do security, reliability, transactions, … (e.g. RosettaNet, ebXML)
  • Biggest criticism of SOAP in 2000: lack of security
  • REST-* is on its way - ARGH!

Today you can find other members of the Web Services community echoing some of Sanjiva’s points. You have Don Box in his blog post entitled Yes Steve, I've Tried saying

I wouldn't call myself an advocate for any specific technology (ducks), but I've spent a lot of time doing HTTP stuff, including a recent tour of duty to help out on our .NET 3.5 support for REST in WCF.

I have to say that the authentication story blows chunks.

Having to hand-roll yet another “negotiate session key/sign URL” library for J. Random Facebook/Flickr/GData clone doesn't scale. 

and even Sam Ruby adds his voice in agreement with his post  Out of the Frying Pan where he writes

I’d suggest that the root problem here has nothing to to with HTTP or SOAP, but rather that the owners and operators of properties such as Facebook, Flickr, and GData have vested interests that need to be considered.

For once I have to agree with Sanjiva and disagree with Sam and Don. The folks at Google, Yahoo!  and a bunch of the other Silicon Valley startups realize that having umpteen different application interfaces, authentication and authorization stories is a pain for developers build mashups, widgets and full blown Web applications. The answer isn’t as Don argues that we all jump on WS-* or as Sam suggests that Web companies have a vested interest keeping the situation fragmented so we have to live with it.

In fact, we are already on the road to REST-* as a way to address this problem. What happens when you put together AtomPub/GData, OpenID, OAuth and OpenSocial? Sounds a lot like the same sort of vision Microsoft was pitching earlier in the decade, except this time it is built on a sturdier foundation [not crap like SOAP, WSDL and XSD] and is being worked on collaboratively by members of the Web community instead of a bunch of middleware vendors.

It’s unsurprising that Don and Sam don’t realize this is occuring given that their employers (Microsoft and IBM respectively) are out of the loop on most of this evolution which is primarily being by driven by Google and it’s coalition of the willing. Then again, it does remind me of how IBM and Microsoft pulled the same thing on the industry with WS-*. I guess turnabout is fair play. Wink

Now playing: D12 - American Psycho


 

Categories: Web Development | XML Web Services

« SocialAds Implications: Facebook will Ac... | Home | Wedding Day Pictures »
Monday, 12 November 2007 16:44:37 (GMT Standard Time, UTC+00:00)
Oh, dear, it looks like my title was too subtle.

I've implemented OpenID on my weblog. Not just as a producer -- anybody can do that, but as a consumer. When are we going to see large scale OpenID consumers by any of the companies that you mention?
Sam Ruby
Monday, 12 November 2007 17:01:14 (GMT Standard Time, UTC+00:00)
Sam,
I doubt we'll see any of these sites consuming OpenIDs anytime soon but I think wide adoption of OAuth will resolve some of the issues that Don is complaining about. And will do so in a more user-centric way than anything I've seen proposed by the WS-* crowd.

GData + OAuth + OpenSocial are on their way to becoming REST-* for a number of online services. I probably shouldn't have thrown OpenID in the mix since it clearly doesn't fit in with the others and will likely not be bundled together in the same way.
Dare Obasanjo
Monday, 12 November 2007 17:07:49 (GMT Standard Time, UTC+00:00)
OK, I'll play along. Clearly I know about OpenID, but perhaps you didn't really mean it. So lets go down your list. Your first item is AtomPub. Do you really believe that I am unaware of it, or don't you mean that one either, or are you merely trolling?
Sam Ruby
Monday, 12 November 2007 17:31:41 (GMT Standard Time, UTC+00:00)
Sam,
Don's post seems to be complaining about having to roll his own code to handle authentication with various online service APIs (Facebook/Flickr/GData). This is a developer pain point in building mashups, widgets, etc. Google has started a number of collaborative efforts in defining common API standards in this space including OAuth and OpenSocial. OAuth comes pretty close in making some of the divergence in authentication schemes straightforward to deal with. At least, from my non-experts perspective, it seems to be on par with the scenarios that would be solved in the Web case by using WS-Security/WS-Trust as Don suggests.

Your post implies that these parties have a vested interest in not collaborating. The number of different parties working on OAuth contradicts that statement. Facebook isn't participating which is to be expected since that is how they roll. Microsoft and IBM being cut out of the loop also isn't surprising given that we aren't the darlings of Silicon Valley startups or the former startups like Google and Yahoo!.

If you were actually aware of OAuth and OpenSocial yet still believe that there is no incentive for Web companies to work together to make developers lives easier. Then you are a bigger cynic than I expected. :)
Dare Obasanjo
Monday, 12 November 2007 20:30:39 (GMT Standard Time, UTC+00:00)
"not crap like SOAP, WSDL and XSD"

Let me ask you one question about REST. Can REST be programmtically discovered? Can I be given an endpoint and discover all the possible operations on that endpoint? Can a REST endpoint have have an Interface, and by Interface I mean that in the c# sense - can the operations be standardized and predictable?

REST is the step in right direction, I'm a REST fan - but the REST community does not near the tools support and the brain cycles that WS-* has.

Can I programmatically discover all the possible operations on the Windows Live Contacts API?
Johnny Fry
Monday, 12 November 2007 21:05:05 (GMT Standard Time, UTC+00:00)
Take a look at WS-Security and WS-Trust some time. Using just those two specs, and no extensions, what scenarios can you solve?

Now if you expand the scope to say "if both partners agree to use a common extension...", how is this materially different than the situation that Don (correctly) said "blows chunks"?
Sam Ruby
Monday, 12 November 2007 21:51:27 (GMT Standard Time, UTC+00:00)
Johnny Fry,
It seems you are hooked on the automatic code generation provided by data binding tools in concert with WSDL. Nothing is stopping you from describing RESTful end points with WSDL 2.0 and in fact, Sanjiva Weerawarana says as much in his talk linked above.

Sam,
I agree that Don's example seems to be a case of the pot calling the kettle black with regards to WS-Security/WS-Trust versus just using HTTP Auth. What I was disagreeing with is that the major Web players don't have an incentive to work together to fix the situation. I should have been clearer about what I agreed/disagreed with in my post. Sorry about that.
Dare Obasanjo
Monday, 12 November 2007 22:24:02 (GMT Standard Time, UTC+00:00)
Dare,

Care to elaborate more on the reasons you think XSD, WSDL, etc are "crap"?

I find that statement interesting, given that you worked in the team producing the Microsoft implementations, and not too long ago, you were blogging extensively about those technologies :)
nexusprime
Monday, 12 November 2007 23:03:18 (GMT Standard Time, UTC+00:00)
nexus prime,
I assume you are not a regular reader of my blog. See http://www.25hoursaday.com/weblog/CategoryView.aspx?category=XML%20Web%20Services
Dare Obasanjo
Monday, 12 November 2007 23:31:37 (GMT Standard Time, UTC+00:00)
nexusprime,

At the risk of putting words into Dare's mouth, let me say that software is very much a journey. You start out down a path, guided by a vision (your own or someone else's), and often reach a conclusion that the path has been ... misguided.

There was a time when Microsoft's WebData team started down a path. The path began with some curious, nascent ideas such as XDR and XSL Patterns, and eventually those ideas developed (with input from many others) into standards like XSD and XPath.

After you've implemented those technologies a few times, and built some apps using them, and really probed their depths, you realize they're ... crap technologies. Yes, it's the right word. XPath has, for example, a translate() function, but no uppercase() or lowercase(). WTF?

You get crap like that when a technology is designed by a committee, or when it starts out with a singular vision and the visionary moves on or isn't critical enough of the creation.

Dare and I could cite many dozens of craptasticity in both of these technologies, but honestly, it's boring. And speaking of boring, so is pointing out all the flaws in SOAP and WS-* and CORBA and cgi-bin and blink and all the other refuse discarded along the path of web development.

Are we better off slowing down and thinking more deeply before creating, or should we continue to create technologies willy-nilly and see what sticks? Design vs. evolution?

The whole world's a mess, conflict, tug of war, competing visions and ideas. There is no magic bullet. Every now and then we manage to identify and smooth over a few rough spots. Sometimes we're able to express clearly the ideas that had so much clarity in our minds. More often we make a mess of things, create more problems than we solved, and worst of all, solve problems no one really had. Job security, eh?

Rough spot du jour is cross-domain authentication -- rough for implementers creating services, for developers consuming those services to build apps, and for the general public consuming those apps and services. We'll create a pile of incompatible solutions to this problem, one or more will "stick," and by then we'll all be on to the next problem already.


Michael Brundage
Tuesday, 13 November 2007 01:18:31 (GMT Standard Time, UTC+00:00)
Oh, I've been reading your blog for quite some time, from Kuro5hin days.

Perhaps I should qualify "not too long ago". Around 2004, which is a fair bit of time when it comes to the web.

But what have we as an industry learned? Apart from the obvious, that design-by-committee produces specifications that are pretty hard to implement?

So we throw away, say, WS-Security. Now I need to roll my own scheme for message encryption and signing, security tokens, etc.

Where's the winner-takes-all replacement for this, or best practices (oh, I hate that term, but it applies) for doing this in a manner that does not compromise security?

Next! Lets say WSDL and all the standards it uses under the hood are quite complex and brittle for what they do.

Not disputing that, but now I need to whip up some documentation and a scheme in the schema definition language of my choice for message format, data types, for each of my different services.

This is what I'm doing today, anyway, since our web services are plain old XML over HTTPS, and maybe that's more valuable, since I'll be writing something that's closer to the problem domain of the people using my service, and lets face it, documentation on how the service works given particular inputs is more valuable than the WSDL generated documentation, which discusses none of that, and is typically the extent of the "documentation" provided by a lot of large companies who should know better.

But basically you've gone and deprecated the VS tooling support for web services. Fine, but there isn't really any compelling alternative, and we're back to "proprietary" (in the sense that it requires custom development to support your basic communication needs, that you now have to do before you can start thinking about matching up the conceptual model of the remote web service to your local client).

I'd be very interested in a post or article that discusses the various components of the WS-* collective, since I hardly think people on those working groups were sitting around, puffing on cigars, in large boardrooms with mahogany tables, leather chairs, simply for the fun of it. But what do I know, I've never been to one of these meetings :)

@Michael: Great response, thanks.
nexusprime
Wednesday, 14 November 2007 04:31:31 (GMT Standard Time, UTC+00:00)
POW! POW!

Dare lets rip from both barrels!

(thought provoking stuff)
secretGeek
Thursday, 15 November 2007 15:38:13 (GMT Standard Time, UTC+00:00)
My concern with OAuth and OpenID (actually pretty similar to my thinking around JSON) is that they're absolutely great for web pages, but (at least last time I looked) really poorly supported in a desktop application or for in-page widgets.

I can't put an OAuth protected widget on my iGoogle page because OAuth (and OpenID) need to redirect me to another web page. And my 100 x 100 pixel iframe is probably not how that web page expects to render itself.

If I want to use OAuth in an app, I need to fire up a browser, do the OAuth dance and then *ask the user to type in an authentication token*.

Cheers
Matt

Cheers
Matt
Matt Ellis
Thursday, 15 November 2007 16:35:42 (GMT Standard Time, UTC+00:00)
(Actually scrap the JSON quip above - just re-read it and I'm not saying what I meant to say - ignore that bit).

What WS-Security + WS-Trust give me out of the box is a user-agent neutral way of doing authentication. Yes, I need more to actually make it work, but this is still a big win. (See previous comment)

By itself, WS-Security gives me message level security. I understand AtomPub is either getting it or already has it, but seeing that GData is not a strict implementation of Atom, what does this mean for the message level security? And what about the RESTful services that don't use AtomPub or GData? Does that mean I don't have a single way of doing message level security across RESTful services? WS-Security gives me that. Any and all SOAP messages can be protected by wsse.

And I've also got features such as securely passing through intermediaries, securely persisting messages and securely passing messages through message queues. (Arguably "enterpise-y" - I need this at work, but not for my email, calendaring, blogging, pictures or shopping)

But yes, I need extra specs for wsse and wst to do authentication. It's like they punted on how authentication, kinda like OpenID and OAuth. Ha ha.

Cheers
Matt
Matt Ellis
Comments are closed.