The usual Web Services background rumble has been getting remarkably loud these past few weeks. [Why now? -Ed. Beats me. -T] I haven’t figured out where we’re going, but then nobody else has either. This fragment surveys the state of play with a traditional link-roundup, and concludes with a suggestion that those who care visit Japan in May. [Updated with a pointer to an analytical piece from Joshua Allen.]
SOAP Detractors · Some of the sentiment is simple, straightforward SOAP criticism. Carlos Perez said SOAP is Comatose But Not Officially Dead! Gregor Hohpe questions how real SOA is. Jonathan Schwartz, in a general report of take-aways from meetings with a lot of CxOs, has a paragraph entitled “5. Web services may collapse under its own weight.” James Governor starts off with SOAP is boring..., provoking a defense of Microsoft’s approach from Mike Champion. The last word goes to Jon Udell, who says Don't throw out the SOAP with the bathwater; mind you, Jon is plugging an Infoworld event in May, but it looks like a pretty good event.
REST? · Quite a few (but not all) of the people who are questioning the current WS-ConventionalWisdom tend to be partisans of REST; if this is new to you, a good place to start learning about it is at Google, with a search for RESTful Web Services; a tour through the top few hits will get you started. Carlos Perez has a four-part rant on Why REST is Better: Explained in Code, Contract Based Protocols, Part 3, and Part 4 - Avoiding the Death March.
David Megginson, the primary designer of SAX, thinks out loud about REST best practices with a tour through a bunch of REST design questions (scroll down a bit).
REST stands for “Representational State Transfer”; Sam Ruby takes an (obvious) step further; a software geek thinking about “State” will naturally segue to “State Machine”, as Sam does in Distributed State Machines. That one got me thinking, I can tell you.
Well, what about a look at both REST and SOAP?
SOAP vs. REST · Since we’re already visiting Sam Ruby, a good place to start would be his titanic REST + SOAP from 2002. For a disorderly but intense treatment, see this immensely long thread on TheServerSide. It has the virtue that it looks explicitly at the lessons of CORBA, an earlier (and, some say, successful) attempt to build a generalized network-enabled programming infrastructure.
Transactions and Messages · One of the issues you run into quickly if you’re trying to build enterprise-level apps with a RESTian “The Simplest Thing That Could Possibly Work” approach is reliable messaging. That is to say, when I visit web page and it stalls halfway through, I hit “Refresh” and that’s fine; but when I’m submitting a billing record to some sort of E-Business infrastructure, I need to know when the system got it.
There’s been interesting news recently in this space; first is AMQ, an open-source framework for reliable message delivery.
At a more basic level, Bill de hÓra presents HTTPLR: reliable message delivery over HTTP. To be fair, I should note that I’m also aware of proposals for making HTTP reliable from Paul Prescod, Sean McGrath, and myself, and I’m pretty sure they all work.
Keep an eye on this space, it’s an important one.
Norm’s Lab · All this rhetoric and theory can get old fast. Norm Walsh, who’s a practitioner not a theoretician, explored the issues of building out Web Services by, well, building out a Web Service called WITW.
His handful of dispatches probably contains more useful lessons than an inch-thick pile of Gartner and Forrester reports.
Come to Chiba! · Jon Udell isn’t the only one with an event to plug. At WWW2005, the 14th International World Wide Web Conference, which is in Chiba, Japan May 10-14, there’s a panel entitled Web Services Considered Harmful?. This was organized by Rohit Khare, and features, along with me, Jeff Barr from Amazon Web Services, well-known REST-head Mark Baker, programming titan Adam Bosworth (Quattro Pro, Access, IE 4), Jeff McManus from EBay Web Services, and David Orchard of BEA and many WS-related working groups as well as the W3C TAG.
Should be fun!