I pretty much have stopped arguing about REST and Web Services. One of the things open source has taught me is to react well to customers. If a customer is interested in using a SOAP solution, I help them. If a customer wants to use a RESTful model, I help them do that too. And I try to look at their individual scenario and understand what is the most appropriate technology for them.
Steve's argument is phrased in terms of RPC, and he portrays WS-* as the culmination of the RPC model. In fact many of the architectures I am involved in building on top of WS-* for customers are not RPC - they are either long-running asynchronous or event driven. It is a fundamental error to say that SOAP is an RPC format.
In my experience, very few customers care about WS-* vs. REST: they care about building something that is effective, maintainable, fits with their skill set and developers, and that scales well.
Given my lack of interest in arguing about REST and WS-*, I considered ignoring that Steve has chosen the WSO2 Registry as an exemplar in his article. On the other hand, his example is wrong in so many, many ways, I can't resist the need to set him straight.
Here is what Steve has to say:
"For example, WSO2 uses Atom4 and AtomPub5 (both built on RESTful HTTP) within its registry product (www.wso2.com/products/registry/), which is part of a set of open source products based on SOA and WS-*. Somewhat ironically, the registry uses a RESTful approach to handle the publication and lookup of metadata for non-RESTful RPC-oriented Web services. Christensen refers to this approach as "cramming," in which firms try to capitalize on disruptive technologies by incorporating them into sustaining products;"Let's address the factual errors first and then address the more systemic problem in the article.
Firstly, let's be clear about the WSO2 Registry: it is a new initiative, built from the ground up as a RESTful model. , and it is not limited to publication and lookup of metadata for non-RESTful services. For example, you could use it as the store for document descriptions, mime-type descriptors, WADL, RDDL, or many other RESTful description models. We built the WSO2 Registry in a RESTful way because we decided it was the most appropriate technology for managing metadata. You could say its ironic, but since 99.9% of the world's WSDLs are accessed via HTTP GET, you could also say it is simply extending the defacto standard. Of course being English, I consider Irony a good thing, and I often point out this same irony myself.
Since the Inventor's Dilemma is also a lot about the human reaction to new technology, I think its also fair to point out that I have consistently criticized UDDI for over 5 years, both publicly in presentations and to anyone who asked me.
I actually wonder if Steve has downloaded the Registry or looked at it beyond the fact that it uses Atom and AtomPub. Why? Because if he had, he would have realized that the main aspect of the Registry is a Web interface. The Atom and AtomPub are secondary to most users, because the main interaction is humans using a Web browser. And mostly if a user comes across the Atom, its in their feedreader, which is likely an extension of their browser.
Steve goes on to say:
"In this case, the benefits of REST are hidden behind an RPC-oriented API for accessing the registry, and those benefits disappear completely as soon as an application uses the registry to find a non-RESTful service and starts to use it."Once again, this is a highly superficial view of the Registry. The benefits of the REST design permeate the use of this product. You can bookmark any page. You can point your tooling or code at a permanent URL pointing to a WSDL or a WADL or a Schema and know that it will always be there in exactly the version you want. You can subscribe to the Registry using your feed reader. You can follow links from dependents to dependencies. You can associate any kind of relationship between resources, and follow those relationships as hypertext. These real and important benefits of the REST design are why we chose it, no more, no less.
The core API is highly RESTful and built around the concept of Resource as a first class concept.
I think its clear that Steve is taking a superficial view of the registry in order to make a point - he thought "cramming" was an essential point of Christensen's model and so he looked around for a target. And this is the systemic problem with this article.
The scientific method is that you propose a theory, and you dispassionately look for evidence to prove or disprove the theory. Unfortunately Steve has proposed a theory - that the Inventor's Dilemma maps neatly onto the REST vs WS-* argument - and then applied his strong viewpoint to bias the outcome. The whole article starts from the premise that REST is the answer and then goes on to prove that. Funny how that happens.
So my advice - take a look at the WSO2 Registry yourself.
Paul, thanks for the feedback. Let me address a few points.
ReplyDeleteI don't think it's fair to say that I've taken a "very strong stance against [my] previous position." It's much more accurate to say that I've learned quite a few things through this decade so far that were wrong with CORBA and things like it, and now that I've incorporated that knowledge into my everyday work, it puts me in a better position than most to be able to explain the differences and help developers choose between them.
If anything is wrong with my analysis of your product, then look no further than your own online documentation as the source of the problems. My understanding is based entirely on it. If I were writing a full review of the product, then yes, a full download and trial would be in order, but I shouldn't have to download and use it just to be able to lightly comment on its documented APIs.
The main reason I mentioned your product was not to review it but to show an example of cramming in the context of RPC and REST, of which I believe it's clearly a classic case. Don't take it personally; I don't know of any other vendors who have better examples, but if I did, I would have used them instead. Cramming isn't as essential to my column as you seem to believe I think it is, but I mentioned it only because it's a clear indication of the tension between the two sides of the argument. Overall, I don't believe there are actually any problems with what I wrote, except that you seem to be saying "oh, ignore those APIs, people use it differently than that" to which my response is that, well, those APIs are definitely there, so in the context of those APIs I stand by my comments and analysis regarding cramming.
Also, if you think the lesson of the column is "REST is the answer," then I'm afraid you missed its main points. The actual points are that 1) technological evolution is inevitable as lower cost approaches continually displace older more expensive ones, 2) individual technologies, be they old or new, appeal to different individuals and different organizations based on their preferred risk/reward ratios, and 3) it's interesting to compare and contrast RPC and REST within this context.
What prompted me to write the column in the first place was the rather pointless reactions to REST by hard-core WS-* advocates who say things like "Oh, but REST can't do transactions!" and come up with other perceived shortcomings as if they spelled a certain death knell for the RESTful approach. Similarly, you can find REST advocates who seem to think that everyone should just drop whatever they're using and use REST for everything instead. If each camp actually understood technological evolution, they'd already know that according to Christensen's theories newer technologies start out less capable in many areas than the technologies they eventually displace. Therefore, if the WS-* guys were smart, they'd try to find ways to take advantage of the new developments in REST, and in fact I commend WSO2 for trying to do so. On the flip side I think REST advocates already do pretty well at listening to the objections of the WS-* crowd and trying to learn how to address them, but they might also do better to keep in mind the technology evolution forces and conservatism that cause some to require quite a bit of time before they'll be ready to adopt RESTful approaches.
If the WS-* advocates and REST advocates also both understood where they themselves sat on the technology adoption lifecycle and how their own preferred risk/reward ratios affected how they viewed technologies in general, then I doubt they'd make the same comments to each other that have resulted in so many pointless battles in the past. I also wrote the column because of the continued general arguments between people with different risk/reward ratios who, because of those differences, are simply never going to see eye-to-eye, and I merely wanted to point out the futility of those arguments.
Finally, the fact that you bring scientific method into the discussion means that you're applying restrictions to the column that simply don't exist. The column is neither a thesis nor a submission to an academic conference. I'm not restricted to applying only scientific method in the column, but rather, I'm required and entitled to express my own opinions there (within reason of course, which is why it's reviewed before publication), and of course you are free to agree or disagree with those opinions as you like. If you want to disagree with my analysis of RPC and REST within the context of Christensen's theories, that's fine (hoping you would do so only after a careful study of all of his books, of course), but I don't think you can deny that it's interesting and perhaps even innovative to explore the topic from that angle.
"I pretty much have stopped arguing about REST and Web Services." That's a little weird. There's an argument going on. You're well-informed, with hands-on knowledge. Agreed that the customers typically don't have an opinion. But I'd think you would.
ReplyDeleteTim first. I have an opinion. Its this - REST and WS-* are two different approaches with different merits and de-merits. Most importantly they are suitable in some different scenarios, and there are places where both of them are reasonable approaches. Arguing one way or the other strongly tends to miss the subtleties.
ReplyDeletePaul
Steve
ReplyDeleteFirstly, I'm really impressed you are blaming me for your mistakes. I think you have looked at the product very shallowly, with some pre-conceptions and decided that since WSO2 has done this, it must have an RPC-like interface. If you look at this wiki page - http://wso2.org/wiki/display/registry/Registry+Protocol - you will see a clearly defined REST API. And I'm not saying to ignore the APIs - the Java API is also closely modelled on REST rather than an RPC model. I'm merely saying that you seem to have failed to evaluate the product as a whole.
I actually think your CORBA heritage blinds you aspects of the WS-* model: you naturally assume that WS-* is an RPC model, whereas it actually quickly evolved to a message-based model which encourages asynchronous document-based messaging.
As regards your use of the cramming concept to demonstrate "tension" between REST and WS-*, once again you are letting your preconceptions get in the way of understanding the true situation. There is no tension involved in using a REST-based repository to store descriptions for WS-* based services. In fact the approach works very smoothly, and is actually very productive and effective.
I actually like the REST model a lot, but I think you make a premature assertion that it is necessarily a lower cost model. Yes, the WS-* specifications have cost the vendors a lot of money to develop, and REST has cost the vendors very little to develop, but that doesn't necessarily mean that those costings apply to users. If you look at the complexity of a CD compared to an LP, the CD cost the developers a huge amount more, but the cost to the user is less because the parts are more amenable to mass-production. So far REST projects are - in my experience - more expensive to implement than RPC projects because they require smarter people and there are fewer tools. However, I do expect that to change over time. However, the fact is that the REST model has complexities of its own that are masked by the fact that the early adopters are a very smart bunch of people (yourself included!).
Finally, as regards the scientific method, I think its widely applicable. Science comes from the Latin word for knowledge. Just because you didn't publish the article in a scientific journal doesn't make it any more right. If you started out with an assumption and then proved that assumption, you're logic is wrong wherever your article is published. The only restriction I'm applying is whether your point is valid or not.
@Paul: rather than being impressed, you should be concerned, given that the errors are clearly yours, not mine. You either don't know what REST is, or you've never read your own registry documentation.
ReplyDeleteJust because you use verbs like "get" and "delete" in your method names doesn't mean your API is RESTful! Please explain to me how your API supports "hypermedia as the engine of application state," for example, which is one of the most important REST constraints. Please explain how having separate specific API calls for manipulating tags and comments is RESTful. I could very very easily write an entire column on just how un-RESTful this API is. It's a clear example of what Roy Fielding recently wrote about with respect to APIs calling themselves RESTful when they clearly aren't.
As for your comment about my heritage, your comment here is off the mark too. You're using the term "RPC" to mean "synchronous invocation" which is a mistake that many unfortunately make, but in fact the term RPC refers to the invocation model at the programming language level used to make remote calls appear as just any other method or procedure call. Your API is clearly of that ilk.
As for cramming, you can try to deny it, but it's undeniable. Your API is RESTful in marketing literature and documentation only. I continue to stand by my analysis here.
You're also mistaken where you try to analyze the term "lower cost" in the context of applying and using REST, but again, seeing as how you clearly do not understand REST, your mistakes are understandable. You're missing the huge fact that REST promotes the decentralized development of services and applications that are "pre-integrated" through the application of REST's constraints, an approach that's impossible with WS-*, CORBA, etc. You seem to be missing the fact that specialization represents an enormous cost in systems like WS-* and CORBA (perhaps your heritage is blinding you to it), and yet it's a cornerstone of such systems. It's a cost that just keeps on giving, because every participant has to pay it. Specialization thus also naturally limits the scale of the system, because each instance of specialization (i.e., each WSDL or IDL interface) represents a point of additional agreement that must be gained across all participants before it can work. Like I said above, this cost is enormous.
And finally, your comments about the scientific method are a red herring. After all, if you were so fond of the method, you might have applied it yourself in analyzing my column, instead of just asserting that the column has problems without providing any actual proof. I believe I applied enough scientific method in my article, thank you, and I stand by everything I wrote. None of my pre-publication reviewers, some of whom are long-time and well-respected industry giants, called that out as an issue. The fact I happened to mention your company's product in my column in a slightly negative context is no reason to try to make up unwarranted and unfounded accusations about the column as a whole. The scientific method works best when you keep your emotions in check.
No offense, but you clearly don't understand REST as well as you think you do, which makes for a very shaky basis for you trying to analyze my work. My advice is to go back and carefully read Roy's dissertation 3 or 4 times, go listen in on the rest-discuss mailing list for a few months, read Roy's blog and the blogs of those he lists in his blogroll religiously, go read all of my previous 2008 columns which were written specifically for people like you (and me) coming from the RPC heritage and wanting to understand REST, and then re-evaluate your own APIs. Perhaps then you will see just how un-RESTful they are. Cramming is, frankly, the least of your worries.
Ahh. Its nice to see the REST police are in action again. Its so refreshing when you work to use a technology to have the supporters of that technology attack you.
ReplyDeleteIf you would like to help us improve the REST aspects of the Registry, rather than criticize from an all-too-brief examination, its an open source project and we welcome contributions and committers. Just join in on the mailing list: http://mailman.wso2.org/cgi-bin/mailman/listinfo/registry-dev
@Paul: ah, now I'm "the REST police" and I'm attacking you. How predictable, and worse, how very sad.
ReplyDeletePlease quote the specific phrases that mark these alleged attacks. Or better yet, since there are none, don't bother doing that, but instead just please refrain from making such unfounded accusations in the future. Needless to say, technical disagreement does not constitute personal attack.
Your API speaks for itself: it's not RESTful. Assuming your documentation is correct, one does not have to actually use the product to see that. But if you still disagree, how about you send a link to the docs out to rest-discuss and ask for their honest evaluation of its RESTfulness?
Whether it's open source or not, I have no need for your registry in my own work, and certainly don't have cycles to spend fixing your development errors. Please go back and re-read the advice I gave you in my previous comment; if you follow it, you'll be able to fix the issues yourself.
Paul, this is a waste of time .. Steve and the rest of the RESTafarians are not going to view things analytically if it comes from the "WS-* crowd". You and I and apparently all of WSO2, are cursed to be the "WS-* crowd". We're simply not smart enough to do anything right with REST. Damn, I have to admire the IQ levels of the REST folks.
ReplyDeleteBTW, IEEE Computer, where Steve's article was published is NOT a scientific journal - most of its content is not peer reviewed. In particular, when one has a column (as Steve does), he can write whatever he wants and it goes in as-is.
This article is so full of stuff that comes from the mindset that WS-* is an RPC thing its ridiculous. To me, its yet another piece of irrelevant documents that anyone can put up on the Web (or print apparently).
@Sanjiva: first, two corrections:
ReplyDelete1. I write for IEEE Internet Computing (IC), not Computer.
2. Both magazines are indeed peer-reviewed as far as regular submissions go. I can't speak for the columns in Computer, but for IC, all columns must be reviewed and approved by the columns editor, who is an editorial board volunteer with relevant and significant technical expertise. For IC, that person was Doug Lea for many of the years I've written this column. Currently Siobhán Clarke, a distributed systems senior lecturer at Trinity College Dublin, volunteers her time for that position. I also generally get all my columns reviewed by one or more other people in addition to Siobhán, quite often still Doug for example.
Now, two comments:
1. It's unfortunate that you two have to resort to whining/whinging, childish attempts at insults, and just plain making stuff up simply because you disagree with what I wrote but are apparently incapable of finding a worthwhile technical basis on which to discuss it.
2. You should really get your facts straight before posting complete fabrications like what you've posted here. I've warned you about that previously, and you apologized then, so you already know I will vigorously defend myself whenever you write such lies. It's unfortunate that your own apologies don't seem to mean much to you, though.