« Is the mash-up the SOA Killer App? | Main | What SOA can learn from Web2.0 Part 1-productivity matters »

I read with interest David Linthicum's postings of a couple of weeks ago on semantic transformation, here and here. In particular, he gives a good description of the scope of the term transformation in SOA by saying:-

Accounting for the differences in application semantics is the process of changing the structure of a message, and thus remapping the structure and data types so that it is acceptable to the target system.

And later

Related to the concept of accounting for the differences in application semantics, accounting for content changes is another important aspect of transformation. In short, it’s the reformatting of information so that it appears native when sent to a target system.

While I agree with his claim that this is not in essence a new problem – similar problems occurred with data warehouses and data marts, I would caution extrapolating to the point where it is thought of as a straight forward and solved issue. The reasons for my caution are two-fold:

 Transformation is poorly supported in most products claiming to be SOA integration suites or ESBs. They mostly provide tools such as XSLT editors which can be hard to use with many more complex formats and are, in general, not very user friendly – treating transformation as a functionality tick-box, not a core feature. Before this is greeted with a wave of comments from readers who are entirely comfortable with using these tools and the vendors of products with this limited support, I will set a benchmark: these should be usable by the averagely skilled developer and not require the team XML or data format guru. This is because in my experience creating transformation mappings is one of the most common tasks in any SOA integration project which brings me nicely onto the next point:

 Some SOA proponents don’t believe that transformation is much needed because they believe strongly that correct definition of service should remove the need for any smarts in the middle. This is a debate I won’t reignite beyond referencing my blog-item here - it is answered in the section “The ESB is aspirin for the headache of badly defined services” – while it focuses on the ESB, the argument is in essence about whether you need to transformation in the middle or whether by correctly defining the service the need is removed. However, I will state again that this is a view that I fundamentally disagree with unless your organization is blessed by simple data formats and your projects focus primarily on writing new applications integrated into old rather than linking together old applications.

Which brings me to my last point, one size doesn’t fit all for transformation as with most attributes of a SOA implementation: the importance of transformation can only be assessed by each organization as it adopts SOA. You need to assess how complex your data is and how many formats are flowing around. The more complex the data and the larger the dictionary of formats the important transformation will be and more likely that you will need to consider how to capture and use the semantics.

Posted by rbradley in |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/266