Customer Reviews

Enterprise Service Bus: Theory in Practice

5 star:		(7)
4 star:		(6)
3 star:		(4)
2 star:		(2)
1 star:		(0)

 

 

Chappell describes a highly promising but still speculative technology for connecting together enterprise-wide computations. It can also potentially be used to span different companies. Some of you may groan. Haven't we heard this already, several times? Remember the toutings of CORBA, Java's RMI, JMX, JMS, and the nascent Web Services?

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.

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.

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.

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.

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.

I found this book to provide a good introduction in the first chapter, but it was extremely wordy in describing SOA and ESB principles. The definitions were polluted with buzzwords and sales jargon to the point of being painful. It's "marketecture."

A book that provides a concise and clear definition of SOA principles is "Enterprise SOA: Service-Oriented Architecture Best Practices" by Dirk Krafzig, Karl Banke, Dirk Slama. While better than Enterprise Service Bus, this book also does not entirely meet the needs of a computer professional embarking on a large Enterprise software project.

I still have not found a book that provides the necessary guidance with regard to architectural principles, architectural styles, communicating an architecture effectively and evaluating/analyzing existing architectures.

David Chappell's book on Enterprise Service Bus describes application integration technology using emerging open standards, event driven messaging and loosely coupled component architecture. The applications that dot any enterprise IT landscape are diverse and hence integrating them to cohesive, collaborating services is by no means simple. In its initial few chapters, Mr.Chappell does a brilliant job in describing typical enterprise IT systems, their current state of cohesiveness (or rather lack of it), importance of integration for business purpose and makes the case for a consistent pattern such as Enterprise Service Bus that can bring diverse IT systems together. He introduces the term "accidental architecture" to describe the ad-hoc, point-to-point integration between systems that had become many maintenance manager's nightmare and helped many to keep their jobs.

The very nature of application integration technology involves a host of technologies such as Message Oriented Middleware, XML processing such as JAXB, XPath or XSLT, protocols such as RMI, SOAP, HTTP. After the initial chapters the book transits to ESB in a rather abrupt manner without spending enough time to elaborate the core capabilities of the underlying technologies involved. The experienced readers may not find this limiting but a more systematic exposition to key technologies for ESB would have been helpful for many readers.

In the same vein, the author misses a substantial discourse on how the ESB container works. The description mainly focuses on "what" the container does rather than "how". For example, how the ESB container maintains transactional integrity across loosely coupled systems, how it copes up with erroneous messages or faulty services or how a repository of metadata can be useful to handle message versioning could have been described in a more in-depth manner.

The book provided numerous descriptions of complex integration scenarios. These examples elaborate the capabilities and scope of ESB approach and its benefit against "accidental architecture". However, focussing more on what this complex integration achieved rather than how ESB carried such tasks, and how were the key challenges solved, these descriptions often read like "mother-and-apple-pie" stories. They are all good, but aren't there any pain?

Besides its main limitation of lack of detailed mechanics, the book covers the breadth of the topics covering JMS, Web Services, new JBI standards, Portal Server, Application Server, Synchronous and asynchronous communication protocols, declarative rule based routing. All these concepts are important in ESB context and the author has tried to bring them together.

I hope experienced reader will be able to find a common thread between these concepts but am not so sure about those who are relatively new in the domain of system integration.

Bit old but was the first one to explain ESB's in simple ways
I loved the patterns and the implementation sections

I was looking for a book that would give me a basic understanding of what an ESB is. This book exceeded my expectations by describing high-level fundamentals, patterns and implementation models. It does a good job discussing service re-usability and examining some core ESB services such as content based routing and XSLT transformations. The book is very high level and doesn't go too much into implementation details!

This book provides a great review of web services, not only discussing where web services are at but how they got there. At just over 200 pages the book covers a lot of ground, but in a very concise and informative manner. The book is technology neutral (no code listings) and provides a great top-down view of this new paradigm for software development. If you have been around web services for a while-this book probably doesn't have a lot for you. However, if you are new to web services and looking for a quick and thorough what's what I highly recommend it.