Opinari

Subscribe

Responses to REST vs. WS-*: War is Over (If You Want It)  
# Monday, July 23, 2007
 
Well, maybe the war’s not completely over. Judging from the responses to my recent entry, a few people are still girded for battle. Some examples:

- I said “A RESTful approach is a natural for data-oriented applications that focus on create/read/update/delete scenarios”. Some took this as an assertion that REST was only useful in these scenarios. I didn’t mean this. Still, believing that a RESTful approach is right for everything seems too strong. As Microsoft’s Steve Maine pointed out, the fact that I can do anything with the universal interface of a Turing machine doesn’t mean that I want to write all of my apps that way.

- Comments like this: “What is this amazing security mechanism that WS-* has that cannot be applied to REST?” are easy to answer, but comments like this: “[N]obody uses SOAP. Everyone has had the ability to choose it for years, and nobody does” are more puzzling. SOAP and WS-* are used in many, many enterprise applications today, and they’ll be in a bunch more by this time tomorrow. Transferring money between accounts at my bank depends on SOAP, for example, as do many other commercial functions that we all rely on. For clients interacting with Internet applications, a RESTful approach is often—usually, even—the right choice. For creating typical enterprise apps inside the firewall, SOAP and WS-* are commonly better, and lots of people use them.

- A few people commented on the number of specs in the WS-* canon. The relevant number, however, is how many of those specs a developer must understand to write an application using SOAP and WS-*. Assuming a decent framework, such as Microsoft’s WCF or the Java world's SCA, that number might well be zero. Just as the creator of a sockets app needn’t read the specs for TCP and IP, the creator of a SOAP/WS-* app can remain largely ignorant of how these technologies provide their services.

- And to be clear, I wasn’t making any kind of analogy between WS-*/REST and Korea/World War II. My only goal was to provide an example of a truce rather than an overwhelming victory. Ted Neward’s erudite response to this brief mention was nothing short of awe-inspiring, however.

Nobody feels strongly about whether the sun will come up tomorrow—people are only passionate when something is in doubt. Now that the value of REST is as certain as tomorrow’s sunrise, perhaps we can all lighten up a little. Readers seemed to focus on the first part of the John Lennon quote in the entry’s title rather than the equally important second half: The WS-*/REST war is over only if we want it to be. And we certainly should—it’s a waste of our energy.

0 comments :: Post a Comment

 

Introducing SCA  
# Monday, July 16, 2007
 
Service Component Architecture (SCA) isn't an especially simple technology. It's also hard to figure out just by reading the specs. To help make clear what SCA is, I've written a white paper that introduces the topic, available here.

My original goal for this paper was to create a straight tutorial that all of SCA's creators would agree was accurate. This turned out to be impossible. Different vendors have different perspectives on how SCA should be presented and even on which parts of the technology are important. Accordingly, while I've done my best to be accurate and objective, I'm certain that there will be some disagreement with how I've described or positioned a few things. Still, my hope is that there's value in an overview of the topic from somebody with no particular vendor ax to grind.

And one more thing: Although everything I produce reflects my take on a topic, I get paid for most of the papers I write. That's not the case here. I've been interested in SCA since it first went public in late 2005, yet I don't think this technology has gotten the attention it deserves. Maybe providing a place for people to start understanding it can help change that.

16 comments :: Post a Comment