JBossDeveloper

Long, long after I thought I would have something to look at ... I have something to look at. :-)

A prototype implementation of the transformer approach I gave above can be found here:

https://github.com/kcbabo/core/tree/transform

And a half-baked write-up can be found here:

http://community.jboss.org/wiki/Transformation

I don't think this is done by a long shot, but I do think it's functional enough that we can start banging on it and exchanging concrete ideas on how to improve it.  One thing your initial prototype had was a mechanism for annotating the from and to, which is not in my prototype but I think can be layered on top.

I have an updated implementation which uses service metadata to assign the "to" name in a transformation.  Code can be found here:

https://github.com/kcbabo/core/tree/metadata

How would that solve transforming using a 'middleman' XML for example? XML -> XML -> XML isn't that uncommon, since it's sometimes not wise to create transformation from every format to every format, but instead use a common format in the middle. The original discussion included Java-objects and such, however in this Wikidocument it's only discussing catching a Transformer using one format to another. Could it be possible to include a list of transformers to the exchange? In that case one could re-use existing Transformer-classes for these multitransformer solutions as well. Or do we have to create several exchanges? Certainly possible with dynamic routing, but might add unnecessary complex..

With three formats you could have TransformerOneToSecond, TransformerThirdToSecond and the solution for OneToThird would be just bundling them one after another. It's a pretty common case in einvoicing world (EDI/ASCII/common XML formats/etc combined)

How would that solve transforming using a 'middleman' XML for example? XML -> XML -> XML isn't that uncommon, since it's sometimes not wise to create transformation from every format to every format, but instead use a common format in the middle.

I agree that this is a common case and in many situations it's actually a best practice.  I will update the write-up to include this scenario.  As you mentioned, I actually see this as a pair of transformations:

XML ---t1--->  XML ---t2---> XML

Could it be possible to include a list of transformers to the exchange? In that case one could re-use existing Transformer-classes for these multitransformer solutions as well. Or do we have to create several exchanges? Certainly possible with dynamic routing, but might add unnecessary complex..

Yes, the exchange can be subject to multiple transformations.  As an example, the SOAP gateway could receive an inbound SOAP message and create an exchange targeted at a service provided by the Bean component.  The first transformation could be from the SOAP XML message body to a canonical XML format.  The second transformation could then map from the canonical XML format to the Java object representation that the Bean component is expecting.

With three formats you could have TransformerOneToSecond, TransformerThirdToSecond and the solution for OneToThird would be just bundling them one after another. It's a pretty common case in einvoicing world (EDI/ASCII/common XML formats/etc combined)

Yep.  Thanks for bringing this up.  We definitely need to add some more detail around this and include it as a primary use case for transformation.