Patterns for REST services with WebSphere DataPower SOA Appliances

This article describes service patterns using WebSphere® DataPower SOA Appliances for REST-style software systems. These patterns will help speed the adoption of DataPower Appliances and help architects build more flexible software systems, as well as improve the security and scalability of REST-style software services.

Share:

Daniel Colonnese (codaniel@us.ibm.com), WebSphere Technical Specialist, IBM

Daniel Colonnese is a WebSphere specialist who focuses on helping insurance and financial services clients design and build service-based applications.



Alex Klevitsky (aklevitsky@mib.com), Director of Architecture and Enterprise Software, MIB, Inc.

Alex Klevitsky is the Director of Architecture and Enterprise Software at MIB, Inc. He has over twenty years experience in design, development and implementation of business and engineering applications, as well as software tools



08 August 2007

Introduction

This article describes the role that WebSphere DataPower SOA Appliances can play as an infrastructure component in implementing SOA solutions based on the Representational State Transfer (REST) architecture. The vision presented in this article complements IBM's family of ESB solutions, which includes WebSphere ESB, WebSphere Message Broker and WebSphere DataPower Integration Appliance XI50. Although simplicity is the key feature of the proposed solution, we'd like to stress that business needs, rather than technology preferences, drive architectural decisions.

SOA Patterns and REST

The IBM SOA Center of Excellence defines SOA as a "flexible architecture of business capabilities being supported by loosely coupled IT elements" SOA is seen as a set of architecture guiding principles, rather than a reference architecture. Many definitions of SOA attempt to formulate guiding principles for this new architecture. These individual principles are not new, but are now exposed as one cohesive unit. These guiding principles provide the foundation for the SOA reference model.

The Exposed Router variation of the Exposed Broker application pattern (see Patterns: SOA with an Enterprise Service Bus) provides the foundation for the SOA environment. According to Len Bass, in Software Architecture in Practice, a software system reflects not only requirements (both in terms of functionality and system qualities), but also the background and knowledge of the architects. Architects select the most common and familiar style that satisfies system requirements. The dominant style in large software systems for the past 30 years has been call-and-return architectures. The client-server is the most popular among them, where programs are components and calls, or remote procedure calls (RPC), are connectors. As described in Pattern-Oriented Software Architecture, Volume 1, A System of Patterns, the client-dispatcher-server style "introduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers." The client-dispatcher-server pattern describes a direct variant of the Broker pattern, indicating that servers and clients use and understand the same protocol. This article describes how to expose a DataPower appliance as a dispatcher variant.

The benefits of SOA can be realized by heterogeneous architectural styles, which are created by SOA architectural patterns and REST (see Architectural Styles and the Design of Network-based Software Architecture, by Roy Fielding). REST is the predominant architectural style of distributed hypermedia systems, including the modern Web. WebSphere DataPower SOA Appliances expedite the implementation of software systems based on this style. The major driving factor in the rising interest in REST is attributed to the success of the Web – the largest software system ever created. Roy Fielding's seminal dissertation illustrates REST data elements, components, connectors, and presents the process view shown in Figure 1 to show the interaction between components:

Figure 1. Process view, courtesy Roy Fielding PhD Dissertation, 2000
Figure 1. Process view, courtesy Roy Fielding PhD Dissertation, 2000

In his description of this process view, Fielding points out that "REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems" (highlights in this quote are ours). He adds, "layered system constraints allow intermediaries – proxies, gateways and firewalls – to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching". In particular, "a gateway (a.k.a., reverse proxy) component is an intermediary imposed by the network or origin server to provide an interface encapsulation of other services, for data translation, security enforcement and acceleration. Note that the difference between a proxy and a gateway is that a client determines when it will use a proxy". A DataPower SOA appliance provides a Multi-Protocol Gateway (MPGW) application component, which provides an inexpensive and loosely-coupled REST gateway component implementation. It also represents variants of the "server-side proxies" – the participating components of the Exposed Broker pattern.

The recent popularity of SOA and REST nicely complements the use of DataPower appliances in a Dispatcher or Gateway pattern. While DataPower does not support representation caching, which is an important constraint of the REST style, the appliance implements limited caching, such as caching of XSL stylesheets that are used for data transformations. Usually coarse-grained services justify representation caching. This approach may not be beneficial when information is highly dynamic, as the expiration of the cache may introduce overhead that defeats a cache's intended purpose..

DataPower gateway design patterns

This article is not concerned with specific implementation details; rather it is a position paper dealing with design alternatives. In the recently published book RESTful Web Services, the authors address the design and implementation of Web services based on the REST architectural style, taking into account functional requirements (including security enforcement, protocol translation, data transformation and routing), as well as non-functional requirements (including performance and consumability).

The introduction of WebSphere DataPower Appliances as a gateway offers flexibility in design choices that might otherwise require complex coding logic in a software-only design. We propose three hierarchical variants of the gateway pattern based on the capabilities of the appliance: Secure Gateway, Secure-Accelerator Gateway and Secure-Decorator Gateway, as shown in Figure 2. Each lower-level pattern helps to complete higher-level patterns.

Figure 2. DataPower appliance as REST-Service Gateway
Figure 2. DataPower appliance as REST-Service Gateway

The Secure Gateway pattern uses DataPower to provide security services and protocol mediation. The DataPower MPGW uses DataPower security capabilities, such as AAA, CRL verification, traffic shaping, and XML threat protection. DataPower's integration capabilities include support for various messaging protocols (such as MQ, JMS) and FTP transports in addition to front-side HTTPs. Multi-transport support does not violate REST, according to the REST process view. The stateless nature of REST requires that a Secure Gateway assume that all client-side traffic is suspect and all back-end messages are authorized and valid.

The Secure-Accelerator Gateway completed by the Secure Gateway pattern adds data transformations and validation of XML messages. DataPower XML acceleration capabilities substantially increase the performance of XML processing and provide highly efficient solutions for transforming programmable representations (such as XML) accepted from the client to the common internal XML message format (or business-local XML vocabulary). We recommend including XML Schema compliance verification, which is more expensive to perform using other infrastructure components. We have found ISO Schematron useful in implementing constraints and complex business rules validations in addition to basic XSD schema validation. With REST-AJAX Web applications, you can use DataPower to perform client-side validations via ISO Schematron or XPATH, which can further reduce latency while decreasing load on the application server. You can use the content-based routing capabilities of the appliance to support versioning of the common internal XML message format.

The Secure-Decorator Gateway is completed by the Secure-Accelerator Gateway pattern, which adds representation construction for human-readable (such as XHTML) and programmable (such as XML) interfaces from the common internal XML message format. This pattern is a variant of a Proxy-Decorator pattern that was envisioned by the authors of Design Patterns: Elements of Reusable Object-Oriented Software as a combination of the well-known Proxy and Decorator patterns.

Web 2.0 and beyond

Consumability, or connectedness, is an important focus of Web 2.0 mashups. Many architects stress that REST services offer this consumability quality. DataPower WS-Proxy and MPGW application components provide features to amplify this quality even further by providing alternative support for non-REST Web services. You can extend these patterns to add SOAP wrapper, WSDL, and Web services capabilities to existing REST services.

You can also build other heterogeneous architectural styles on REST and selected SOA architectural patterns. For more information, refer to Patterns: SOA with an Enterprise Service Bus.

Conclusion

This article describes some high-level pattern-based architecture for service design. Remember that to succeed in applying these patterns, your software system must build on common-sense and proven practices in computer science. We hope you can apply these software patterns to better organize the next generation of service-oriented software.

In conclusion, we'd like to recommend that pattern-based architectural styles and software design patterns be used in the way Christopher Alexander, the father of the Pattern Architecture Language, advocated pattern usage in the field of civil architecture – to build better systems rather than simply solve recurring problems in a given context.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services
ArticleID=244803
ArticleTitle=Patterns for REST services with WebSphere DataPower SOA Appliances
publish-date=08082007