Entry tags:

design patterns, integration, messaging

integration patterns
One of the books that I was reading recently, was Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf. The book published as a volume of the "Martin Fowler Signature Books" series, and this was promising. I have a great respect to Martin, and always enjoyed his books and articles.

However, my expectations were probably too high. Well, the book was OK, but not more than that. It is a very valuable resource of messaging patterns, and some of the patterns are described splendidly (specially, chapters written by Martin who was invited to do that). On the other hand, I was hit by some sloppiness right from the introduction. Here is a few examples:

• "The message itself is simply some sort of a data structure - such as a string, a byte array, a record, or an object." "some sort of a data structure" is just not correct.
  
• Describing shared databases the authors say: "multiple applications share the same database schema". This is not correct again. In that pattern, applications share data.
  
• A picture on page xxxii presenting a message transmission process suggests that the messaging channel starts (and ends) on the same computers where the applications are located. This may be or may not be true, depends on the implementation.
  

Unfortunately, these small issues were making my reading efforts more painful than I wanted.

However, in general, the book is OK. It provides a list of 65 different patterns creating at least a good starting point for discussion.

There are several thoughts that came up to my mind when I was reading the first part of the book.

1. Terms in this area definitely need clarification. We often use data integration vs. application integration and even message integration. It seems to me that any integration is application integration. Some of integration patterns assume just moving data, others assume moving data and invoking applications. But essentially we always integrate applications. Message integration is really a method (methodology) of integration.

I would agree that using data integration vs. application integration might be reasonable, if the difference between them is clearly defined. In fact, I think that all of above mentioned terms can be used if clearly defined. For example:
- Simple Data Integration: file transfer, data sharing, replication (see below).
- Messaging [Data] Integration
- Application Integration: remote procedure invocation, others (?)

2. The authors of the book consider four integration styles (patterns): File Transfer, Shared Database, Remote Procedure Invocation, Messaging. Well, the list is not just incomplete, it is somewhat inconsistent. I can probably say, that File Transfer may be considered as Messaging, for example. Files (having a header and a body) are true messages, and file systems play roles of message brokers, delivering files according to the information in the header.

3. Why Remote Procedure Invocation should be always synchronous? I believe that this pretty much depends on the implementation.

4. Thinking about "data integration" before, in addition to the File Transfer and Shared Data patterns I always considered a Replication pattern. It could also be called Data Synchronization pattern, and it was commonly used in first distributed systems specially over unstable connections.

Has anyone seen a description of Replication/Data Synchronization pattern?

Well, when it comes to the terminology, I usually have more questions than answers.

DesignPatterns