A couple of lively debates are roiling the world of enterprise IT, sweeping up everyone from CIOs and system architects to development teams, security officers, and network administrators. The first debate involves the pragmatic value of a Service-Oriented Architecture (SOA). The second is a dispute between the advocates of SOAP-based Web Services and the advocates of Representational State Transfer (REST)-based Web services to determine which architectural style is best suited to meet the objectives of the agile enterprise.
The SOA Debate
For most vendors and analysts, and certainly for many enterprises, SOA connotes an enterprise-wide initiative to replace monolithic, siloed applications with a collection of broadly accessible services. Vendors, analysts, and architects have been promoting the value of SOA for years, touting the long-term advantage of investing in small, reusable components that can be rapidly assembled to create new services, rather than continuing to rely on lengthy development cycles and large, complex, and cumbersome applications.
SOA has certainly gained momentum in the world of enterprise IT. Recent polls of CIOs show SOA and Web services shooting to the top of the priority list for most enterprises, in many cases bypassing traditional front-runners like security and compliance. Other top priorities, these polls show, include Business Process Management (BPM, the management and optimization of business processes, which are increasingly Web-enabled) and Business Intelligence (BI, the benchmarking and analysis of operational performance). The combination of SOA and BPM makes sense. SOA is about creating an IT infrastructure that can be flexibly deployed to address changing requirements for business operations and business services. SOA, BPM, and BI all have to with agility, efficiency, and visibility.
Given the ever-increasing tempo of the global economy, businesses have a keen interest in becoming more agile. One way to do this is by replacing costly, monolithic enterprise applications, which usually take years to develop and deploy, with a collection of smaller, independent business services that make business logic (e.g., authentication processes, logistics services) available on demand. Over the medium and long term, an architecture that stresses re-usable components will always prove more cost-effective and flexible than an architecture that relies on one-off applications to perform business services.
Nonetheless, some business managers, IT managers, and programmers are rightfully skeptical of the hype that has built up around SOA. SOA implementations take time—usually years. Everyone from SOA vendors to SOA adopters is on a learning curve, trying to figure out what really works and what doesn’t in a SOA deployment. Progress is being made, but most organizations are still in the pilot phase. So far, the results of current implementations have been spotty. A recent study by Nucleus Research found that, so far, only 37% of SOA implementations have delivered a positive ROI.1
This leads some skeptics to say that SOA is too grandiose, comprehensive, and impractical a vision to meet the pressing needs of business and IT. As the analyst firm ZapThink notes:
Most often, the single cause of failure for SOA is inappropriate scoping of the SOA project. Companies too often seek to make SOA an enterprise-wide effort, even though the business case for that is typically not justified. . . . SOA is simply not appropriate for all problems.2
This perspective, coming from a firm known for its bullish attitude on SOAs, reflects a growing consensus that while SOAs have their value, enterprises would be misguided to try to funnel all their integration and Web services solutions through a grand SOA implementation. SOA should not be all or nothing. Enterprises can take an incremental approach to services roll-outs, sometimes building on SOA and other times, when appropriate, deploying distributed data services around the edge of the IT infrastructure.
SOAP vs. REST
Another debate focuses on a closely related topic: Web services, the delivery of application and data services using HTTP and other Web-based technologies.
Web services provide a convenient and powerful interface between applications. This is, in part, because Web browsers and Web servers are now ubiquitous, and it makes sense to leverage this familiar client/server infrastructure for new services. It’s also because Web services have the potential to deliver automated and ad hoc services that span multiple enterprises and organizational domains. And finally, it’s partly due to customers demanding that new applications and services be able to integrate with products from other vendors.
The promise of SOAs based on Web services drove the creation of the SOAP and WS-* standards and for a long while it seemed that SOA meant SOAP and WS-*, and the terms became nearly synonymous. Meanwhile on the public Internet, different kinds of Web Services such as the data access APIs provided by sites like Flickr, Google, Amazon, Yahoo and the data available from other sources like RSS feeds —all based on simple RESTful interactions—were being rapidly adopted for a wide range of loosely coupled, integrations.
The success of simple, public RESTful Web services caused some developers to reconsider using the increasingly complex WS-* and SOAP to achieve their SOA objectives. They then began to promote REST for SOA3 as a credible alternative that could be successful without any of the overhead or complexity of SOAP or WS-*. Therein lies the debate: SOAP vs. REST.
Web services developers seem to be confronted with a choice: either develop services based on SOAP interfaces, the WS-* family of specification, or develop services based on a more bare-bones REST infrastructure based primarily on a few basic HTTP commands (GET, PUT, POST, DELETE). The SOAP and WS-* specifications were developed to provide reliable, secure messaging for mission-critical applications. But they add complexity and overhead to services. In contrast, programming in a REST style is simpler and faster. It omits some of the rigorous controls available with SOAP, but often these controls are not needed for internal services, or the same level of control and security can be achieved through the standard techniques developed for VPNs and security of Web traffic.
Given the business need for more information from more sources, it’s understandable that some business managers and IT teams would want to take advantage of the rapid development cycles enabled by REST. The promise of direct access to services, via sophisticated, interactive interfaces made possible by AJAX and Web 2.0 programming techniques, is too attractive to pass by. Analyst firms, who formerly promoted best practices based on SOAP and WSDLs, now concede that IT organizations have been right to prefer REST for most of their Web services solutions. Anne Thomas Manes of the Burton Group, for example, states flatly that the future of Web services is REST.4
But many SOAP supporters are alarmed by the growing popularity of REST. They worry that REST’s popularity comes at the expense of the more rigorous programmatic discipline derived from the SOAP and WS-* standards, and that REST is undermining the primary objectives of SOA: Instead of contributing services to a strategically important, tested, and sanctioned collection of enterprise services, REST developers seem to be creating “quick-and-dirty” Web solutions, many of which may turn out to be unique, un-reusable programs—as much a “one-off” as the monolithic enterprise applications they are designed to replace.
How should one make sense of this debate? Even in organizations that support the vision of SOA and are pursuing SOA implementations, how should programmers meet their urgent, short-term deadlines (e.g., the data feed needed for the BI dashboard, which is just as high priority as the SOA initiative) until the comprehensive roll-out is complete? Is there room for a middle way, an approach that acknowledges the value of structured SOA based on SOAP and WS-*, while enabling developers to solve problems efficiently in the here and now?
The Router Analogy
One way of understanding the best use of SOA, SOAP, and REST is to compare them to other areas of IT infrastructure where the requirements are pervasive, yet still vary tremendously across the enterprise. One such area is network infrastructure. Today, no one would disagree that a network needs both switches and routers. But when switches first appeared there were people that considered them a throwback to the earlier days of bridged networks. Even among routers, there are two fundamentally different types designed for completely different needs, yet everyone today would agree that each has its place. Core routers route packets between other routers within the core of the network, while edge routers route packets from the core of the network to other networks. No IT organization would confuse the two types of routers. They serve different purposes, and many enterprise networks needs both types.
But that doesn’t mean that every enterprise network needs both kinds of routers. Department LANs, small offices, and home offices typically require only edge routers. Conversely, a large telecommunications company might have an entire division that runs exclusively on core routers, using no edge routers at all.
It’s clear that a services architecture shares many of these network characteristics. At its core, the architecture requires an essential set of stable, high performance services. These are often implemented with an Enterprise Services Bus (ESB). The ESB provides messaging and transactional services for tightly coupled integration with applications. It’s a centralized function, like the function of a core router. But, analogous to a network “edge,” there’s also a “services edge” that supports varied, loosely coupled integrations with endpoints such as Web sites, desktops, departmental applications, hosted applications, public Web sites, search and mapping services, RSS feeds, etc.
Does every integration require an investment in a SOAP/WS-* based SOA? No. These SOAs are like core routers. They’re great for certain operations, but they’re not appropriate for all operations. Other integrations, which take place at the functional edge of the enterprise infrastructure, can take advantage of technology that lends itself to more rapid and flexible development and deployment.
Labels: REST, SOA, SOA vs. REST
Now you can shoot video, edit it, and share it — all on your iPhone 3G S. Shoot high-quality VGA video in portrait or landscape. Trim your footage by adjusting start and end points. Then share your video in an email, post it to your MobileMe gallery, publish it on YouTube, or sync it back to your Mac or PC using iTunes.
