Adoption of REST for Building Enterprise Integration Architecture

1.                         REST versus WS_*

Information Technology Industry is facing huge challenges on adoption of Service Oriented Architecture (SOA) for implementing loosely coupled service based solutions. There are a primarily two architectural practices that have come to forefront in adopting Service Oriented Architecture. One standards is called Web services standards (WsS-*) and other is Representation State Transfer (REST).

There are number of Web Service Standards that are in practice, in terms of implementation and solution adoption. Whereas REST focuses on Simplicity as the fundamental principles with fewer standards.

Enterprise Level Integration Architectures, more specifically EAI(Enterprise Application Integration), Brokers and ESB (Enterprise Service Bus) provide the critical background processing and Integration capability to enterprises. By the very nature of the reason for its existence they need to be stateless, asynchronous and loosely coupled to accommodate for easier integration, flexibility and scalability of the architectural solution.

WS-* and REST are being adopted in the industries to solve their Integration Issues.

Recent technology trends in the Web Services (WS) domain indicate that a solution eliminating the presumed complexity of the WS-* standards may be in sight.

Advocates of Representational State Transfer (REST) have come to believe that their ideas explaining why the World Wide Web works are just as applicable to solve enterprise application integration problems and to simplify the plumbing required to build service-oriented architectures.

The objective of this point of view is to provide adoption parameters from a perspective of enterprise integration architecture principles.

The attached document provides the comparison summary for REST versus WS-* from an architectural principle and technology perspective.

1.1.                  Key Architectural Principles Advantages of REST over WS-*

REST has the following strengths over WS-*

a)      Simplicity: REST is intuitive due to simplistic nature of its principles and adoption techniques.

b)     Fewer Standards and Well Proven Standards for Implementation: Fewer Standards means like HTTP, XML, JSON, JAX-RS, RSS and WADL.

c)      Promotes effective Loosely couples architectures without contracts: These features make REST highly extensibility and Open. 

d)     State management can be performed through the use of resources. Therefore promotes very level of scalability

1.2.                  Key Adoption Factors for Integration Architectures

a)      Where Simplicity and Scalability of the Integration Architecture is critical to delivering business needs, then REST is a good choice

b)     Where State Management is not a key function of the Integration architecture and state may be managed through source or target application resources.

c)      Where Synchronous processing is a key requirement: In case an Integration Architecture requires synchronous processing between source and targets applications then choice of REST may be considered a good choice. However where Integration Patterns required are asynchronous, then REST may not be a suitable choice

d)     Where Performance, Reliability, Interoperability is critical to the delivery of the   solution: REST due to choice simplistic and well established mechanism of solution implementation, is a good choice. Use of XML as the base data interchange technology in WS-* standards makes it really resource expensive solution.

e)      Where Cost plays a crucial role in delivering loosely coupled solution, then REST is a good choice.

f)       Where cross domain integration is required, then REST may be a very good choice of Integration

g)      Where Transaction Management, Orchestration, routing, correlation, aggregation, discoverability, choreography and Transformation is a critical to delivering Integration Architecture, then REST may not really a good choice.