This chapter is from the book
This chapter is from the book
This chapter is from the book
RESTful SOA
Before closing this chapter, which has been a whirlwind tour of REST, JAX-RS, and JAXB, as well as how to use them in the WebSphere Liberty Profile and Eclipse, we need to talk about the way in which the services we’ve been talking about here relate to the Enterprise services you might also want to implement. The problem is exactly how often the technologies discussed here, as powerful as they are, should be applied.
An old adage that still rings true is, “If all you have is a hammer, everything looks like a nail.” That’s true of technologies as well as physical tools. Another truism is that all technologies follow the “hype cycle,” popularized by the analyst firm Gartner, Inc.5 In the hype cycle, all technologies first encounter a period of inflated expectations, followed by the inevitable “trough of disillusionment.” In the years since the publication of the predecessor volume to this book,6 the hype cycle has definitely run its course for Enterprise Web Services with SOAP and the WS-* standards. Many people tried applying the WS-* standards to situations for which they were not appropriate, or when something simpler would definitely have worked better. However, it’s easy to see that the REST services that are rapidly replacing WS-* in the hearts and minds of Enterprise developers could soon suffer the same fate. You have to be smart about what you’re building when you’re crafting a service and what you’re building it for. Otherwise, REST can simply become another hammer used inappropriately for trying to insert a wood screw.
It also comes down determining what each different service implementation approach is best suited for. REST is about exposing content through HTTP; it does not replace traditional WS-* web services. Traditional web services are much more about program-to-program integration. The WS-* approach allows for a variety of protocols and integrating logic. For example, you might need distributed transactions and message delivery on top of a reliable protocol such as JMS when assured delivery is essential.
Traditional web services built using WS-* standards are about technology abstraction to allow for a wide variety of infrastructures. REST-based web services are about HTTP exploitation, to take advantage of a single delivery channel. For example, WS-* abstracts security through WS- Security, enabling you to apply security policies away from the code and abstracting the encryption methods and decisions such as token providers. REST-based services, on the other hand, make assumptions, using HTTP security mechanisms such as Open ID or HTTPS for encryption.
The real key lies in channel abstraction rather than channel exploitation. REST does not address transactions, reliability, or standard context propagation, or other protocols such as messaging. However, these are important considerations for the enterprise as a whole. REST is great for the responsibilities it is meant to handle, but it can’t do everything. The two approaches can coexist in the same enterprise—and they should. Always make sure you choose the right tool for the job.