Enterprise Integration Pattern by Gregor Hope and Bobby Woolf
What are Enterprise Integration Patterns?
Enterprise integration is a complex field, and there is no simple 'cookbook' answer. That's why patterns are a useful way to convey experience that usually only lives in architects' heads. Patterns are accepted solutions to recurring problems within a given context. They are abstract enough to apply to most integration technologies, but specific enough to provide hands-on guidance to designers and architects. Patterns also provide a vocabulary for developers to efficiently describe their solution.
Who can use Enterprise Integration Patterns?
Most of the patterns assume a basic familiarity with messaging architectures. However, the patterns are not tied to a specific implementation. So if you use EAI suites such as IBM Web Sphere MQ, TIBCO, Vitria, See Beyond, Web Methods etc., messaging specifications such as JMS, or Web service standards like SOAP, these patterns help you design better integration solutions. In some cases, a pattern may already be embedded in the middleware package. This is a sign that the vendor recognized the recurring problem and incorporated the solution into the package. We still present these patterns for two reasons. First, not all packages implement the same patterns, so a user working with another package will still find the pattern useful. Second, despite the default implementation of the pattern in the middleware package, a description of the forces and alternatives is insightful for any architect or developer who is interested in EAI concepts beyond the specific package implementation.
The Patterns
We have identified 65 patterns so far. Which is organized the patterns into the following categories:
Integration Styles document different ways applications can be integrated. These patterns present somewhat of a historical account of integration technologies.
Channel Patterns describe the fundamental attributes of a messaging system. These patterns are implemented by most commercial messaging systems. This section focuses on the interrelationships between different features and highlights implementation trade-off made by different vendors.
Message Construction Patterns describe the intent, form and content of the messages that travel across the messaging system. Routing Patterns discuss mechanisms to direct messages from a sender to the correct receiver. Message routing patterns consume messages from one channel and republish the message to another channel that is determined by a varying set of conditions. The message content is not modified.
Transformation Patterns change the information content of a message. In many cases, a message format needs to be changed due to different data formats used by the sending and the receiving system. Data may have to be added, taken away or existing data may have to be rearranged.
Endpoint Patterns describe the behavior of messaging system clients. They illustrate different ways in which applications can produce or consume messages.
System Management Patterns provide the tools to keep a complex message-based system running. A message-based integration solution can process thousands or even millions of messages in a day. Messages are generated, routed, transformed and consumed. The solution has to deal with error conditions, performance bottlenecks and changes in the participating systems. Message management patterns address these requirements.
Subscribe to:
Post Comments (Atom)
2 comments:
Hi thanks for the FAQs. They were helpful though some where still too technically answered. Anyway will catch up with you in class and explain a few issues I had difficulty with, if you do not minds.
Cheers
hi there, ii did like the discuss you pick to discuss enterprise intergrated pattern its a nice one, that show how hard working you are since you have started this course, doing some research my yah self its kool, but make sure that you are more specific.
Post a Comment