More responses to Steve's ESB Rant
Both David Pallmann and Curt Peterson, who work for us, have provided responses to Steve's post after my post.
David:
Disclosure: My company provides an ESB.
Human beings tend to overreact to things they don’t like. I’ve witnessed this my entire life, in every area from religion to technology.
The problem is, we tend to overreact to something we dislike and the pendulum swings too far the other way — often becoming equally inappropriate.
When people have an experience with too much infrastructure, the natural thing to do is want to avoid infrastructure. But surely having no infrastructure at all is just as bad. The two extremes are to be avoided.
I believe the debates currently raging about REST / SOA / ESB boil down to the simple question of how much infrastructure is appropriate and what shape / capabilities should it provide. I’ve blogged on this here:
http://davidpallmann.spaces.live.com/blog/cns!E95EF9DC3FDB978E!266.entry
For those who think no infrastructure is realistic in an enterprise setting, I’d be very interested to hear what your philosophy is on change management.
Curt:
Steve,
I’m happy to provide specifics, and address a number of the points in your post.
“some of the mindset behind ESB-type middleware is the desire to do everything in Java or C++.”
Really? How so? Actually, the opposite is true, ESB’s are intended to embrace the use of a large variety of technologies, and the better ESB’s do not constrain you to any specific language, transport protocol (within reasonable limits), interface type, or architectural style. A good ESB will in fact help decouple the implementation of the service interfaces from the goal of transporting messages. Thus, a developer no longer needs to consider all of the details and intricacies that we used to with Corba, COM, DCOM, etc. Sure, we no provide tools so that metadata can be imported from service endpoints, or repositories, and that’s good, who wants to deal with all the details when you have business features as your driving concern?
You continue to stress the single minded programmer concept, “Too many programmers I’ve encountered over the decades know only a single programming language,...” How does the language used have anything to do with the concepts? Aren’t you are falling into your own trap here, by stating “I’d also try to totally avoid SOAP and WS-*.” You’ve just reduced the number of tools in your toolbox considerably, as both of these technologies are extremely valuable, and powerful, if applied correctly. Why would you purposely reduce your toolset? Why don’t you just stick with one language then, how is this different? Sure languages can help support concepts (like Eiffel and Spec# do for contract based development), but seldom is the solution dependent in any way on the language. As a result of dealing with traditional application development, integration issues, Web development, and a constantly changing technical community, most developers today have much more breadth than they ever have. Most know a variety of languages, and many can effectively code services, data components, build databases, and construct UI’s. My experience with developers is very different from what you’ve stated yours to be.
Looking at the enterprise, you state that they want to, “…save themselves a lot of money and trouble if they can just get the whole enterprise to agree on a single integration architecture…”. I’m sure we’d all like to save money, but in my experience very few people actually go down this path for any significant period of time, as they realize it is futile to expect all parties to agree on anything of a singular nature. In addition, most technical and business decision makers realize their organizations are, and will continue to be heterogeneous, and therefore they must support a variety of interfaces, transports, messaging schemes, and other technological factors. All commercial ESB’s offer features to address these needs; adaptation, mediation, and transformation. You go on to mention a way that you would address this, “…grab the modules they provide that surely cover whatever protocols and formats are needed for the integration.”
Ruby and Python have integration modules for all of my LOB applications? No they don’t, and rarely have I found myself in a situation where I get to design and construct everything from a whiteboard state, let alone actually write the code instead of buying a product. Adaptation is a critical feature in any SOA, and all commercially available ESB’s today have strong support for adaptation. In addition, most have some form of extensible framework that provides for the creation of new adapters, to increase reuse at the adapter level.
Based on your closing statements you agree that legacy systems might be a place to use an ESB. It is fair to say that mainframes, mini’s, and micro’s do not have outstanding support for Web based protocols, as many are using Cobol, RPG, and are designed to connect directly to terminals. Given this scenario, how might one go about interconnecting these systems with REST, HTTP, and your choice of dynamic language? And since, I’m pretty sure it’s a safe bet to assume that heterogeneity is not going away anytime soon (in fact there is an argument for it growing), that embracing differences is critical to success, and ESB’s are designed to do exactly this.
It is widely accepted that there is significant value in developing common semantic models for business entities. A different interpretation of identical entities is a common problem, and can lead to all sorts of less than ideal decisions. REST does not cure this problem, reduce its complexity, or change the facts here. Creating reusable components requires commonality, and the process of analyzing a business process, and factoring out the common elements is difficult (for a variety of reasons, many non-technical), but these common elements are critical to ensuring any architecture is extensible and flexible, including RESTful elements. You still need common entities to make any of this work effectively, and achieve any notion of reusability, no matter what the implementation technology.
The raging debate between SOA, or ESB’s, and REST has centered largely on the specific implementation of the interfaces, specifically those interfaces that use RPC style operations. I think we’d all agree that RPC style interfaces are often less ideal than document based interfaces, but REST isn’t the only way to implement a resource centric, document based interface with endpoint transparency. Good designs are most often the result of good architectural discipline, rarely are implementations dependent on the languages, and technologies used. In fact, that’s precisely why many of these ideas have been with use so long; they endure the ever changing technical landscape because the concepts outlive the specific tools.
Contract based development has proven to work well on a number of projects that I’ve been involved in, and many of my colleagues have had similarly pleasant experiences with this process. Working with REST is a challenge in this type of an environment because everything in REST is implied; there is no explicit contract, or definition of behavior. This certainly complicates communicating to other parties exactly what is going to happen with your submission, or request, this lack of semantics often leads to errors in the use of these services, or incorrect use of the data by the consuming service. Aside from the advantages of contract first development, a strong SOA principle is to enhance flexibility, and agility so that the business processes can be as fluid as required (we all know they change constantly); addressing only resources (as REST does), and not a combination of resources, operations, and composition does not provide a complete solution. The ability to quickly create new applications or to change existing applications is made possible by many of the features inherent in today’s ESB’s http://davidpallmann.spaces.live.com/blog/cns!E95EF9DC3FDB978E!266.entry.
In general, I’m not a technology worshiper, although I’ve been in the industry for 25 years, but instead I look for the best tools, best practices, and best disciplines to get the job done. REST is most assuredly a value tool, and its use will continue to grow, and I expect that many ESB’s will soon offer strong support for REST.
