-
1. Re: Transformation engine
pfricke Nov 7, 2005 8:47 AM (in response to starksm64)We don't need to solve all of the problems outlined in BEA's writeup in a release 1 of transformation. We do need to pick a starting place that adds value and provides a fleixble technical foundation to grow.
-
2. Re: Transformation engine
rmarins Dec 22, 2005 9:00 AM (in response to starksm64)So, it's not yet clear what kind of transformation engine will be implemented. Simple XML transformations or also including Positional/Delimited/XML transformation?
-
-
4. Re: Transformation engine
ddossot Mar 17, 2006 9:22 PM (in response to starksm64)Dozer is great but isn't it too bean-centric?
XSL-T is extremely powerful, from my experience with Mule, is not enough as some message payload pre-parsing is often needed. This can be achieved with scripting enabled transformers, but isn't that scary? I have preferred a specialized regexp-based pre-parser in front of a chain of XSL-Ts.
Another thing I have experimented, with Entire-X this time, was body-to-header transformation, ie extraction of body content to fill header fields. Sounds crazy but when a client bluntly refuses to speak WS-Security and embeds credentials in the body, well, it simply saves the day. BTW. this was XPath driven.
All this might be too specific for your consideration, I just wanted to point out the kind of things that happen out there ;-)
All the best,
David -
5. Re: Transformation engine
marklittle Mar 18, 2006 7:22 AM (in response to starksm64)Hi David. Great feedback. As far as Dozer is concerned, I never saw it as the solution, only part of an overall solution. So things like XSLT, XPath and roll-your-own would be in there too. This is another case of one-size does not fit all, and we need to ensure that we're not locking developers (and deployers) into something that isn't appropriate. We obviously can't think of all possible use case scenarios, so I also want to ensure that whatever we do support is done so in a manner that is extensible by users: as much as possible, I don't want users to have to come running back to us (or mod the ESB code themselves) in order to support what they may consider a basic transformation mechanism.
Mark. -
6. Re: Transformation engine
marklittle Apr 3, 2006 7:11 AM (in response to starksm64)We're also looking at Smooks (http://milyn.org/Smooks). This looks like a pretty powerful transformation engine and the author (Tom Fennelly) is keen to work with us.
-