Integration story or 5 ways to transorm a message

[Dimitar Dimitrov]

Yesterday I wrote a blog entry (http://tinyurl.com/3jqw9v) about my experience applying Mule on a real world project and specifically different strategies for transformations and data mapping. I'd like to receive any comments or suggestions.

I apologize if this post is off-topic, please let me know.

Dimitar

[Andrew Perepelytsya]

Hi Dimitar,

Yes, I've been notified of this post and read it (we have taps on things around Mule online ;). What caught my attention was your transformation challenge. Specifically, how you decided to have a less anemic domain model and move transformations there instead of dedicated transformers (hope I didn't misinterpret it). Could you shed more light on this move? This could be an interesting pattern for some cases.

Andrew

On Fri, May 23, 2008 at 11:21 PM, Dimitar Dimitrov <dimitar.dimitrov@...> wrote:

Yesterday I wrote a blog entry (http://tinyurl.com/3jqw9v) about my
experience applying Mule on a real world project and specifically different
strategies for transformations and data mapping. I'd like to receive any
comments or suggestions.

I apologize if this post is off-topic, please let me know.

Dimitar
--
View this message in context: http://www.nabble.com/Integration-story-or-5-ways-to-transorm-a-message-tp17444043p17444043.html
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Dimitar Dimitrov]

<p>Well, the idea is that your domain uses adapters to wrap the source data
and the accessors perform the transformation in place. Since it's usually a
straight mapping, we haven't found the need to cache the values.</p>

<p>The mutators also store directly to the underlying source bean, except in
the cases where the value is derived from multiple input fields and updating
them would break some consistency rules (actually in such a case, it would
be better to avoid providing accessor if you can). A third approach is to
have a map for changed properties and have all your accessors check there
first and all mutators write there. This way you don't have to do a deep
copy when you move the message using the VM transport.</p>

<p>The technical part is that there is a transformer, which has its source
and output classes configured in the Mule configuration (I've had to add a
custom setter for the source class). In the transformer initialization, it
resolves a constructor of the output class, that takes a single instance of
the source class as argument. The transformation itself is invoking the
constructor with the payload. Note that the specified output class has to be
a concrete instance in this case. Perhaps I could have done something
similar using expressions but I like the type safety of this approach (if
one of the classes is missing it blows at runtime).</p>

<strong>Pros:</strong>
<ul>
<li>You can easily trace why the data is the way it is.</li>
<li>Adding new field requires changes to only one class (the adapter).</li>
</ul>
<strong>Cons:</strong>
<ul>
<li>At least the first layer of adapters is coupled to your source objects
(if you use regular transformers, the transformer clearly decouples the src
and output models). I would advice putting thest in a separate
packages.</li>
<li>Needs better regression testing. Usually one catches a good number of
breaking data changes in the transformation step. Since we transform on
demand, this means that you either need bigger unit test or might have
problems go unnoticed until integration testing</li>
<li>You lug a lot of data around, I can imagine that the serialization and
cloning overhead could become prohibitive. In such cases you can have a
method like Adapter.pruneStuffIDontNeed() that removes the parts of the
input message that have not been used until now (you also need to track
them).</li>
</ul>

--
View this message in context: http://www.nabble.com/Integration-story-or-5-ways-to-transorm-a-message-tp17444043p17453929.html
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Dimitar Dimitrov]

errr, something went wrong with the formatting in Nabble..

You can also find this post here: http://tinyurl.com/5lbrny