Message ordering is a key concept in a service orientated architecture. It is a key concept, because one of the core tenets of SOA is that a service must remain autonomous. In remaining autonomous, a service must be able to deal with any unexpected circumstance of messages sent to it, including the possibility of messages being received out of order.
There are two core strategies you can apply when designing your service: you can either force your client to send messages in the correct order, or you can enable messages to be processed out of order and implement mechanisms within your service to deal with the consequences of this. There are strengths and weaknesses to both approaches. In general, imposing ordering has a cost to the performance of the solution, because managing ordering requires you to manage the state of order. However, removing ordering requires the service to respond to the consequences of receiving the messages out of order. This has an additional development cost, which normally requires the development of compensating transactions.
When discussing the strengths and weaknesses of imposing ordering, the decisions have to be considered for two distinctly different scenarios: homogeneous and heterogeneous ordering.
Homogeneous message ordering
Homogeneous message ordering is ordering of messages with the same schema. For example you may have a message to update a customer. In this example, it is important that ordering is considered, because messages being received out of order could result in a customer being updated in an incorrect state (because the final update to the customer has been overwritten by an earlier message which has been received out of order).
Imposing ordering of such messages can be achieved in WCF using a binding that supports ordering, such WsHttpBinding (this uses the WS-ReliableMessaging policy). Likewise, BizTalk can support ordering through use of correlation. However in such ordering scenarios, be mindful of the fact that both the client and the endpoint must be order aware. So for example, if BizTalk (as the client) correlates messages being sent to a web service that is not order aware, no guarantee can be made on the order the messages are processed by the endpoint.
Enabling a service to receive homogeneous messages out of order means that the endpoint must be able to cope with messages that have expired; the service must cope with the fact that the inbound message has already been superseded by a newer message. An expired message is known as a "zombie" message. The simplest way to ensure that the endpoint is able to evaluate the message as older than the previous message is to include a published date (date time) on the outbound message. If the endpoint persists this published date as stateful data, the service can then evaluate the previous published date for the message and ignore older messages.
Heterogeneous message ordering
Heterogeneous message ordering is ordering of messages of different schemas that have a relationship to each other. For example you may have a message for each customer and each customer may have many bank accounts, each of which constitutes a separate message which is related to a parent customer message.
Imposing ordering of such messages means that the publishing system needs to maintain some understanding of related messages that have been previously sent. In BizTalk, this is achieved using correlation which requires messages to expose distinguished fields that will be used for correlation.
Whilst imposing ordering is achievable its performance cost can be avoided if the endpoint is designed to be order agnostic. When an endpoint is order agnostic, it is able to receive heterogeneous messages in any order and tie the messages together within the endpoint. So for example, the endpoint would accept an account for a customer it has yet to receive the message for. To enable the endpoint to correlate these messages, the customer and account messages would need to contain enough information about the relationship between these two entities. The endpoint then needs to be designed to be able to accept these messages in either order and deal with the consequences of this.
By enabling an endpoint to receive messages out of order, the service endpoint must also deal with the consequences of one these messages never arriving at the endpoint. So, for example, if a customer has two accounts and only one them is received by the endpoint, it may be important to deal with this account having gone missing. This scenario would require compensation.
Compensation is some form of action that compensates the publishing system when a failure has occurred. Compensation can take many forms from the simple to the sophisticated, depending on the requirements and the business value. Indeed, in some scenarios, it may be deemed reasonable not to provide any form of compensation at all. A simple form of compensation might be to email an administrator to tell them in invoke a manual procedure. A sophisticated form of compensation might be to send a compensating message back to the publishing service which would then rollback the state of customer in that system.