Multiple argument service methods

[jkschneider]

Recall this post from Mark in INT-710:

<service-activator expression="@someObject.foo(payload.bar, header.baz)"/>

First of all, good work -- I like this syntax and think it is compact and elegant.

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?

[Mark Fisher]

I'm not sure if it's the best idea, since it's not as explicit as the transformer. However, to have this behavior happening behind the scenes without requiring a transformer for each service-activator, you could register a Converter that converts A objects to B objects. By using Spring's ConversionServiceFactoryBean with a bean id of "integrationConversionService" and adding your Converter implementation, you would be enabling that Converter's use from SpEL evaluation as well as for matching the "datatype" attribute on any <channel>. This is something relatively new in the 2.0 milestones, and it's not yet sufficiently documented, so let me know if this description helps.

Thanks,
Mark

[jkschneider]

Works like a charm. Thanks.

One minor suggestion: auto-wire by type the ConversionServiceFactoryBean whenever only one is defined in the appContext so that we don't need to specifically know the name "integrationConversionService".

Thanks again for your quick reply.

[Mark Fisher]

Glad to hear that works. We probably can't rely on autowire-by-type - mainly because there can be multiple instances of ConversionService in an ApplicationContext. In fact, the bean factory can use its own instance, and we need to make sure that ours is distinct. For that reason, we have decided to rely upon the "reserved" bean name of "integrationConversionService". We do plan to make the configuration simpler. Please feel free to add you suggestions to this JIRA issue: http://jira.springframework.org/browse/INT-1178

Thanks,
Mark