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 in Oracle 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 be strongly typed all messages should be valid. The proxy service interface has to be weakly 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.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

UK Pre-Sales consultant specialising in business integration.

Search

Categories
Archives
« April 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  
       
Today