Does Java EE 5 getting REST mean WOA will break out?

The REST vs. SOAP debate can seem like an esoteric discussion about Web services, but it's not.  REST puts the Web back into Web services by taking what's been so successful with the fundamental protocol of the Web, namely HTTP, and making it into a seemingly ideal Web services architecture.  This model has been called Web-Oriented Architecture in certain quarters, and the label does seem to fit. REST, and its little brother, XML over HTTP, have increasingly gathered mindshare lately by sheer Darwinian competition.

SOAP is an a priori concoction created early in the life of the Web, while REST is a natural extension of that most successful Web services protocol of all time, HTTP. And now, like so many things lately, best practices from the Web, such as REST, are flowing back into our enterprise architectures and related products.  And for good reason.

For example, the new Java EE 5 (good coverage of this release by ZDNet's Joe McKendrick here) now significantly includes built-in support for REST.  Unfortunately, J2EE expert Richard Monson-Haefel has a raft of concerns about JAX-WS 2.0 (the actual name of the new Web services support in Java EE 5), specifically about the dizzying complexity required to implement it.  This is genuinely unfortunate because REST has some extremely powerful capabilities to bring to the table and Java is one of the most heavily used enterprise platforms in history.  REST's ease-of-consumption, interoperability, and performance – all due to its simplicity and true harmony with HTTP – are its most important attributes, but this can potentially be undone by excessive cruft.

Read this distilled overview by Doug Kohlert to see what it looks like to develop a simple number adding REST service with JAX-WS 2.0 in Java EE 5.

We get into Web 2.0 territory with the REST/WOA discussion when we talk about turning applications into platforms.  Specifically, this means turning over the Web services that your application is based on to your customers for reuse, hopefully to encourage some of those second-order unintended uses that Web 2.0 proponents talk so much about.  For its increased reach alone, this is were REST can be much more helpful than SOAP.

Contrary View: Read Mark Nottingham's excellent notes about SOAP/REST and Web 2.0 companies using REST, sometimes not so well. 

SalesForce has opened its platform up in this way and the results of people reusing these services can be seen on AppExchange.  Amazon also does this with their enormously profitable Web services division, and so will many others as the value of doing so becomes clear.  Thus, for an increasing number of companies, how services are delivered over the Web to customers is of vital competitive relevance.

However, it's been my experience, and many others, that SOAP, the classic Web services standard, does a generally poor job in highly heterogenous environments, of which the Web is the most canonical example.  Part of the problem is that SOAP wasn't designed for the "leaks" that tend to occur when SOAP processing is highly automatic, like it is on most major development platforms.  A classic instance of this is the older implementation of SOAP for Java; it had nine serious yet often subtle flaws that didn't come out until it was used extensively.

But my purpose here is not to bury SOAP but to praise REST (and note that SOAP can sometimes even be used entirely RESTfully).  In fact, it's becoming clearer and clearer that simple, straightforward techniques that embrace the fundamentals of the way the Web works and don't abstract the it away (such as most SOAP stacks do, for example), is a preferred way to go.  Though even Sun's own folks seem to emphasize that REST is primarily a quicker way to implement Web services, the real advantages however go much deeper. 

This is why you'll see REST used more and more, both in the enterprises as lightweight SOA and on the Internet as the underpinning of Web 2.0 sites and Software as a Service (SaaS):

Advantages of Using REST/WOA for Web Services and Turning Applications into Platforms

1. Interoperability is automatic and guaranteed, without long lists of subtle gotchas and security holes, as long as your environment supports plain XML and HTTP.  Heterogeneity between REST client and services is essentially unlimited and virtually every environment in the world can handle XML and HTTP.  REST can be used between any two Web computing systems in the world.
   Update: REST expert Mark Baker sent me a helpful note that recommended I reemphasize here that REST is not just XML and HTTP, but also a very specific lightweight architectural style originally propounded by the inventor of HTTP, Roy Fielding.  REST = HTTP, state representation (usually XML), and simple RESTful patterns.
   
2. Ease of Consumption:  SOAP, particularly when used with a bunch of other WS-* protocols, is sometimes like building a shipping in a bottle.  Finding the right toolkits, making sure schemas match and work in the underlying language, understanding the interaction model of the Web interfaces, all impose a consumption tax of time and energy.  REST is resource-based and provides a standard organization system based on URIs that is consistent, simple, and highly flexible.
   
3. Leverage Web Infrastructure: Takes advantage of most existing infrastructure that makes HTTP better, faster, and secure.
4. No layers or wrappers, means less bugs and loss of control: Does not add an abstraction layer with moving parts that can break.  This includes mapping to objects, an API wrapper, or anything else that obscures what is being passed back and forth, and how.  This eliminates complexity and layers that can fail or get out-of-sync.
   
5. Maximum Flexibility: Great increases the flexibility of processing, including when and how interface contracts are checked, how much of the data retrieved is actually processed, etc.  This is vital in highly federated situations where the other side can change structure unexpectedly or suddenly send you a lot more data that you expected.
   

Of course, I would be remiss without emphasizing that no technique in the world is appropriate in every situation.  SOAP, and WS-*, and heavyweight SOA are entirely appropriate in certain circumstances.  This is part of having a good architecture that doesn't try to be all things to all people and even REST doesn't have a place in every situation.

Read a discussion on tolerance continuums to understand flexibility at the edge of Web architecture.

 The bottom line, if my job was to make sure the Web services for my Enterprise Web 2.0 app were usable by the most number of people (especially without knowing their toolset in advance), had to highly maintainable, be easy as possible to consume, scalable, and took advantage of existing infrastructure investment, then REST/WOA is at the top of my list.

Finally, this article is also part of my discussion of exploring Web 2.0 strategies in the enterprise. Specifically, along the axis that RSS and ATOM are excellent protocols for syndication and are popular on the Web, but deep heterogeneous application integration, Global SOA-style, is often best done using Web

Did Java EE 5 completely blow it with its new Web services support?  Is it just "lipstick on the pig" like Monson-Haefel says?