EAI project strategies-4. EAI basic architecture August 3, 2009Posted by Terry.Cho in Architecture, EAI.
Lots of EAI solution provides EAI components and frameworks but when we integrate system we have to make framework for the target systems. In this article I will explain about formal reference EAI architecture.
Interface Module is most basic module that integrates sender and receiver system.
This module gets a request from sender system. It has two modules
Adapter is entry point from Legacy system. It has native interface for the legacy system. It transfer the data into internal format like XML.
Sometimes this module is combined into Adapter. This module translates native format of input message into EAI internal data type and format. Data format means data structure including header etc. Each enterprise has internal standard data structure with transaction header, sender id, timestamp etc. This module translated unformatted message to enterprise internal standard message.
This module is very important in EAI.It processes incoming message to fit out bound message.
This module route incoming message to target system depends on contents or header. Routing can be occurred single source system to single target system (1:1 multiplicity) or N:1, 1:N multiplicity.
This module mapping structure of data from source system to destination system. It changes message structure by using mapping between message fields.
MEP (Message Exchange Pattern)
Mediation also handling MEP. MEP means message communication methods like Sync, Async, Deferred. It uses message queue like JMS to covert MEP.
Outbound is same as Inbound module. It translate EAI internal message into native message of destination system.
Monitoring and Trouble management.
EAI also has to have transaction monitoring and audit trouble & recovery feature.
Transaction Log is used to recovery/audit transaction when EAI or connected system has been failed. In transaction log, the transactions are identified by unique transaction id. The id is usually described in message header.
Concern of transaction log in EAI is where we store the log. Writing log always need physical disk IO. It directly impacts EAI interface performance.
We can choice log storage between file system or database.
If we use file log, the performance is faster than database. But problem is the log files are stored across a lot of hardware. So when problem is occurred and to find the transaction log, we have to search all of log files across all EAI machines.
In contrast if we use database for storing log. It provides very convenient log analysis. If transaction error occurred we can find it by simple querying from database. Compare to file based logging, it provides single logging point. But if the database has been down, the problem impacts production EAI system. (EAI system has a dependency to database )
To solve these problem, I suggest async log writing system with JMS.
JMS based logging separates logging system and EAI system. Even if database behind EAI is failed, the impacts are minimized. (Log datas are stored in JMS queue until the database is recovered)
In JMS based logging system, we have to consider where the jms messages are stored. (memory/file or database). Memory based JMS store is fastest but can be lost message if JMS server is down suddenly. File based JMS store doesn’t lost message but performance is slower than Memory based JMS. (But I recommend to use file store based JMS )
Finally JMS based logging system can minimize performance degradation in EAI. But has a lot of factors to be considered in architecture design.
Error Handling Logic (Error Hospital)
This module covers error in EAI system. Error handling in EAI system has 3-steps.
Aware the error, logging cause of the error, and recover the error.
I don’t know who make the word named “Error Hospital”. Doesn’t it look great?
If an error has been occurred in interface, the error is handled gathered into error hospital. And the error is handled by error handling policy (Ignore, automatically recovery, notify to system engineer etc.)
Error Handling Policy
The error handling policy that I mentioned are like this.
|Ignore||Simply ignore the fault and purge message.|
|Report||Report the fault. Optionally send notification message (Email,IM,SMS etc)|
|Retry||Automatically retry the transaction with specified time after specified sleep time||After failing all of retry, next error handling policy definition is required.|
|Report the fault and let user select policy described above|
Commonly EAI requirements has 10~30% XA based distributed transaction. It is easy way to guarantee data integrity between integrated system. Even if XA is easy to apply internal architecture of XA is complex. So it needs a sophisticated testing.
This is one of most important features in EAI. If one interface has a problem, the interface should be deactivated to prevent problem propagation or impact to other interface.