Nmedia - Fotolia
Service oriented architecture is probably the seminal concept of modern IT, but many question its relevance in a web-driven future. SOA, it is said, lost to the REST model. But for application architects and developers, SOA still drives the evolution of distributed computing and even modern concepts like microservices. In 2016, SOA got back to basics, separating the notion of service from the model of service coupling, integrating SOA with the cloud in an efficient way and building bridges between legacy services and microservices.
The goal of SOA
When it emerged in the early part of the 2000s, SOA's goal was to create applications from composable services, which, in effect, built a composition of interfaces. By building applications from service building blocks instead of from traditional code, development costs could be minimized and application consistency maximized. That goal is as accepted today as it has ever been.
Unfortunately, the SOA goal is does not always define exactly what interfaces are being composed. A service in the original sense differs from a module in that services are network coupled. It's not surprising that early SOA advocates gravitated toward extending the modular programming concepts of the time over network connections of the time. Modular programming practices of the time were based on procedures, so early SOA development focused on remote procedure calls (RPCs). The early web services (WS) specifications focused on creating loose component coupling described by XML and implemented using RPCs over private company networks.
Unlike WS SOA, internet computing evolved from the model of a procedure or service as a resource object, accessed via representational state transfer (REST). Because REST is a different implementation model, the approach competes with the WS/RPC model of service interfacing. But both the REST model and WS/RPC model support the same higher-level goals SOA was supposed to support. Eventually, it was discovered that services-based computing wasn't a single implementation model or path.
Now, the cloud
In 2016, the cloud became a development platform. Amazon and Microsoft both enhanced their cloud offerings to include a wider range of web services that specifically target new applications. By focusing these services on emerging areas like mobility, internet of things, artificial intelligence and functional programming, they've worked to make the cloud the initial platform for these kinds of applications.
Experience with the first true cloud applications impacted enterprise application planning. It was learned that some service-based applications evolve from co-loaded modules that are dispersed short distances over private networks. This remained prime turf for the WS/RPC model of SOA. Others evolved from internet and, now, cloud principles, where services are resources shared concurrently by users distributed perhaps even globally. These favored REST, and so enterprises increasingly saw SOA as a goal. Both WS/RPC and the REST model were seen as paths to achieving that goal.
An emerging development model coming late to the market can face daunting challenges in penetrating current practices. Focusing cloud- and REST-modeled SOA on new applications can offer a path forward, but there are still millions of legacy applications to deal with. One critical strategic development in 2016, largely overlooked, is the increased support Microsoft offered for web programming in .NET and in Azure. Microsoft has been one of the champions of the WS/RPC model of SOA, and it enhanced the interchangeability of Java and .NET in application development. Not only did this help users evolve to what is in effect a REST model of SOA, it created both tools and developer notes that let users build RESTful services as well as WS/RPC services almost interchangeably in whatever language was convenient.
WS/RPC and REST aren't just different ways of doing the same thing, though. The WS/RPC approach has always been about directories and service discovery, while the REST model has focused more on defining basic XML or JSON APIs. API management tools already existed, but in 2016 the API gateway and manager became a unifying repository for service information for both WS/RPC and RESTful services. Companies like Akana pioneered a development model that's centered building services on API design rather than on simply registering the APIs services happen to expose.
The microservices factor
All of these trends collide in the emerging area of microservices. Even advocates of the WS/RPC model of SOA admit that microservices are being driven largely from the web side, and it seems likely that microservices will shift the balance of power in implementing SOA interfaces from WS/RPC to REST. Microservice based development exacerbates the challenge of ensuring that applications that invoke services do so properly, and that services are secured and meet internal governance requirements. This is already impacting API gateway and management products, and the result is something that functionally resembles the web-services model of SOA registries and security but also serves REST.
What 2016 has shown is that the SOA model is still the foundation of modern application design. The demands of web-distributed, scalable, multiuser, services embodied in the evolution to microservices has simply forked the path to SOA. The future is not a battle between SOA and REST, but a symbiosis of WS/RPC and REST interfaces under an evolving API management and API gateway architecture. REST is evolving to implement SOA, and SOA is expanding to support that additional implementation path.
A transformation to the SOA model that 2016 has demonstrated is going to take time and work. Current WS/RPC applications can be absorbed into API management and gateway tools, but in some cases, it would be better to evolve the applications into RESTful services or microservices to take full advantage of the cloud's capabilities. Now, though, all the tools and practices to support this kind of application evolution are available, and SOA is free to develop in the way that works best for its users.
Why people need to be the center of your SOA governance model
Learn about alternatives to RESTful APIs for accessing object storage
Choosing between SOAP and REST