|
|
AS OF 7/4/2008 8:32PM EST
|
January 1, 2008 —
Long live WS-*! WS-* is dead! REST is great! May it rest in peace!
Which one is it? WS-* or REST? It turns out that both camps are lying through their teeth about how "easy" it is to build distributed business applications using their favorite technological approach.
In fact, there is no easy way to build distributed applications; it's simply a hard problem. WS-* and REST (Representational State Transfer) each has its own strengths and weaknesses. Knowing the realities of these different approaches for building distributed systems is critical for being able to make the right choices (and hence sleep restfully on a starry night).
Once you cut through the cloud of hype, it becomes much easier for the confused enterprise architect to understand what to use and when. So let’s take apart the WS-* versus REST debate and clearly separate the facts from the myths and the lies:
WS-* Camp: You need WS-* to build Web services.
Reality: Not true. There are a great many services that do not need WS-*. As long as your requirements are satisfied by the security offered by HTTPS and HTTP Basic Authentication, and you don't need message reliability or transactions, just using REST is the right answer.
To look at this at a lower level, if you're using SOAP to communicate and don't have any headers, then SOAP is not adding any value over a simple XML-over-HTTP approach. Switch to REST instead.
REST Camp: You can build any Web service you need with REST.
Reality: Theoretically you could, but that's not the right practical answer. While there are many services that do not need rigorous security and reliability at the message exchange level, there are also a great number that most certainly do. For example, if you're dealing with medical records, end-to-end security and reliability are absolutely essential.
In that case, you do need the WS-* protocols over HTTP; WS-* is essentially a set of standard, interoperable protocols to achieve these qualities of interaction over any underlying protocol, including HTTP.
The strength and value of WS-* is not its incredible technical beauty—to mimic a comment I’ll refer to later, any damn fool could come up with a better way to sign and encrypt messages and a way to exchange them reliably, but getting the entire world to accept that approach is the problem. WS-* has been through that pain—all the core parts of WS-* are now standards and are supported by ALL major and minor vendors.
If you don't use these, you need to essentially invent similar protocols over basic HTTP, which eventually would result in REST-*! That does not achieve anything other than satisfying your urge to support the “not invented here” syndrome. Fans of technology for the sake of technology will undoubtedly build REST-*, but street-savvy enterprise architects would be best off ignoring it.
WS-* Camp: XML is the best language to communicate in.
Reality: XML is not the best data communications format. Even one of the original inventors, James Clark, said, “Any damn fool could produce a better data format than XML.” But just as English has emerged as the lingua franca of the business world, in the tech world, this role is filled by XML. XML is simply the language that everybody has accepted.
REST Camp: JSON is the best language to communicate in.
Reality: JavaScript Object Notation certainly has its advantages, including compactness, better alignment with object-oriented programming languages and programmer readability. However, we can't use JSON out-of-the-box from a mainframe to a cell phone in a way that is already possible with XML. Also, JSON doesn't come with the rich set of tools that XML does: XPath, XSLT, XML Schema, Relax NG, etc. JSON is great for AJAX scenarios, but it’s not in the same league as XML as a universal data format, especially when the data is not serialized data structures but rather documents. It may get there, but we're far from it right now.
REST Camp: You don’t need a description language because everything has a uniform interface and is self-describing.
Reality: REST takes the approach that the media type you get back from the server is a sufficient description of what that URI is supposed to return. While that is sufficient for the dynamic environment of the Web, where the browser simply has to use the media type to display the content in a human-readable form, developers writing programs need to know beforehand (i.e., at development time) what they will get when they GET a specific URL. Without that, there can't be any tools that make it easier to process the data. REST fanatics argue that such tools represent a form of coupling and hence are bad for the loosely coupled architecture of the Web. While true at a strictly theoretical level, it’s simply unrealistic at a practical level.
WSDL is by no means the best possible description language; in fact, any damn fool could come up with a better one! (Given I'm one of the damn fools who came up with WSDL in the first place, I have no shame in admitting it.) However, it again has an incredible advantage: It is supported by all major vendors. Until we get a more widely accepted replacement, if you're writing Web services, you should describe them in WSDL even if they're RESTful services. The recently standardized version of WSDL (2.0) is significantly improved from WSDL 1.1 and offers a very nice and simple way to describe both RESTful and non-RESTful services.
WS-* and REST Camps: You can simply take legacy apps and make them into a WS-* or REST service.
Reality: Both camps are guilty of promoting this fantasy. Despite WS-* fans’ claims to the contrary, there’s no way you can simply take your old Java classes and magically SOA-enable them. You need code that understands the proper granularity of interactions in a SOA and the underlying business processes, and then you can make them into a service.
Creating a RESTful interaction with an application is no trivial matter either. In fact, there's still quite a bit of art in creating proper REST services, and tooling support is minimal to nonexistent. For certain applications, of course, there is a natural and simple mapping (as with certain other applications for WS-*), but otherwise you need to be a REST artist.
To create a good RESTful interface, you need to understand REST (which by itself can be quite tiring), figure out how to create the proper resource structure for your artifacts, and finally figure out how to create and manage links between them. The last part is nontrivial, but that represents the “hypermedia as the engine of application state” mantra of REST, which is critical for achieving many of the scalability benefits. REST may be easy for simple cases, but it will not afford you much rest when building real systems.
With so many half-truths, obfuscations and outright lies around WS-* and REST, it’s tempting to toss them both out the window. But for today’s distributed applications, WS-* and REST are two of the most viable and useful platforms available.
Instead, enterprise architects should consider adopting a heterogeneous approach to Web services that capitalizes on the strengths of each. For simple delivery or exchange of messages, REST offers a quick, clean, dependable approach. For more sophisticated services and SOA deployments, the rich WS-* stack provides proven, standard protocols for secure, reliable and transactional services.
When choosing middleware, select one that allows you to focus on the business logic and let the infrastructure worry about supporting both REST and WS-* interfaces.
And in all cases, don’t get caught up by promises of plug-and-play Web services that seem too good to be true. Building distributed systems is hard. You need to be ready to do the hard work before you and your team can rest easy…even if you don’t use REST.
Sanjiva Weerawarana is founder, chairman and CEO of WSO2, which sells open source middleware for SOA.
|