Having established who is driving the integration it’s tempting to start designing the message content or turning to a messaging standard like ORIGO or FIX.  However there is a layer above the message content that needs to be considered: conversation patterns. This is also a valid consideration for standards which often concentrate on the content and, whilst conversation patterns are implied or stated, it’s important to be certain about which you are using and the consequences of that choice.  Don’t go mad with the number of conversation patterns for the integration, try and keep it to a small set. The following are taken from a solution I designed in 2005, which has stood the test of time:

• Inform-Receipt:

A wants to tell B something and wants B to acknowledge it has been told; A does not need any information back from B, other than the acknowledgement.

• Request-Response:

A wants some information from B. ‘Ah!’ I hear you say, ‘that’s the same as Inform-Receipt!’, well you are probably going to implement them the same way but the conversation is different: in Inform-Response B is getting something from A but in Request-Response A is getting something from B. Also note that B is not bothered if A actually got the response.

•  Request-Response-Receipt

Extends Request-Response such that B now needs to confirm A has received the response before continuing.

Once you have established the conversation patterns consider a scheme for giving each message a unique identifier; this is useful for debugging problems but critical for managing idempotency and allowing for re—transmission if the connection or message is lost.

My final observation about conversation patterns is to be very clear about persisting the message before acknowledging receipt and, if possible, do this in a transaction otherwise it becomes much harder to sort out missing and duplicate message problems.

Follow

When considering an integration it is important to be clear about which part is the customer and which is the provider. This is probably fairly obvious in a B2B relationship but may require some thought for internal scenarios. My default position is that the consumer, or customer, should drive the conversations. Consider this high-level scenario:

Fairly typically, A is asking B for some information or to enact a transition. As this may take some time an asynchronous response is required (what is in the response is not important here, it could be some data, the result of a transaction or an error condition). Now it may be tempting to have A initiate the conversation with B when making the request (1) but have B initiate the conversation when providing the response (2). Now this can work well, especially in internal situations but if A and B are in separate organisations, or if B needs to know how to respond to a variety of clients (As), then there is an overhead in that both parties need  to build solutions to both act as the initiator and responder in a conversation. I firmly believe that it is simpler to have one party initiate all conversations and the other to only ever respond to requests. Look at the more detailed solution:

Here A initiates all conversations. This has advantages:

• A does not need to open firewall ports to receive responses from B
• A does not need to build an endpoint for B to respond to
• A gets to run things at its own pace
• A does not need to correlate responses from B if using the pattern shown above (it does need to maintain its own state)
• If A is temporarily down B is not impacted (simplifies SLAs)
• A might not need to authenticate B (depending on what is being returned)

Of course there are always exceptions but start with this pattern and then justify changing it based on specific requirements.

Follow