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.

David Chappell invented the term ESB. Different people use the word ESB to denote different concepts. Chappell's book provides a clear explanation about his definition of the term ESB, which makes it a must-read for anybody involved in ESBs.

The book is clearly written, and provides a good overview of all the characteristics of an ESB, albeit strongly biased towards JMS. Not surprisingly if you look at Chappell's background. If you can get over this minor issue, this book is an excellent read.

This is a good book on ESB's but not on Service-Oriented Architecture (SOA). Although ESB's have become the foundation of most SOA deployments, this book was written before the majority of the market activity took place around SOA. Therefore it doesn't cover in much detail registries, repositories, governance, security and more current SOA issues. It does however provide a very good overview of ESB's.

It is interesting to note that the author has moved on from Sonic Software to Oracle and now is selling the virtues of SOA-enabling Grids or SOA Grids as the next best thing proving that SOA is about to move beyond the Enterprise and impact networks. I would expect to see a book in the near future by David on this topic.

Gary E. Smith
THE SOA NETWORK
www.soanetwork.net

This book, which was published in 2004, still remains as one of the best books in my personal collection of Enterprise Service Bus (ESB), SOA and related books.

The author does a good job of introducing a new computer architecture paradigm! And this is to think of software like hardware. Like hardware, have components that are plug-and-play into a standard bus. Standard interfaces, standard input/output, etc.

I found the first three chapters as extremely useful for an overall view. Then I recommend skipping to the fold out to study symbols and icons. Then, I studied chapter 9 which is about ETL (Extract, Transform, and Load) as an example that tries to help us understand the essence of ESB. I also spent time on understanding, chapters 10, 11, and 12 which give a good understanding of the Components, Integration, and Web Services. Other chapters in between, for example EAI, MOM, JMS and XML should be looked at more like the "Old paradigm". But if you are focused on ESB/SOA above chapters will give you an excellent overall architecture picture, and, a good taste of what it takes, and what different terms mean.

I also think that the author has done a good job of explaining things whith what was available then. This is an evolving and maturing technology even now.

I also tried to understand these concepts as they related to BEA WebLogic 9.2 and/or IBM WebSphere to bring more practical parallel understanding. This did help.

I wanted a book that gave me an clear understanding of what an ESB is, and this book did exactly that. While the figures were illustrative, I felt that more reading material could have been added. The two chapters that were useful were Chapters 1 and 11.

But like I said in my first sentence, it gave me an high level understanding of an ESB.

I wanted a book that gave me an clear understanding of what an ESB is, and this book did exactly that. While the figures were illustrative, I felt that more reading material could have been added. Hence the 3 stars !.

But like I said in my first sentence, it gave me an high level understanding of an ESB.

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.

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.

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.

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 is the definitive guide on ESB - excellent coverage on fundamentals, patterns and implementation models. I had read quite a few books around SOA and Web Services, some good, others not so good... but this book really stands out stressing the importance of ESB. The concepts were covered in sufficient details for any aspiring SOA developer. It all gives you a very good idea what you would need to consider when deciding to implement a real-world SOA solution in your organization.
Highly Recommended!

This is just a big broucher about ESB. It states all the benefits about the ESB but it never gets into the details of how to implement an ESB.

This book will become helpful when the author decides to add code examples of services implemented with ESB.

The good side of the book is that it is written by a seasoned veteran in async messaging that clearly understand the field and where the specs are going. He makes a good introduction to the whole paraphernalia of messaging and a good chapter about caching strategies.

This is just a big broucher about ESB. It states all the benefits about the ESB but it never gets into the details of how to implement an ESB.

This book will become helpful when the author decides to add code examples of services implemented with ESB.

The good side of the book is that it is written by a seasoned veteran in async messaging that clearly understand the field and where the specs are going. He makes a good introduction to the whole paraphernalia of messaging and a good chapter about caching strategies.

This book makes a lot of sense when you know how the SONIC ESB works. Whatever is being discussed here is a reflection of the product. So I think the product came first and then this book. However; still good reading material and intro to the goals and the architecture of ESBs.

Perhaps a better title for the book would have been ESB for the J2EE technology stack. Although the author positions the book as a technology agnostic exploration of the technolgy, his lack of understanding of the Microsoft technology stack makes it impossible for him to pull this off. His obsession with JMS shows through in every chapter and the if he made a convincing argument about why JMS compatability is so useful in an ESB in a Microsoft based platform - I failed to spot it. Also his cavalier dismissal of Biztalk ( the latest version of which incidentally does have all the features of ESB he identifies ) is also quite surprising. As an architect who is working in a non java centric ,microsoft based environment, the book comes across as primarily written for people working on the Java stack. He does pay lip service to how the ESB in his view will work with any technology but the arguments fail to impress and appear incomplete. Given the fact that the essence of SOA and ESB in my view is interoperability, his espousal of JMS,a java specific mechanism, as a key standard ESBs must implement is strange to say the least.

Having said all that, I did think the book is extremely well written and the concepts outlines nicely complement Hohpe's book on intergation patterns in my view. He should perhaps have looked a bit more at that book to see how to truly write a technology independent book.

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.

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.

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.