SOA Tips-Message Exchange Patterns (MEPs) are the units of ‘wire’ collaboration

SOA-Tips

The units of ‘wire’ collaboration are the Message Exchange Patterns (MEPs)

The most important thing to understand is that wire-design from an application perspective is made up of Message Exchange Patterns (MEPs) . These message exchange patterns are just units of simple message exchanges and are a way of incrementally shipping messages back and forth between different consumers and providers – whether it is with HTTP itself using Put, Post, Get, Delete, or WSDL 2.0 MEPs, or AS 2.0 MEPs. These are the incremental building-blocks of how data flows on the wire. These message exchange patterns are transient primitives that allow us to send a message and get back some immediate response to that message interchange.

Transient message exchanges

Message Exchange Patterns are transient message exchanges in the sense that they are simple synchronous interactions, typically end-to-end, that causes the message to be transported with some simple acknowledgment that it reached the other end. This is one of the things that distinguishes this infrastructure integration from the web-site interaction over the net because typically you are expecting a kind of full-fledged response coming back on the HTTP request and at the integration level often it is just a simple acknowledgment. Out of these simple Message Exchange building blocks we build larger practical conversations.

Design focus

The first consideration in building up a wire design is to determine which MEPs you are going to be using for what and define which particular transports you are going to be transporting these messages over. The first building-block that you have to think about in doing wire-design are which specific message exchange patterns you are going to use. It is perfectly fine to use HTTP directly. You don’t have to use a SOAP based message exchange pattern in order to do wire-design. That is a design choice you can make and it is not something that you have to feel bad about in the sense that you’re not ‘puffing up’ your wire design with the complexities of SOAP.

As we saw in previous entries, conversations are longer running contexts across which we are trying to collaborate. These conversations are built up of correlated messages. Message exchange patterns are not conversations – they are just a way of shipping the messages over the wire. From a network perspective, the network does not understand what a conversation is. Conversation is part of the wire design that is interpreted at the endpoints based on the correlations between these messages that have been described in the wire design architecture. Clearly, these conversations are peer-to-peer. Each side has some objective they are trying to achieve. Each side correlates these messages in different ways and they are just using the network to interchange these messages. So it is really important as part of the wire design to define the roles and correlations, the overall life cycle of the conversation, and the shared state that these conversations describe.

If you do not have a clear design for these, you cannot achieve a practical collaboration wire design.