Nearly every software architect has to build applications that operate through Web front ends and feed traditional mainstream applications such as inventory, shipping, billing and manufacturing resource planning. This
On the Web side of the application, there's little doubt that the best approach is REST. Nearly any consumer device from phone to PC has a browser and can accept a URL, which can then open a webpage to initiate a retail application. In virtually all situations, the design of the RESTful end of the application is based on the presumption that the end product is an order and that the transaction isn't actually launched until the order is completed to the user's satisfaction.
Typical retail activity includes the following:
- Creating orders
- Reading product information
- Updating orders
- Dispatching completed orders for processing
The application server, the next layer inward from the user, provides the glue that links the online application to legacy components. This layer is operating on a complete retail order, an order for which product availability has been assured by allowing the user to read quantity-on-hand information and suppressing order activation for items not in stock. Feedback to the user at this point would be via a contact email, since the Web transaction is considered complete.
SOAP is considerably better for maintaining state.
REST vs. SOAP use case issue
In many cases, applications servers are simply front ends to existing applications. Typically, these applications are based on manual order processing or customer service agent support. Human coordination of the order process is sufficient to eliminate ambiguities in the order state should a customer hang up, for example. Where there isn't a human intermediary in the order processing chain, it's up to the application server to ensure the transaction is complete. Otherwise, it's possible the customer may receive nothing, or may restart the order process and create a duplicate.
REST can be used to complete the order in the following instances:
- A product is routinely stocked and the rate of ordering isn't likely to deplete it; or
- A user can be notified after the transaction if an item becomes out of stock due to multiple orders.
The application server is likely the point where RESTful processing will be transitioned into workflow. However, if the order processing requires confirmation of the ability to deliver before the Web transaction completes, feedback to the user from the inventory/production system is needed.
If the legacy inventory/production system confirms an order and the Web transaction is lost before it completes, the order will have to be backed out. That means the application processor will have to maintain an order state for each ordered item and be able to reverse any orders should the Web process fail or be repudiated by the user.
SOAP is considerably better for maintaining state. One would presume that a stateful SOAP transaction would be maintained through the entire Web transaction cycle, in parallel with Web server activity.
Elements in the REST vs. SOAP decision
RESTful components aren't as capable of sustaining context; therefore, they work best when an order is a single process, even though it may involve several screens. If the create/read/update/dispatch process can't be contained to simple webpages, then REST is likely not as suitable as SOAP, and the REST-SOAP boundary must be moved outward further, toward the user, pulling more of the transaction inside the SOAP domain.
The REST vs. SOAP use case is also impacted by performance and reliability considerations. If a user is likely to spend time browsing product catalogs and reviewing information before making a purchase, then it's logical to assume that under heavy transaction load, it would be convenient to replicate multiple Web front ends to support more users.
More articles on the REST vs. SOAP debate
REST vs. SOAP: Which is the best Web service?
Daigneau talks REST vs. SOAP
REST vs. SOAP for mobile development
At the Web server level (REST), the ability to load-share and fail over is almost automatic. This is because the customer system maintains state, and any Web server can be assigned to respond to all requests, even if another server handled an earlier phase of the dialog. For application servers and deeper components of the use case, special handling is required to support load-sharing.
If SOAP is to be used, it's possible to manage state with a back-end database that can synchronize the user's multiphase transactions among multiple application components. This process demands a reliable database update/access mechanism so that the shared state isn't contaminated by a failure of a component or the abandonment of a transaction at a given point. Where workloads are highly variable or where transaction abandonment rates are high, careful design of SOAP-based applications is critical to avoid problems with state and the integrity of critical databases.
Are there any simple rules to be inferred from the use case? It's likely that for new applications supporting Web users (particularly mobile users with high abandonment rates), the goal should be to drive REST behavior inward as far as possible to provide elasticity of resources. Where existing applications are to be used, and in particular where applications designed for internal customer support representative use are to be Web-exposed, it may be best to create a new application server element to form a boundary between a Web-based customer experience and the applications themselves.
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 November 2013