• to reduce the message size to ease a performance problem (divide & conqueror)
• to make sure the message size conforms the size limitation of the messaging system (e.g. 4 mb limit in the MQMQ)
• The message is split into smaller chunks. Each of these chunks are processed independently by a service process. Finally the results are aggregated back to a single result (for further processing or for reply.)
• The sequence information (message-id, sequence-id, total-sequence, reply address etc) are added in the headers (to avoid parsing the body).
• The construction is generic, de change needed in the business processes are kept to minimum for example by using wrappers/handlers to manage the headers.
• After a timeout period, the incomplete chunk results will go to an error-queue.
Its parallel version is the split-aggregate pattern:
This open an interesting possibility with cloud computing: the processes can be computed for example using map-reduce algorithm from Hardoop. This solution is scalable but we need to consider the latency cost due to the network traffic.
See also blogs compilation about messaging for integration: http://soa-java.blogspot.nl/2012/01/asynchronous-messaging-for-integration.html
Please share comment.
Source: Steve's blog http://soa-java.blogspot.com
References
Hohpe's Enterprise Integration Patterns... one of the most popular SOA books in the market
No comments:
Post a Comment