Middleware Interoperability Middleware interoperability is one of the main function of EAI(Enterprise Application Integration ) products.

Application A wishes to send a message to application B but its not bothered about a response. To make it more concrete, let us assume application A uses message queuing and the hub receives the message and calls application B using Java Remote Method Invocation (RMI). When application A sends a message using message queuing, the message is a) Guaranteed to arrive at its destination and b) Not send twice It is possible for hub to provide message queuing integrity but not without some work from the hub programmer. One way is for the hub to have two-phase commit transaction that spans receiving the message from A and calling application B. Alternatively, if the transaction had a special unique identifier, you can have the hub call application B again if it lost or never received the reply from the original submission. If the original submission was processed, the resubmission will be rejected. Suppose application A wants to see the reply from application B and expects to see the reply in a message queue, a different message queue from the sending message queue. If application A is sending many messages simultaneously it will have to be able to tie the reply to the original sender, which may require the hub to put additional data in the reply message. There is the possibility that application B processes the transaction, but the hub or the link fails before sending the reply message on to A. How can the hub guarantee that if application B sent a reply one and only one response message gets to application A? A simple solution is to put all the hub work reading in the input from A, calling B and sending the output to A in a single transaction, which means using two-phase commit to synchronize the queues and the transaction.

Finally suppose the hub instead of just calling application B, calls application B, C, and D all for one input message. How is integrity maintained ? A simple solution is two phase commit if any fail, they are all undone. Sometimes though the desired action is not to undo everything but for instance, to report to application A that B and C were completed but D failed. The problem now arises that if the hub goes down in the middle of all this processing, it must reconstruct how to reassemble the output for A. One ingenious solution is for the hub to send message queued messages to itself after processing B and C and let message queue recovery handle all the synchronization issues.

Application A

Middleware Hub

Application A

Routing,

Application B

Reformatting, etc

Application D

key

= middleware

Middleware interoperability showing one hub acting as a link to many applications. To Summarize  The integrity issues need to be thought through case by case.  It can be done.

 If you want the hub to handle everything, you probably have to use techniques like two phase commit and sending message queued messages within the hub.  An alternative is to handle recovery issues at the application level, typically by having the requester repeat requests if it hasnt received a response and having the provider detect and eliminate requests it has already processed.