Creating flexible, loosely coupled solutions based on web services and implementation agnostic protocols is the cornerstone modern enterprise design, but underneath the covers a contentious debate rages over whether a service oriented, or resource oriented approach to software design is best. It is important for any IT professional to understand the difference between these two approaches, and when one approach is preferable to the other.
Service oriented architectures (SOA) burst onto the IT scene over a decade ago. Since then, SOA has delivered many benefits to businesses. Even as it has divvied up processes and programs into more manageable sections, it has helped resolve some of the fragmentation issues facing the enterprise application suite by easing integration. For example, the SOA approach makes it possible to wrap existing legacy assets to allow modernization without a complete recreation of older applications. It also has benefits on the development and management side by promoting and supporting reuse of services across a broad range of scenarios.
Some SOA benefits are MIA
The grumbling amongst those who are dissatisfied with SOA has risen to a dull roar over the past few years. According to Steven Bristol at Less Accounting, "Service-Oriented Architecture is an extraction done for scalability, easier to maintain code, and segregation of business logic by function. Since you can't see all possible ends when you start, you're basically guessing at how things should go." As you can imagine, the difference between educated guesses and blind stabs in the dark accounts for a lot of the issues architects run into.
Will businesses ever learn that just because a particular solution works for a lot of problems, it isn't the answer for everything? One big problem businesses have is trying to use SOA when they should be relying on something else. This methodology can prove to be unwieldy and resource-intensive if it is used incorrectly. Matt Brasier, Head of Consulting at C2B2 and coauthor of Oracle SOA Suite 11g Performance Cookbook, says this is a pretty common mistake. Businesses that treat SOA as a panacea for every IT ill are bound to be disappointed. Over the past few years, there has been a pendulum swing away from a service based focus for API development and a rush to implement a resource based approach (REST). The fact is that SOA and REST serve different purposes within the application world, but both are useful and both can serve and important purpose.
Knowing when to give it a REST
Arnon Rotem-Gal-Oz, the author of SOA Patterns, holds that REST does deserve its reputation for making things easy, but only if you use it correctly. "REST democratizes services. It allows you to build using simple tools and interfaces, get things going, and become more agile. One advantage of the REST movement is that it lowers barriers. You can get into trouble like you can get into trouble with any technology. But making simple things simple is a big win." He says even just using the HTTP verbs can help you gain flexibility.
Brasier says that, with the resource approach, you cut away a lot of the unnecessary overhead. At the same time, you have little margin for error and less ability to tailor the transaction. You need to have a lot of information including the structure of the resource since the contract is not well defined. You can't really put together a highly complex query without relying on SOA. For this reason, REST works best within an application or between two closely linked applications that know a lot about each other. They have to be able to make assumptions that hold true to deliver the desired results. .
Not SOA Fast
According to Brasier, "SOA is designed to be a high level architecture for how you expose parts of large-grained services across your enterprise and how you route traffic between those services. REST is much more about exposing fine-grained parts of an application." Brasier sees the current popularity of REST as a reaction to the overuse of web services and SOA in ways that weren't appropriate. Large SOAP envelopes aren't the best answer for actions that don't need that level of management and quality of service. In other words, you don't go hunting for quail with an elephant rifle. You have to match the tool to the target.
Arnon points out that SOA came into being in the first place because of the need to build distributed systems. It lets you model and componentize your system while incorporating flexibility. It's the principle of the thing, not rigid adherence to doing everything the SOA way that brings benefits. The inherent flexibility of the concept itself is what makes service oriented architecture viable even as technology changes around it.
How are you pairing SOA and REST to get the best of both worlds? Let us know.