Software architects have long been vying to create compostable applications from multiple linked components. This model offers better development economy and easier application lifecycle management (ALM), but it raises a question of the software model for componentization.
Should applications be based on the lightweight Web-model representational state transfer (REST) or on the business-proven service-oriented architecture (SOA)? The answer depends on where the development began, the nature of the components and the extent to which the applications are likely to be linked to thin-client applications.
Key differences between REST and SOA applications
The greatest difference between REST and SOA applications is likely the mechanism with which they control state, which is the context of a given message in the overall flow of processing a worker transaction or request. The software design needed to support these two state-control strategies is very different. The first question an architect has to ask is whether software in place has already made the REST versus SOA choice by default. With SOA, state control typically rests with each of the components. The relationship between components has to be maintained through a logical process so individual messages aren't interpreted out of context. With REST, state is transferred from component to component as part of the message.
The second most significant difference between REST and SOA applications is that the latter typically has a more robust facility for describing the interface between components and binding based on interface and functional capabilities. While it's possible to manage component binding in RESTful processes, and even to have browsing and dynamic binding, the facilities are more limited and far from standardized. That means that for highly dynamic component workflows, SOA may be better.
Adapting applications based on legacy design
As recently as 2010, companies reported that most of their business applications had evolved from designs and code developed at least five years ago. Their software practices were modular in execution but not componentized, and thus there was no particular consideration given to issues of componentization and workflow steering. Even where later work created components and workflows, companies report that basic application logic has remained largely intact.
The greatest difference between REST and SOA applications is likely the mechanism with which they control state.
Where an application is largely based on legacy design, it is almost certain the application was written with stateful components. This means adapting the application to REST would be considerably more difficult. SOA, on the other hand, can easily accommodate stateful components.
Stateful Web services can usually be created from legacy applications without serious reworking. If an application is relatively mature, it can be assumed SOA componentization should be used unless there is a clear need to redesign the application.
Where new applications or new components are being developed, the burden of legacy design is less likely to make a REST versus SOA choice for you. Here, the question may be the nature of the interactions among components. There are two things to look for: the need for horizontal scaling or cloudbursting and the need for multi-phase commit or reliable transaction processing.
Implementing REST and SOA application hybrid designs
Since RESTful interfaces between components carry necessary state information with the messages, it's easy to spawn additional copies of a component to accommodate changes in workload, or to spin down one or more copies when work lightens. With SOA, this type of scaling is more complicated because a new component may not inherit processing state correctly and thus process messages in the wrong context. Generally, the more Web-like or cloud-like an application is, the more likely it should be built with RESTful interfaces.
Where transactions must update multiple databases, however, SOA may shine. Multi-phase commit -- the finalizing of a transaction only when all the impacted databases have been updated -- is easily handled in SOA, but will require some design finesse in REST. It's not possible to do reliable transaction processing without some stateful component, so a hybrid of REST and SOA applications is needed at the minimum, and possibly a complete SOA implementation.
REST and SOAP resources
Choosing between REST and SOAP
REST or SOAP for mobile apps?
SOA e-commerce app uses REST and SOAP
Hybridization could be a useful notion for anyone going through the REST versus SOA decision process. It's possible to build a componentized application using both approaches. In fact, this is often done when Web-server front ends are employed with more traditional application servers.
Computational tasks and database access can be made into RESTful components that can horizontally scale as needed. Where strict transaction reliability is mandated, workflow could shift to a SOA-based interface to permit precision control of state even during a component or network failure.
Determining the need for dynamic binding
The need for dynamic binding in applications is difficult to assess. Some users say they rarely need or use SOA facilities to describe interfaces in a catalog for selection, where others feel it's a helpful capability. SOA binding definitions may be valuable in ALM itself where :
- an application crosses company boundaries with workflow;
- a high degree of componentization is expected;
- a high level of component reuse is anticipated; and
- many developers may be working with a common set of components.
For general applications, one must consider how often binding of components will change.
The final issue is the data presentation question: whether the application will support dynamic-based client devices, such as would be the case for mobile empowerment. Mobile connections are less likely to be reliable.
Careful transaction control will be important, but SOA interfaces to mobile devices are rarely used. This creates a distinct REST-SOA front- and back-end model. If application development is on the front end (or presentation side) then REST is the preferred choice. But if so, SOA or some form of transaction recovery will be critical on the back end.
Best practices should always give a nod to current practices, too. A company with considerable SOA experience and little experience with RESTful interfaces should think twice before shifting for a single application, and vice versa. The team's skills are the final decision-maker.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in September 2013