Some years ago Service Oriented Architecture (SOA) was put forth as a model for decoupling enterprise services and consumers. Although there are certainly great examples of robust SOA ecosystems, it never really lived up to its promise. Let’s take a look at how the service based internet is different, and why this model has become preferable to SOA in most cases.
SOA arose largely in the context of enterprise services within a single organization. Developers and integrators were finding that their systems were brittle and unreliable largely because of the unreliability of the underlying infrastructure. Many of these systems were highly transactional in nature, and a failure in the resource chain could cause a lot of transactions to end up in an indeterminate state.
To remedy this, a new layer of abstraction was introduced; the service layer. This service layer was designed to sit in front of resources within an application or application stack and provide a brokered mechanism for handling transactions across unreliable resources.
SOA was designed using the most common web services technology in use at the time. Namely, WSDL, SOAP and the WS-* stack of protocols for service communication. WS-* defines protocols and interchange formats for communication, authentication, encryption and reliable messaging, among other things.
The Challenge with SOA
The challenge with SOA systems is largely one of complexity. SOAP and the WSDL standard are relatively complex and defined an entirely new protocol. Moreover the decision to have the transport protocol handle reliable messaging placed complexity into the system that required additional components like message queues to manage. Further, the SOA model often pushed enterprises into implementing heavy middleware components like enterprise service busses.
Ultimately, the complexity of implementation and the fact that that complexity had to be implemented in every component of the system made SOA difficult to implement across all systems within an enterprise and certainly a non-starter for the wider web. As such, SOA is typically only implemented today in distributed systems where transactional reliability and component scalability are critical.
In contrast, the Service Based Internet is a more organic model. In general we can say that the internet seeks simplicity, and the RESTful model is far less complex than SOA.
For starters, RESTful architectures rely on well-established and widely implemented protocols (i.e. http and https) which require little to no coding or configuration to leverage. To wit: why would I implement a whole new transport encryption pattern when https is proven, reliable, secure, and requires almost no extra effort to implement? Likewise, reliable messaging is typically not needed, and where it is needed, it is better off built into the logic of the service than at the transport level.
Moreover, SOA systems require a fair bit of coordination to ensure communication between services and consumers. Such coordination is challenging and costly in distributed enterprises and simply impossible to achieve in the wider internet. Let us accept that we will never guarantee availability or reliability and design our services and apps with that in mind.
Ultimately, it isn’t my intention to declare one model as superior; certainly SOA has its place and can be very effective in distributed computing. Rather, let’s say that the RESTful model lends itself to simplicity and the internet loves simplicity. As such, it’s clear why the service based internet relies on the RESTful technologies and why it has been so successful.
About Chris Sorel
Chris is a senior architect with Statera, focusing on enterprise application architecture and application development. Chris has spent many years in the industry evangelizing user-centric design and the role of custom software in helping companies stay innovative. When he’s not helping our clients, he can be found hiking one of Colorado’s 14ers or rock climbing in one of the front range canyons.