But there are some notable disadvantages too. In particular, infrastructure costs are the Achilles heel of service oriented architecture. In the meantime, a new paradigm named resource oriented architecture is on the rise. Will this new development obsolete service oriented architectures? And should you act on that now?
The promises of service oriented architectures were and still are ambitious: loose coupling keeps the application landscape manageable, many software packages come with standard connectors for quick and easy integration, and enterprise service bus products are offered to implement service oriented infrastructures that support application integration at enterprise scale. There is no doubt that this paradigm has brought us a substantial step forward from the point-to-point connections we were used to in the nineties.
But these advantages come at a high price: enterprise-scale ESB solutions are very expensive and require intensive systems management. And they introduce new and tight vendor lock-in. And the most common standard for service integration, the http/soap based web services standard, relies on the bandwidth-inefficient XML format for data exchange. It has been ten years already since Erik van Ginneken and I published this article (in Dutch) about building a business case before introducing a service oriented architecture. The message in that article was that the business case is not always positive. And costs are still the Achilles heel of service oriented architecture.
Trends driving change
Two trends from the past years drive a change in the way new applications such as cloud services integrate, a change that is now pushing service orientation and enterprise service buses in the defensive.
The first trend is linked open data. More and more organisations, predominantly in the public sector, are publishing large amounts of data, enabling others, either academic researchers of commercial enterprises, to use that data for whatever purpose. This linked data movement uses new standards, such as OWL (for exchanging ontology information), RDF (for exchanging facts about resources), and URI (for referencing universal resource identifiers), to integrate information from various sources with the purpose of discovering previously unknown information such as correlations, trends, etc. Important is that data items named resources (such as customers, orders, and accounts) are directly referentiable, independent of the system in which that data is managed. The popularity of linked data has increased knowledge and support of these technologies.
The second trend is software as a service. Cloud applications are popping up like mushrooms in autumn, desperately looking for paying customers in order to survive the harsh competition. Many are offering advanced API-based integration functionality, usually based on what is known as representational state transfer or simply REST. REST defines a way of data communication based on uniform interfaces and stateless transfer of resource representations between a client and a server. Again, the popularity of this trend has increased knowledge and support of technology.
A new architectural style
As a result of these trends, we see a new architectural style emerge which we can name resource oriented architecture (ROA). This architectural style combines the concepts of directly referencing resources, stateless communication, and uniform interfaces to integrate resources from various sources and achieve the same or even better loose coupling as service oriented architectures do. This makes an alternative to service oriented architectures that has some significant advantages.
One advantage is that resource oriented architectures do not need an expensive integration infrastructure, as the largest known resource oriented architecture, the world wide web (www), proves. A simple naming service and a resource identification strategy will do to make applications find the resources they need.
A second advantage is that ROA’s are versatile and resilient to disturbances and changes. Applications may change and changes may break services, but resource definitions don’t change that frequently and if they do, it is likely that the client application will want to change anyway, to benefit from the changes in the resource definition. Furthermore, not having a single point of failure (which an ESB basically is) is always an advantage.
A third advantage is that ROA’s reduce applications to a transparent “resource enabler”, acting in the background. Moving a resource from one application to another will only impact the naming server that resolves the resources URI to its URL, just like moving a web site to a different server requires only changing the IP address in the DNS entry. Architectural discussions will be much more in terms of resources and their operations and less in terms of applications.
A fourth advantage is that ROA’s can directly integrate with cloud based applications and linked (open) data sources, enabling agile development of the enterprise’s application landscape. We see more and more use of cloud services and it makes sense to adopt an integration style that fits that trend.
Even though we don’t see enterprise scale resource oriented architectures as of yet, it is only a matter of time when this architectural style will rival and likely replace service orientation. Given the speed of developments right now, that moment could be closer than you think.
Erwin Oord (firstname.lastname@example.org) is a principal consultant and managing partner at ArchiXL.
Neem contact op met ons, we vertellen er graag meer over!