What is EI Pattern?
We have identified over 60 patterns so far. The Table of Contents lists the problems addressed by each pattern. We 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. All subsequent patterns follow the Messaging style.
• 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. The base pattern for this section is the Message pattern.
• 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. The patterns presented in this section are special cases of the Message Router base pattern.
• 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. The base pattern for this section is the Message Translator.
• Endpoint Patterns describe the behavior of messaging system clients. They illustrate different ways in which applications can produce or consume messages.
• 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.
EIP 에서는 60 개 가량의 패턴을 분류
아래와 같은 카테고리로 나누어서 설명함
Integration Style – 어플리케이션 간의 통합
Channel Patterns – 메세징 시스템의 기본적인 속성에 대해서 설명
Message Construction Patterns – 메시지의 구성에 대해서 설명
Routing Patterns – 메시지가 정확한 수신에게 가는 방법을 토론. 메시지의 내용이 변경되는 건 아니며 어디로 가는지에 대해서만 이야기함.
Transformation Patterns – 메시지 콘텐츠의 정보변경, 많은 경우 송신에서 수신으로 갈때 메시지의 데이터 포맷이 변경되어야 함.
EndPoint Patterns – 메시지 시스템의 클라이언트에 대해서 설명, Application 이 어떻게 메시지를 생성하고 소비하는지에 대해 말함.
Management Patterns – 복잡한 메시지 기반 시스템을 유지할 수 있는 툴에 대해서 설명
Preface
This is a book about messaging. More specifically, it is a book about how to use message-based communication successfully to connect applications. It does not document any particular technology or product. Rather, it is designed for developers and integrators using a variety of messaging products and technologies, such as:
• IBM’s WebSphere MQ (formerly MQSeries)
• Microsoft's Message Queuing (MSMQ), accessible through a number of API's, including the System.Messaging libraries in Microsoft .NET
• Java Message Service (JMS) implementations incorporated into many J2EE application servers and standalone products
• Integration broker suites offered by vendors such as TIBCO, WebMethods, SeeBeyond, Vitria, and others
• Existing and emerging Web services standards such as SOAP, WSDL, WS-Reliability, etc.
This book is also about enterprise integration -- how to integrate independent applications so that they can work together. This goes beyond a single application with an n-tier architecture, which enables the application to be distributed across several computers. Whereas one tier in a distributed application cannot run by itself, integrated applications are independent programs that can each run by itself, yet that function by coordinating with each other in a loosely coupled way. Messaging enables data or invocations to be sent across the network using a “send and forget” approach where the caller sends the information and then goes on to other work while the information is transmitted in the background. Optionally, the caller can later be notified of the result through a callback. Asynchronous calls and callbacks can make a design seem more complex than a synchronous approach, but an asynchronous call can be retried until it succeeds, which makes the communication much more reliable. Asynchronous calls enable several other advantages such as throttling of remote calls, load balancing, quality of service tuning, and timeout handling.
주로 Messaging System 에 대해서 언급
Messaging 이 외에 File Transfer, Shared Database, Remote Procedure Invocation 이 존재
File Transfer
하나의 Application 이 다른 Application 이 추후에 읽어들일 파일을 쓴다. 이 Application 은 절대적인 파일이름, 파일경로, 그리고 언제 읽을 지와 쓸 지를 정해야 한다. 몇 Application 은 파일 전송 후 삭제하기도 한다.
Shared Database
하나의 Application 이 다른 Application 이 추후에 읽어들일 데이터를 DB 에 작성한다. 이 Application 은 DB 스키마와 조회할 때의 key, 그리고 언제 읽을 지와 쓸 지를 정해야 한다. DB lock 과 트리거링은 Application 을 설계 할 때 유용하다.
Remote Procedure Invocation
하나의 Application 이 몇 개의 procedure 를 공개하여 원격으로 접근 할 수 있게 한다. Application 은 procedure 가 사용 가능하게 하여야 하고, 데이터의 타입과 포맷을 맞춰 주어야 한다. 이 통신은 동기방식의 실시간 커뮤니케이션이다.
Messaging
Application 이 메세징 시스템에서 채널에 메세지를 통해서 통신하도록 해야 한다. 메시지의 포맷과 채널을 맞춰 주어야 하며, 동기 혹은 비동기 전송이 가능 .
What is a Messaging System?
Messaging capabilities are typically provided by a separate software system called a messaging system or message-oriented middleware (MOM). A messaging system manages messaging the way a database system manages data persistence. Just as an administrator must populate the database with the schema for an application’s data, an administrator must configure the messaging system with the channels that define the paths of communication between the applications. The messaging system then coordinates and manages the sending and receiving of messages. The primary purpose of a database is to make sure each data record is safely persisted, and likewise the main task of a messaging system is to move messages from the sender’s computer to the receiver’s computer in a reliable fashion.
The reason a messaging system is needed to move messages from one computer to another is that computers and the networks that connect them are inherently unreliable. Just because one application is ready to send a communication does not mean that the other application is ready to receive it. Even if both applications are ready, the network may not be working, or may fail to transmit the data properly. A messaging system overcomes these limitations by repeatedly trying to transmit the message until it succeeds. Under ideal circumstances, the message is transmitted successfully on the first try, but circumstances are often not ideal.
In essence, a message is transmitted in five steps:
1. Create - The sender creates the message and populates it with data.
2. Send - The sender adds the message to a channel.
3. Deliver - The messaging system moves the message from the sender’s computer to the receiver’s computer, making it available to the receiver.
4. Receive - The receiver reads the message from the channel.
5. Process - The receiver extracts the data from the message.
네트웍을 통해서 Message 를 하나의 System 에서 다른 System 으로 전송
메시지 전송의 5가지의 단계
Create
Sender 가 메시지를 생성하고 data 를 채우는 부분.
Send
Sender 가 메시지를 channel 에 넣음.
Deliver
메세징 시스템이 Sender’s System 에서 receiver’s System 으로 전송
Receive
Receiver’s System 이 channel 에서 Message 를 읽어 들임
Process
Receiver 가 Message 에서 data 를 추출, 처리한다.
