Question

Here is my requirement.

I have a client that was sending a specific message format to some software service provider(ABC) using what ever network protocol.

Now this client is switching software service provider (XYZ) but does not want to change their software and wants to continue sending the same message of ABC provider.

• Provider ABC uses some sort of positional based message format over some archaic network protocol
• Provider XYZ uses XML over HTTP(s) web service not SOA just simple POST with XML
• Some values can be directly mapped while others must be recalculated or modified. For instance converting client’s account number from ABC Provider to account number of XYZ provider. this is for request and response.
• The archaic network protocol will be converted to TCPI/IP at the network level so that is not an issue.
• The client expect a response in real time. I.e: Client makes request, XYZ does what ever and response back to client.

So I need to create some sort of tunnel that accepts TCP/IP converts the message to XML, sends it HTTP(s) POST to XYZ, get back XML response, convert back to positional based, reply back through TCPI/IP to the client.

Is this an ESB type thing, should I just write some sort JAVA server app that will do this?

Answer 1

Tried Mule ESB it’s very light weight. I would say even more so then some of it’s competition. I like how it’s not particularly bound to SOA or soap. So you can construct any kind of end point from plain TCP/IP, HTTP, File, to Email to anything really it has more then a dozen connectors and you can even write your own. I also like the fact that the message can be anything. I could be wrong but even when others claim they have various connectors and message formats they seem to have SOAP somewhere hidden under the hood and it seems icky lol Some others seem good, but have poor docs. Didn’t like the fact that some basic JDBC functionality is only available in the enterprise edition. I.e: To get Output parameters from your stored proc call you need the enterprise edition.

In reality I could have picked any server API that allowed me to create a server to receive HTTP, then write my code to transform a message, open a client connection to the next service send it off, receive the response, re-transform it back and return to the client. All while making sure threads and queues are behaving correctly within the server. Maybe I could have just used jetty and a servlet and do everything in one request. It’s an option, but if I have to switch to TCP/IP then I just change the config a bit. Waiting to see what the client says.

The ESB is basically the glue and plumbing. All I had to do was write three custom transformer classes as the messages I deal with are proprietary banking formats and don’t exactly map to simple XSLT/XML transforms… And about a 20 XML tags to put it all together…

This is all I needed to get this out of Mule (not including the tags to build my datasource and SQL query)…

<flow name="myFlow">
    <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8081" />
    <object-to-string-transformer />
    <custom-transformer class="com.mycom.transformer.MyTransformer" />
    <enricher target="#[variable:client]">
        <jdbc:outbound-endpoint queryKey="getClientConfig" exchange-pattern="request-response" />
    </enricher>
    <custom-transformer class="com.MyCom.transformer.MyOtherTransformer" />
    <http:outbound-endpoint exchange-pattern="request-response" host="xxx.xxx.xxx.xxx" port="80" path="some path" method="POST"/>
    <custom-transformer class="com.MyCom.transformer.BackToOtherFormat" />
</flow>

So basically…
1- receive HTTP(s) with custom message
2- Parse message to get client number
3- Lookup client number in database to get client number for the other service…
4- Create the new message
5- Send off to other service
6- Transform response back
7- Return to client