Handling the transformation of multiple message types in Oracle Service Bus

Roger wrote a blog post recently about my post entitled “Dynamic transformations in Oracle Service Bus 10gR3“ which got me thinking about the different ways you can handle the transformation of multiple message types inOracle Service Bus and the things you should consider before selecting one approach over another.

Before I discuss the different solutions and their benefits/disadvantages, let me describe the basic scenario I am talking about:

“I have/want to be able to receive messages in a number of different message formats and transform them into a common format in order to invoke a backend service.”

In terms of handling this in Oracle Service Bus there are a number of possible solutions:

Solution 1 – A separate proxy service for each message type

Solution 2 – A single proxy service containing if/then logic to determine the appropriate transform to apply for each message type

Solution 3 – A single proxy service which selects the appropriate transform to perform by inspecting the message type and determining the correct transform to apply at runtime (as described in Dynamic transformations in Oracle Service Bus 10gR3)

Before we consider why you would choose one over the other, lets make some assumptions:

- We have N different message types

- Each message type needs to be transformed into the same common data format

- We are invoking a single common business service

- We already have a message definition (WSDL, XML Schema or MFL) for the common data format

Now, on to the comparison:

	Solution 1	Solution 2	Solution 3
Number of assets to create/manage	3N N x Proxy services N x Transforms N x Message definitions	2N+1 1 x Proxy service N x Transforms N x Message definitions	2N+1 1 x Proxy service N x Transforms N x Message definitions
Work required to add N+1th message type	+1 Proxy service +1 Transform +1 Message definition	Modify existing proxy service +1 Transform +1 Message definition	+1 Transform +1 Message definition
Adding message type dependent logic/error handling/monitoring	Easy as each message type has its own proxy service	Possible but makes the proxy service more complex and harder to maintain	Possible but only by adding if/then logic which suffers from the same issues as solution 2.
Adding message type independent logic/error handling/monitoring	Difficult as it has to be added to each proxy service	Easy as this can be added outside of the if/then logic	Easy as everything in the proxy service is message type independent
Changing the incoming message transport/protocol	Difficult as every proxy service would need to be changed	Easy as there is only one proxy service to modify	As solution 2.
Message validity	Since the proxy service interfaces will bestrongly typedall messages should be valid.	The proxy service interface has to beweakly typed to accept multiple message types and so there is more likelihood you will have to handle invalid messages.	As solution 2.

In conclusion, I recommend choosing:

Solution 1 – If you have lots of message type dependent logic; need to ensure messages are valid and don’t mind the maintenance overhead

Solution 2 – If you have a few message types; don’t mind modifying the proxy service to add a new message type and don’t want the overhead of managing multiple proxy services

Solution 3 – If you have lots of different message types that change regularly and you don’t want to have to make proxy service changes to add a new message type

I’m keen to hear your thoughts/experiences/comments.