Propagation of business changes in transformation components

Few days ago I started to write about separating business logic from message translation in middleware systems. Today I share some further thoughts concerning this issue. Particularly how message translation model usually looks like and what can we redesign it in order to make it more elegant.

Gregor Hohpe in his famous EIP book described message translation as a component of messaging infrastructure that is responsible for performing modifications on the incoming message.



Message translator can enrich, as well as reduce, the content of the message. In extreme cases translator can even replace incoming message entirely with the new content. While EIP book lists and describes possible transformations that can be executed against the incoming message (wrapping in envelope, enriching, filtering, normalizing an so forth), it does not discuss the possibility of delegation of the translation logic to the external business component.

Business requirements tend to change frequently during the software system development. Moreover, even when application is already built and deployed, it is still very likely that business rules are going to change. In general integration architects can safely assume that business requirements are going to evolve and being modified during the lifetime of the system.

If system architect decides to include business logic in the transformation components, then all changes to the business rules affect also translation modules (and therefore messaging infrastructure).

Implications of such approach are (just to mention few of them):
• Violation of Separation Of Concerns principle between messaging and business layers of the system.
• Low reusability of the both middleware and business components of the system.
• Worse maintainability of both business rules and the transformation components.
• Problems with distribution of the tasks within the team (since analysts have to work on the same component as the integration architects and engineers).
• Unnecessary redeployment of the messaging infrastructure on changes of the business rules.

What we would like to achieve is transformation model where business changes affect only business components of the system. In our perfect model message transformation should depend on business logic, but still be unaware of the business rules details. Therefore internal changes within the business components would not affect the messaging infrastructure.

In next posts I'll cover the latter model in more details (including Apache Camel and JBoss Drools solution) and present some experience of mine in the area of the discussed issue.