SOA Tips-Use Separate Message Exchange Patterns (MEPs) for Business Responses

SOA-Tips

The wire is peer-to-peer meaning that in most cases the individual collaborating parties are interacting in a peer-to-peer way. They are not restricted to some kind of limited client/server functionality where you got the big guy and a small guy and the small guy has different concerns than the big guy. Each element in the infrastructure has to deal pretty much with the same set of wire-design concerns. Simple things in a client/server world do not work the same way in the wire-design world – like HTTP session cookies, pseudo-conversational modes, and so forth – because that implies that there is this hierarchical relationship elements that are collaborating with wire design. The wire is not hierarchical, its peer-to-peer. That means that any kind of correlation between interactions is in effect up to the business logic to resolve. You are moving information back and forth and you really cannot rely on simple things like HTTP sessions to keep correlations between messages sorted out. You are pushing that to the edge to keep these correlations resolved.

When dealing with stateful interactions, mandating a business response as part of a single request/response message exchange pattern (MEP) overly restricts the asynchronous collaboration that is required. Often the business response is not available quick enough to place the acknowledgment into the response. The only way the business response can fully be decoupled from messages that produce them is to place the acknowledgment in a separate message exchange pattern.