7 Replies Latest reply on Apr 21, 2006 12:44 PM by marklittle

    Transformation engine

    starksm64

      We need Transformation for ESB....it also may well be a great standalone product along the lines of jBPM and JBoss Business Rules, but from the ESB layer its a pluggable aspect. The question is what is our default implementation.

      It needs to be able to transform customer records from a custom CRM app to Siebel, for example. It needs to solve the problem of one app thinks I'm "John Doe" and another app thinks I'm "Doe, John". And the more complex scenarios that exist in the real world, of course.

      We need to be able to transfer data between DTDs and XML Schemas and other formats. XML to binary and back....etc...

      Here is a more detailed description of BEA's capability which hits the mark pretty well.

      http://e-docs.bea.com/wli/docs70/diuser/wlxtover.htm

        • 1. Re: Transformation engine
          pfricke

          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

            So, it's not yet clear what kind of transformation engine will be implemented. Simple XML transformations or also including Positional/Delimited/XML transformation?

            • 3. Re: Transformation engine
              marklittle

              Dozer?

              • 4. Re: Transformation engine

                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

                  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

                    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.

                    • 7. Re: Transformation engine
                      marklittle