A Simpler Approach To SOA

REST VS. SOAP: A MIDDLE WAY
Ed Lyons, enterprise architect at Keane, a global services firm whose specialty is IT and business transformation, says that if Amazon, Google, and Yahoo have made the move from SOAP to REST, then it's high time for other companies to consider following their lead.

"I tell my large corporate clients that their requirements can't be more strenuous than those of a $30 billion-dollar Internet-focused company like Amazon .com," Lyons says. "The complexity of the SOAP WS-specifications is unnecessary most of the time. It's better to have simple standards that are broadly useful but don't cover everything."

Asked whether WOA or SOA is the best way to do business transformation, Lyons says it doesn't have to be an either/or answer. If you accept WOA/REST as the grassroots way of doing SOA, and WS-*-style WSDL-based SOA as the top-down way, then there's a strong business case for using WOA/REST as a way to get your feet wet with SOA--whether or not your company wades any deeper into the SOA stream.

Mozilla's chief evangelist, Mike Shaver, offers this explanation of why Mozilla went the WOA route in adopting MindTouch's Deki Wiki as the future platform for its developer community. "Mozilla has a large volume of developer-relevant information, ranging from traditional documentation and sample code to test suites and bug-tracking data, as well as a number of active discussion forums and RSS streams," Shaver says. "More than any other wiki system we looked at, Deki Wiki feels designed to be extended as a platform for Web applications. ... Whipping up a new extension or integration point is easy enough that even a chief evangelist can do it."

Surprisingly, the argument that WOA is compelling for simple ad hoc development but that companies need to stick to the full Web services SOAP stack if they want secure, reliable, manageable services is also being refuted by recent advances in a new generation of XML hardware appliances. These devices--by the likes of Cast Iron Systems, Cisco, IBM DataPower, and Sonoa Systems--secure, accelerate, and route XML and can make the various WOA/SOA/Web 2.0/software-as-a-service preferences of corporate customers and partners work together. To that extent, existing SOAs can be extended with resource endpoints, and new WOAs can be extended with service-oriented end points. In many cases, hybrid systems may make the most sense.

DESIGN IS EVERYTHING
As we said at the outset, SOA isn't fundamentally about technology; it's about design. It's possible to implement a service-oriented system using any type of distributed computing technology: HTTP/REST, SOAP, Corba, DCOM, RMI, Jini, Fax, Telex, or even (if they're handy) tin cans and string. A simpler technology such as REST can be a great way to make SOA successful because it emphasizes the importance of establishing communications between endpoints with your tin-can telephone, as opposed to fretting about the size, shape, and composition of the various receivers and transmitters. IT groups must decide if it makes more strategic sense to get their endpoints talking or to focus on the clarity and security of the conversations. One doesn't preclude the other; rather, it's a matter of priorities and resource allocation.

It's important to remember as well that if you go with a lightweight, bottom-up WOA approach, you won't want to spend too much time decorating and WOA-izing your network tree, since at some point it's probably going to get thrown into the yard, along with the other discarded models that your end users have become enamored of over the years. This gets down to the fundamental difference between design and implementation: Implementations always get thrown away at some point, whether they're based on top-down SOA or bottom-up WOA--but good design is forever. In Web years, anyway.

Illustration by Mick Coulas