Tuesday, February 24, 2009

System integration nightmares

I'm currently poking my way through an enterprise service bus, figuring out how to make it do stuff. I've just successfully written my most complicated hello world program to date. It includes message formatters, message routers, two seperate processing pipelines, and it's processed across a SOAP interface generated from a generated WSDL file. Over engineering for the win, right?

The underlying metaphor embedded in the configuration language is one of a pipeline. Pipe line stages can have filters on both input and output, the output stage can select the next stage depending on attributes of the message, and the center of the stage, the component, does some form of transformation, all the while being isolated from the message transformation and routing happening around it.

The issue I'm having with this metaphor is that pipe lines are not turing complete. I need the ability to take a message in over a SOAP connection, do a bunch of steps (including writing to our local database as well as querying and updating a pair of remote ERP systems), and then return a result over that said same SOAP connection.

Now, in the simple examples, this return can be done, because an input endpoint can have metaphor breaking property of being inout as opposed to just in. What I'm scrabbling through the documentation attempting to understand is how i pass this SOAP connection through the chain so that I can return the result, even after a long trail of transforms. Not sure if it's going to work, or if I'm just going to have to cheat...

The most interesting point to me is that the pipeline metaphor is insufficient.