I think it is very necessary to think about this statement:
It is not possible to map behavior.
Assume there is a given system landscape of different business systems each fulfilling a part of the business processes. Now assume the goal is to model a common layer of services around these systems, a SOA layer, and to map this layer back to the different business systems. The purpose is to allow flexibility in the underlying system landscape, because the SOA layer remains stable, even if underlying systems change.
I wrote about this already here.
The Enterprise Service Bus (ESB) is designated to fulfill the mapping job. This – often – is a naïve assumption. Why?
What is an Enterprise Service Bus able to do? It can route and transform messages (if we omit the discussion of technical adapters that is irrelevant for now). This is not very much. Message transformation is not enough for mapping the process logic of different application systems. Yes – they can map interfaces from one format to the next – if the mapping is easy. Even if we start to discuss structural transformations and key mapping it is not so easy – but I want to omit this discussion as well.
The point I want to make is about behavior. What is behavior? Behavior is the contract that a service provides to service clients with regards to the messages that it is able to receive or send depending on the state of the business process that the service offers. A service contract that only defines the signature of service operations (WSDL) is too less to understand a service. It is necessary to know if it is possible to send an order cancellation after an order confirmation has been sent from the supplier to the customer or if it is not possible. It is necessary to know if it is possible to send two purchasing change requests in a row, even before the first purchasing change request has been answered or if it is not possible. This is a contract that a service offers to its clients – and it has to be defined. This is behavior. A means to define such a behavioral contract is the BPMN 2.0 choreography and interaction modeling for example.
So – now – if one participant – the customer – of the interaction is able to send a cancellation of an order after the order has been confirmed, but the other participant – the supplier – is not able to process such a cancellation request, then there is no way to make this scenario work by mapping. What should an Enterprise Service Bus do in such a situation? The Enterprise Service Bus certainly does not solve the problem.
So – how can the problem be solved? The only way is to agree on the contract before the business system(s) that should interact are purchased or developed – or to be lucky and thus be able to configure each of the business systems to comply to a contract that is defined afterwards. But good planning is always better than hope to be lucky.
How can this planning be done? Use BPMN 2.0 choreography and interaction modeling.