I assume you were handed this “solution” to implement. IMO, this is a very poor approach. I assume also that the intent is to externalize the mapping so that someone else can maintain the mappings. Not a terrible idea but the use of a DB to hold the mappings probably not the way to go. Another thing to consider is how often do the mappings change? They shouldn’t change that much–if they do then the upfront analysis has been very shoddy.
Java is absolutely the wrong thing to use in this case. Just say no.
As Mark suggested earlier, using XSLT is one possible approach that externalizes the mapping so that so-called business users can maintain the mapping by updating the XSLT. Perhaps you can chat with whomever is responsible for maintaining the DB entries and go over the pros and cons of the solution using a DB vs. XSLT.
Personally, I’d go with simply mapping from source to target (or maybe from source to canonical form to target) directly within Developer, as Mark suggests in his most recent post. It’s easy to maintain and debug. I’m not a big fan of XSLT but it is nice if the mapping needs to be externalized however you need a completely different set of tools for development and debugging.
The strength of Integration Server (webMethods is the company, not the product name) and Developer is the speed with which one can develop solutions for manipulating XML. Don’t drop to Java. Don’t needlessly externalize things that don’t change much.
#Integration-Server-and-ESB#Flow-and-Java-services#webMethods