Large IT organizations increasingly face the challenge of integrating various web services, applications, and other technologies into a single network. The solution to finding a meaningful large-scale architecture that is capable of spanning a global enterprise appears to have been met in ESB, or Enterprise Service Bus. Rather than conform to the hub-and-spoke architecture of traditional enterprise application integration products, ESB provides a highly distributed approach to integration, with unique capabilities that allow individual departments or business units to build out their integration projects in incremental, digestible chunks, maintaining their own local control and autonomy, while still being able to connect together each integration project into a larger, more global integration fabric, or grid.

Enterprise Service Bus offers a thorough introduction and overview for systems architects, system integrators, technical project leads, and CTO/CIO level managers who need to understand, assess, and evaluate this new approach. Written by Dave Chappell, one of the best known and authoritative voices in the field of enterprise middleware and standards-based integration, the book drills down into the technical details of the major components of ESB, showing how it can utilize an event-driven SOA to bring a variety of enterprise applications and services built on J2EE, .NET, C/C++, and other legacy environments into the reach of the everyday IT professional.

With Enterprise Service Bus, readers become well versed in the problems faced by IT organizations today, gaining an understanding of how current technology deficiencies impact business issues. Through the study of real-world use cases and integration patterns drawn from several industries using ESB--including Telcos, financial services, retail, B2B exchanges, energy, manufacturing, and more--the book clearly and coherently outlines the benefits of moving toward this integration strategy. The book also compares ESB to other integration architectures, contrasting their inherent strengths and limitations.

If you are charged with understanding, assessing, or implementing an integration architecture, Enterprise Service Bus will provide the straightforward information you need to draw your conclusions about this important disruptive technology.

ISBN13: 9780596006754

Condition: New

Notes: BRAND NEW FROM PUBLISHER! 100% Satisfaction Guarantee. Tracking provided on most orders. Buy with Confidence! Millions of books sold!

Average Customer Review: ( 19 customer reviews )
Write an online review and share your thoughts with other customers.

Well, ESB draws upon often bitter lessons learnt with these earlier endeavours. CORBA was widely found to be too complex. RMI works only for tightly coupled systems, which do not scale well. So that became one reason for JMS, because it enabled loose coupling. But JMS is too low level. Web Services may indeed be promising, but face a danger of overspecifying a standard before enough practical experience is garnered.

ESB tries to subsume the best ideas from the above, and from other efforts. It promises loose coupling and an incremental rollout, amongst other things. The incremental ability may be key to getting a small scale project approved and implemented, due to its minimal investment.

You could think of ESB as taking the ideas of the JMX management console a step further. Plus, ESB can use JMX as a subsidiary technology.

Chappell also offers nice visual component schematics that could be used to represent and perhaps even assemble an ESB network. If this indeed is possible, it would be tremendous. Akin to the 1980s, when MicroSim offered a graphical version of Spice, with electronic parts availabled from a menu.

31 of 35 found the following review helpful:

All sales, no sizzleOct 01, 2005
By R. Pearlman
I was hoping that this book would go through the history of technology leading up to the ESB, discuss how the ESB solves the problems presented by previous solutions and talk about some best practices for building ESBs.

Unfortunately, the whole book goes right into the sale pitch telling you that ESB is the solution to problems that we previously were unable to solve! And, ESB appears to have no downsides! And, there are some great vendors out there that can solve all your problems!

EAI didn't work for you? That's because Hub-And-Spoke doesn't scale. But, the author doesn't spend any time on what people did to address these problems. How about distributed components? Of course, they didn't work... no exactly sure why, but ESB solves the problem!

The redeming part about this book is that it does provide a good overview of what an ESB is. It also provides you with a lot of terminology that may be new to you.

However, I wouldn't buy this book again or recommend it to anyone. Instead, I would recommend a lot of other good books on SOA that tell you about how we got here and how the technology pieces are around to help support new solutions to previously hard problems.

22 of 24 found the following review helpful:

A must-read for integration architectsAug 04, 2004
By Ronald A. Ten Hove
This book should be required reading for anyone involved with EAI, especially integration architects.

For those of you who may not have heard about ESB, it is a rather new approach to structuring a SOA (service-oriented architecture), using a distributed MOM infrastructure, XML messages, intelligent message routing, automatic transformation of messages, and centralized administration. The SOA approach to EAI solutions is compelling, but it is still too early in the game to tell if ESB will take the world by storm. It has a lot of promise, and many EAI vendors are jumping onto the bandwagon that Sonic, including Dave Chappell, helped to build.

The book offers the first comprehensive definition of an ESB that I have seen, almost entirely stripped bare of vendor-specific information and sales info. I say almost, for some issues (such as app-servers vs. ESB service containers) are presented in a less vendor neutral fashion than I would like. Overall, the book stays high on useful content, and low on vendor product positioning.

The books combines nicely described technical descriptions of ESB features with some high-level case studies culled from Dave's experiences in industry, or based on interviews with IT leaders that he conducted while researching the book.

The technical descriptions avoid becoming too detailed, but are sufficient to capture the essential issues encountered in integration. The book's diagrams, resembling Gregor-grams, are very useful, although I was a bit mystified to find a reference card for the glyphs used, tucked away in the back of the book. The diagrams are self-explanatory, IMHO.

The case studies are similarly abstract, avoiding introducing a level of detail that would cause the forest to be lost amongst the trees. At times I wished to a little more detail here, but I suspect I'm something of a glutton for punishment that way.

ESB is threatening to become something of a buzz word these days, what with IBM weighing into the ESB market. This book should help secure a rational, useful definition of Enterprise Service Bus before the marketing machines of the various integration vendors obliterate it in a storm of white papers and glossy brochures.

16 of 17 found the following review helpful:

Ultimate ESB bookOct 03, 2005
By Paul Lopez "Paul"
Frankly, I feel that some reviewers misunderstand the purpose of this book. In my opinion, for a SOA focussed professional who needs to know the role of SOA, this book is a gem! Any of us who have had the challenge of explaining messaging technology should be grateful about reading this book.

As technologists, we forget just how much intimidating jargon we use and how many underlying assumptions we make when we explain things. As a software architect once said to me, "if I had more time, I'd make it simple." Clearly Mr.Chappell has taken on the challenge of making it simple and made it in such a way even an idiot can understand, and such efforts are incredibly valuable.

6 of 6 found the following review helpful:

Some interesting insights, but a bit too high-level for meFeb 12, 2007
By Krot
The book provides some interesting insights into emerging technologies, but overall is too high-level and, in the end, pretty vague on the ESB (Enterprise Service Bus) architecture. The basic idea is that you should use asynchronous messaging in XML and leave all routing/aggregation/security/transformations to a special integration layer called ESB, like a product produced by author's company. This would give you more integration by configuration rather than coding, the argument goes. Author described how a lot of recent XML standards are going toward or adding async model. All in all, ESB seems to be pretty much Message Oriented Middleware (MOM), but with (somewhat inconsistent) emphasis on open on-the-wire protocol. I wish this was distilled in a sentence upfront.

So far so good. But what on-the-wire messaging protocol should we use? It appears the author is saying anything and all goes - just maybe add XML. This is where it starts being vague as if for fear to upset anybody. So, is ESB basically about just putting any XML on the wire? Not all XML is the same (just as binary content was not), and author in fact points out competing standards on XML messaging. There are a lot of decisions on top of "let's just use XML" on which the author leaves you to your own devices. He just covers all upcoming XML standards from A..Z in a few sentences each. It is the sort of "XML will save the world regardless of how it is used" approach that worries me.

At the same time, a lot of space is dedicated to JMS. The author tentatively explains that JMS is not really suitable for ESB because it does not provide an open on-the-wire protocol - only standard APIs. I am glad he covered this because this is a wide misconception. But then why JMS presented as one of nice re-usable building blocks for ESB? I think he is saying because it provides comprehensive framework for messaging. Ok. But proprietary on-the-wire format means it is not really suitable for ESB unless you find a product that uses XML transport under JMS API. The author does not explain this nor discuss how standard is that JMS-API-to-wire bridge today, so the whole JMS tie-in with ESB's supposedly open architecture was not clear to me.

As a practitioner, I also wish there were a bit more insights into how redundancy and errors are to be handled in this architecture. Also, how transactional semantics are handled end-to-end in such environment. The examples with reliable messaging are too simplistic and abstract to cover the real challenges involved. All of this may hide the extra complexity and overhead actually pushed on application with asynchronous and highly loosely coupled ESB design. Maybe the trade-offs would still favor it, but a bit more points of analysis would help to enlighten the reader.

It is interesting that the author takes on application servers and argues that they are not good for ESB infrastructure (unlike for source applications themselves). I appreciate that the author is not afraid to go against the grain if it makes for a good technical choice (same could be applied to JMS), but I wish the arguments were a bit clearer and specific. For example, the author claims that app server is not suitable for loosely coupled component deployment. I wish he explained why because obviously JEE proponents may be curious.

In the end, this book is more of an overview of Sonic ESB product deployment architecture, rather than necessarily an IT architecture. Be aware of that, but do read the book for yet another perspective. I found the book pretty easy to read - only took me an hour.

See all 19 customer reviews on Amazon.com