Recall this post from Mark in INT-710:
First of all, good work -- I like this syntax and think it is compact and elegant.
<service-activator expression="@someObject.foo(payload.bar, header.baz)"/>
The scenario we run into again and again is this:
1. I have a Message whose payload contains objects from Domain A. Domain A is essentially the DTO in this case.
2. I want the interface (arguments) to my service-activators to always be objects of type Domain B, which we consider the domain model for this service.
3. I already have a general purpose mapping transformation from Domain A to Domain B.
Unfortunately, there is no provision for mapping the payload of the Message from Domain A to Domain B before it is split into the several arguments that the service-activator takes unless I:
1. Provide another Message type that contains all Domain B objects and pass the whole Message containing Domain A objects through a transfomer, transforming the whole message prior to using the expression to break it down into arguments.
2. Allow the service-activator interface to be objects from Domain A rather than Domain B.
Solution 1 is undesirable because I now have the dual maintenance of two different Message types with the only difference being which domain they are using.
Solution 2 is undesirable because the first order of business in every one of my service activators will be to transform Domain A to Domain B even though I already have a general purpose transformer to do this work.
Has anybody else run up against this? Any thoughts on how to resolve this architectural dilemma?