Some thoughts on ESB vs. REST + Dynamic Languages
I spent some time this weekend thinking on Steve Vinoski comments regarding the REST+Dynamic Languages vs. ESB debate. As much as I've admired Steve over the last years I cannot agree with him on this one. I bought into the REST philosophy a long time ago and I am a big fan of dynamic languages but I think that presenting both as an alternative to ESBs on EAI-BPM scenarios is oversimplifying one of the most interesting challenges on the industry nowadays. In my opinion all this come down to applying the right technology to a specific scenario. I spend a lot of time working with customers on SOA/BPM scenarios and I've seen some very creative solutions both using ESBs as well as using REST and Dynamic languages. One of the main challenges with the ESB adoption, especially for J2EE-J2SE customers, is the high number of vendors (23 last time I counted) that provide very similar solutions in terms of features. I also think that with the increasing adoption of Service Component Architecture (SCA) we are about to see a similar phenomena for service composition and deployment technologies. In .NET environments the best option are a combination of BizTalk Server and the ESB Guidance Toolkit or the very creative Neuron ESB from my friends of Neudesic.
From my perspective, I always try to apply REST to model resource-oriented and/or state-machine services. My friend Tim Ewald wrote a phenomenal reflection on this topic. Dynamic languages on the other hand, are a great fit for creating live-models that represent interactions between services. Combining these two technologies together we can certainly provide some very effective solutions for some integration scenarios for which the use of an ESB would introduce unnecessary complexities. Given said that, there are A LOT of scenarios on which applying an ESB either as a product or as an architecture style is the right solution and REST and Dynamic languages are just NOT ENOUGH. Addressing those scenarios using only REST and Dynamic Languages most likely would introduce the typical problems that occur when we try to solve intrinsically complex problems with simple and limited technologies.
As always, an example might helpJ. I've listed some of the capabilities that I think traditional ESBs technologies offer and that are very difficult to equate using REST and/or Dynamic Languages.
- Long running processes: Some Business Processes in the enterprise are naturally long-running. Modeling those processes often entails the use of persistent-stores, message correlation mechanisms and other capabilities that are traditionally part of ESB products. Building these functionalities with REST and Dynamic Languages requires lots of custom coding.
- Scalability: When comes to BPM, the notion of scalability entails more than what you can achieve with infrastructure technologies such as Web Servers or Database servers. Some ESBs (at least the decent ones) provide some complex algorithms for controlling the important aspect such as resource throttling, message throughput, messaging routing among other key components of a scalable solution.
- WS-* protocols: Some WS-* protocols have matured enough and present a wide adoption in the industry. Arguably, the top list is composed by WS-Security, WS-ReliableMessaging, WS-Policy, MTOM and WS-MetadataExchange with honorable mentions to WS-Trust and WS-SecureConversation. A lot of the existing ESBs are built on Web Services frameworks that provide implementations of the most common WS-* protocols. On the other hand, the support for those protocols in Dynamic Languages is almost non-existent with the exception of my friends of WSO2 who have been doing some fantastic things implementing WAS for PHP, Python and Ruby.
- Description: As much as I love REST we have to admit that one of the main challenges to its adoption is the fact that there is no widely adopted service description language that presents and alternative to WSDL. WADL seems to be a decent solution but its adoption in the enterprise has been very limited and still remains to be seen how REST-based technologies can overcome some of the challenges that SOAP-based technologies faced with the use of WSDL. It's undeniable that having mechanisms to express service contracts and policies becomes essential in some ESBs scenarios.
- Adapters: Although you can always argue that you can use REST interfaces to communicate with Line of Business (LOB) systems; the fact of the matter is that the interaction with LOB systems requires lots of infrastructure logic on the client side for handling things like configuration, retransmissions and failures, connection management, etc. The majority of the ESBs in the market use or implement adapter frameworks that handle all those important features.
- Modeling: The use of models is one of the keys to the success of a SOA implementation. Traditionally, ESBs rely on declarative languages such as WSBPEL, XLANG or WSCL to model the different interactions or compositions between services. Using Dynamic languages to express models is a very attractive idea but it requires the ability to model Integration Domain Specific capabilities which are not represented by default in languages such as Ruby or Python.
- Monitoring: Monitoring integration solutions entails much more than just monitoring the message flow between endpoints. Some of the existing ESBs on the market provide rich monitoring technologies that help to address this challenge. In the case of a solution based on REST and Dynamic languages, this capability is often limited to the use of monitoring software on the services endpoints.