Enteprise Integration Patterns book

As I am taking transit to get to work now, I got some time to read in the bus and on the skytrain. I decided to read the book by Gregor Hohpe and Bobby Woolf ("Enterprise Integration Patterns") that I started to read a while ago. My first impression about that book was not very good: http://andreiko.livejournal.com/2826.html.

Why am I doing the second attempt? Well, first of all, there are just a few books on that topic. Secondly, I am doing an interesting work now, related to the integration patterns. And I wanted to do my research as thoroughly as possible. And the last push I got from my conversation with Jame Healy a few months ago. I tried to explain Jame why I did not like the book, and he answered: "Oh, I consider it just a catalogue of patterns". He had a point. So, I started my second attempt trying to consider it just a catalogue of patterns.

One thing which I have discovered (actually quite some time ago) that the catalogue is incomplete. Big deal? Surely not. However, it was missing some important patterns which were quite obvious. I have difficult time imagining how one can forget about replication/synchronization patterns discussing data integration. Well, the Microsoft "Integration Patterns" (significantly based on the Hohpe's book) covered the issue.

However, let's pick a pattern from the book. And believe me, I'm not picky :), I just looked into one of the first patterns in the book, "Message Channel". Don't forget, I'm trying to read the book as a catalogue, so I'm trying to understand what this particular pattern is.

Well, what do we see?

The authors introduce the Message Channel pattern saying that applications don't just randomly throw out information into messaging systems. A sender adds information to a particular Message Channel, a receiver retrieves information from a particular Message Channel.

What do I learn about the Message Channel pattern from it? First of all, Message Channels is something what applications could add information to. Is it some type of storage? "Adding" information is different from sending/throwing/passing/etc. it. "Adding" assumes storage. I doubt that this was what author meant. If he really did, I have concerns.

Secondly, I see that the sender's Message Channel is different from the receiver's Message Channel. I had no problem with that, if the picture in the book did not show one channel between a sender and a receiver. A few pages after the authors say: "A Message Channel can often be though as a pipe, a conduit from one application to another". So, my question is: "Does the receiver share the channel with the sender?" There is no answer in the book.

Let's keep reading. Two paragraphs later we see "Channels are logical addresses in the messaging system." WHAT? I have an urgent temptation to close the book. This is not just negligence, this is ignorance. First of all, CHANNELS ARE NOT ADDRESSES. Second of all, I cannot even imagine an address being a data storage, or a pipe.

Just last example. Actually, that was enough for me already. But for those of you, who are masochistic in nature -- one last quote. "There are two different kinds of message channels: Point-to-Point Channels and Publish-Subscribe Channels". This sounds rubbish to me, but I'm not arguing it. I am just surprised (am I?) that the next sentence is "Mixing different data types on the same channel can cause a lot of confusion; to avoid this use separate Datatype Channels". What is Datatype Channels? A new type in addition to the other two? Or is it a new classification, say, a new category? The author does not explain.

Supposedly, when I read about the Datatype Channel pattern, I will understand it better. Somehow, I doubt it.

No, this is not a good book. THIS IS A BAD BOOK. You can not use it even as a catalogue.

Dixi et animam levavi.