Componentized applications need mechanisms to link the components to pass work along. From the start there has...
been a polarization of views on the linkage process and a divergence of implementations. Arguably, the SOA camp evolved from software interfaces that became Remote Procedure Calls (RPCs) and eventually Simple Object Access Protocol (SOAP). This approach results in secure, highly-architected interfaces.
On the Internet side, interfaces started as remote resource references contained in HTML. The process formalized into Representational State Transfer (REST), and now there are hints a third model might emerge. To decide whether the birth of a new model is more than hype, it's important to consider what factors may drive such a development, the problems it would solve and whether revolution or evolution is the best approach.
Stresses on SOA and REST architecture
At one level, there are already pressures on SOA and REST to accommodate two key application trends -- support for workers at the point of activity and the use of elastic virtual resources to host components. For architects, it's critical to understand how much pressure these factors generate beyond media and vendor promotion.
Mobile devices tend to offer more focused information to workers because they're used tactically on the road. Since what and how information is presented to a worker is often the function of a Web front-end or a separate GUI component, making changes to support mobile devices may not require changing the componentization model. If that's the case, there's little need to think about new application interface choices.
The successor to REST is likely to be a consolidation of SOA and REST principles.
Elastic resources present a more immediate challenge, particularly the cloud. Most workers access cloud applications via the Internet or an Internet VPN, encouraging RESTful interfaces. However, applications designed to run in the data center are often SOA-based and have not been designed to support resource elasticity by multiplying or removing components in response to changes in load. It is this challenge that has driven most of the demand for a new interface -- something that is dynamic like REST but more secure and controllable like SOA, SOAP and Web services (WS).
In the resource elasticity area, the REST limitation most often cited by architects is the lack of explicit support for scale-in or out. The issues architects think need to be resolved are reliable load-balancing among components sharing a workload and control of state both among component copies and within a single component.
REST presumes state is controlled by the client side, but most applications have stateful updating. Even some Web activities could create situations where switching consecutive client or component interactions to different components through load balancing would break the application. Back-end state control seems like a logical solution, yet there isn't a standard way of providing it or knowing whether it's available.
Even without considering dynamic resources and their impact, the drive for composable applications and componentization puts stress on the REST model. The problem of most concern to architects is the lack of explicit support for functional- and property-based binding of components.
Unlike most SOA bindings where browsing based on WSDL is possible, there isn't explicit support in REST for validating functionality and parameter support at the point of interfacing. Some have suggested forming a standard way to validate the compatibility of a client and component during connection, but there isn't an agreed approach. The problem of binding control is complicated if client-to-component relationships change because of scale-in or out and load balancing.
More on REST architecture
Why REST architecture works well for SaaS integration
Making the decision between REST and SOAP Web services
It's possible to visualize the solution to REST API challenges as a set of enhancements to REST to make it more SOAP-like, changes to SOA to make it more RESTful or the creation of a new standard combining both. A completely new approach seems unlikely to succeed given the range of applications already deployed with SOA or REST APIs. An evolutionary approach to addressing the problems of component multiplication and resource virtualization is likely the best approach.
Approaches to REST architecture woes
Most believe the best approach to enhance REST is directory-driven binding where a client accesses a RESTful API by first obtaining a token from a directory. The token provides the application link and validates available services (load balancing, state control) and the specific format of data exchange. Since this is much like what SOA does with WSDL, it seems logical to call this a WSDL extension to REST. It would be a matter of choice in the interface design whether the REST API required a token to respond or could default to normal REST behavior.
Evolving SOA APIs to a RESTful model is already happening. Typically this means nothing more than taking the actual application connection and making it RESTful by eliminating in-component state control and SOAP. This REST extension to SOA seems to take the evolution of APIs to the same point.
Currently, SOA and REST are relatively safe inside their own missions. The question is whether new applications will create dynamic relationships that stress REST and SOA to where another approach is needed. If that approach is driven more from the cloud side, then WSDL-like extensions to REST seem likely to become the preferred interface. If the evolution of current applications drives progress, then it's SOA that will evolve and REST will remain focused largely on Web front-end processes. In either case, the successor to REST is likely to be a consolidation of SOA and REST principles.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Tom Nolle, Contributor asks:
Do you think elastic resources challenge REST architecture?
0 ResponsesJoin the Discussion