Not sure if I got your requirements right. How about going a plain XSL way (no java mapping)? Doing everything in XSL and using a generic template for address mapping. You could import it as needed and overide as needed.
Cheers, Thomas. Am 21.11.2013 um 03:13 schrieb Andrew Thorburn <[email protected]>: > I am currently in the process of building a "simple" proof of concept > using Camel and ServiceMix, and mostly it's been going fine - it so > far has done exactly what I want, if not necessarily always how I > want. > > However, I'm coming up a bit short on how to achieve what I want right now. > > The scenario is fairly simple: > > SMX is acting as a layer between my Application, A, and a remote > application, R. To try and centralise a bunch of the logic, we are > planning to have A transform a (non-trivial) graph of domain objects > to XML and send them over to SMX. SMX will then take this set of XML, > transform it into some different XML via XSL, transform that into a > POJO, then transform the POJO into the flat file required by R. > > The problem I'm running into is that I need to combine some of the > data in non-trivial ways. e.g. The domain objects I'm sending have > address data like unitNo, streetNo, streetName, streetType, suburb, > country, etc. Whereas R requires address line 1, 2, 3, 4, etc. So I > need to turn our separate address fields into combined fields, based > on various rules around shortening them if they're too long, etc. > > On top of that, some values also need to be mapped, as the value of > the field in the domain object may be different to the value that R > expects (e.g. A may have a street type of ST, but R may expect > STREET). This occurs in the addresses, and also in other fields as > well. > > This one ESB will handle multiple different interfaces on R, and I > imagine that while most will share the same requirements as far as > mapping and address formatting goes, I worry that some might not, so I > would like to come up with a solution that makes it easy to have one > generic implementation that can be overridden on a case-by-case basis, > or be able to be exposed as a web service, etc. > > It's possible I'm overthinking this, but I'm not happy with my current > solution: > > Camel Route is Web Service -> XSL -> XML -> ..., where the XSL calls > out to a static Java method for transforming the address and > translating codes. Note that there could be 5 - 10 different addresses > in a single request, and 30+ elements that need a mapping, out of a > much larger set of elements. > > My problem is that, while this seems fairly simple, it means I lose > access to everything Camel-, Spring- and OSGi-related. Mostly, it > means I'd have strong coupling between all my dependencies, no way to > access any properties apart from System properties, no way to call > Camel routes, etc, etc, which makes me very nervous, and just doesn't > *feel* right (I know, I know - that's a terribly subjective > qualification!). > > Does anyone see a better solution, or have any advice about things I > should have a look at which could help? Can I, for example, gain > access to the current CamelContext so I can call out to a camel route > for address formatting or other such things? > > Or am I really just stuck going with this: > > public static NodeList formatAddress(NodeList address) { String unitNo > = address.item(0).getChildNodes().item(0).getTextContent(); ... } > > public static String translate(String type, String val) { InputStream > is = XSLUtil.class.getResourceAsStream(...); ... } > > Thanks, > > - Andrew Thorburn
