ften considered the backbone of service-oriented architectures (SOAs), the enterprise service bus (ESB) has emerged as a standard for enterprise-wide integration among disparate information systems. Many enterprise architects leverage the ESB as an essential component of their SOA-compliant architectures, where ESB serves as the cross-protocol, multi-format façade to corporate services that serve SOAP-based front ends to other enterprise information services. In that role, the ESB delivers not only a practical solution for enterprise-wide integration efforts, but also a much-needed standard for otherwise diverse integration channels.
Most of the popular ESB products are message oriented (see Sidebar 1 for an explanation of ESB architecture). They are tailored for connection-message adaptation, using specific ESB adapters for different connection types and message formats rather than for protocol- and resource-oriented services. In contrast, the wonderfully practical RESTful web services are not only very HTTP specific (i.e., relying on HTTP methods, errors, state transfers to URLs), but they are almost exclusively resource centric (every entity exposed as a web service has a unique URI). For that reason, the RESTful style represents a challenge for message-oriented ESBs.
ESB is mostly intended as an enterprise wide infrastructural pipeline that exchanges messages among statically defined end points (FTP directories, message queues, web services, HTTP URLs, database connections, etc.). Network protocols serve simply as the most rudimentary pipelines for network exchange. Integration with RESTful web services requires not only strong familiarity with the REST protocol, but also with the integration features offered by common ESB products.
This article presents key strategies for enabling interoperability between RESTful web services applications and ESB-connected applications. It reviews three integration tools that will enable you to reliably incorporate RESTful web services into ESB-backed integration solutions.
Specialized REST Adapter
Popular open source ESB products, such as Mule, provide REST adapters as part of their product offerings. Mule offers a REST wrapper that is very simple to set up and configure. Configuration steps include setting up all the common parameters that characterize the RESTful web service, such as URL, HTTP method type, query parameters, HTTP error handler, etc.
The following is an example of Mule’s configuration file for the RESTful adapter, which invokes the RESTful web service presented in my previous DevX article “RESTful Web Services: The Keep-It-Simple Style“:
singleton="false" initialState="started"> All other parameters such as payloadParameterName are optional, but the urlFromMessage parameter is of particular interest when integrating ESB Mule with canonical web services.With this parameter set, Mule ESB will look into a message for the value of the rest.service.url parameter, which represents the URL of the RESTful web service to be invoked.
This option enables Mule to access RESTful URLs that universally represent entities (e.g., shipment ID is part of the URL), which is in accordance with the best practices for RESTful web services.
HTTP/S Adapter
Most ESB products provide HTTP/S adapters out of the box. They are most commonly used as a solution for dynamically and programmatically inserting data into online resources such as forms on web pages. As RESTful web services are not only amenable to the HTTP protocol but in execution pattern almost identical to how web users interact with web forms, HTTP/S adapters are often (in absence of a specialized REST adapter) the best alternative for access to RESTful web services.
The issue with HTTP/S adapters is that they are intended for use with static URLs. Yet RESTful URLs reflect entities being accessed and a URL can be different every time the resource (RESTful entity) is accessed. For that reason, the HTTP/S adapter is appropriate for RESTful services that represent entities such as lists or services where the URL does not change and input to the RESTful service is via configurable parameters.
HTTP/S adapters are also appropriate for RESTful web services that are not written according to the entity pattern (which they often aren’t). In that case, an HTTP/S adapter is used to access the static URL of the RESTful web service, and all the information needed by the service is passed on in an HTTP query string. This is the simplest form of a RESTful web service, and the HTTP/S adapter serves this purpose well.
Beyond that, the only further consideration when working with an HTTP/S adapter is selecting the appropriate transformer/mapping component. Most RESTful web services (Hi-REST or Lo-REST) are designed to produce output structured as XML, not plain text or HTML. As XML is the standard format for data representation on ESBs, any ESB used for interaction with RESTful web services should support XML transformation to Java objects or some other convenient data representation format.
Custom ESB Adapter
Most ESB products support and even supply toolkits for developing custom ESB adapters. If the product you use does not supply a RESTful-specific adapter or if the HTTP/S adapter supplied is not flexible enough to support adaptation of RESTful services, developing a custom adapter may be the simplest solution. As RESTful web services are very simple and fully HTTP compliant, most of the time adapter development for any ESB product will involve only implementing the logic that adds the entity as a resource to the URL being accessed. Everything else will mimic what the HTTP adapter already does:
- Access the URL using one of the standard HTTP methods (GET, POST)
- Eventually add support for other HTTP methods such as PUT and DELETE
- Handle HTTP errors
For most ESB products, be they open source or commercial, one of the most viable alternatives for implementing a custom ESB adapter is to implement a Java Connector Architecture (JCA)-compliant adapter. The core function of this adapter will be executing the logic for translating requests coming off the ESB into RESTFul web services-compliant requests.
When Architectures Collide
Many enterprise architects see ESB as an indispensable tool for integrating disparate systems and bringing backend services into service-enabled architectures. Many of these architects also express discomfort with RESTful web services because they do not see as much vendor support for them as there is for legacy resources or SOAP-based web services. Meanwhile, many hands-on architects and developers consider RESTful web services the most straightforward and natural solution for service-oriented interactions, and they often integrate their front-end applications or integration solutions directly with RESTful backend services without using the ESB. This article presented architectural options for what happens when these two worlds?monolithic enterprise architectures and lightweight integration architectures?collide.
As the ESB product market is very diverse and very competitive, no one solution or set of solutions provides a best practice for integrating ESB with RESTful web services. My professional concern is that without defined guidelines enterprise architects may discard RESTful web services as too exotic for enterprise integration. In fact, RESTful web services are too practical and too simple to be ignored due to their lack of mainstream support. I hope this article will inspire technologists to incorporate this valuable technology into their ESB-backed enterprise integrations and fully leverage its potential.
