This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Comment

I'm not keen, at the moment, to change to QueueChannel. I want to test the orchestration itself, not just a service, so the MessagingTemplate sounds like the way to go. Looking at the documentation it looks awesome, except for something that puzzles me out :
public Message<?> receive(final PollableChannel<?> channel) { ... }

Yes, receive() only works with PollableChannel since by definition only PollableChannel has capabilities to buffer messages while still maintaining the semantics of P2P messaging contract (for each message there can only beone consumer). This means its is holding messages until a consumer asks for it. The flip side of it are the SubscribableChannels which DO NOT buffer messages. The SubscribableChannel work together with MessageDispatcher to dispatch arriving messages according to the message exchange contract represented by a particular SubscribableChannel (P2P or Pub/Sub). The P2P type channel (e.g., DirectChannel, ExecutorChannel etc.) will require that there should be a subscriber consuming messages otherwise you'll see MessagingException telling you that "dispatcher has no subscribers" where with Pub/Sub channels (e.g., PublishSubscribeChannel) each Message wil be dispatch to as many subscribers as present. If 0 the message will be discarded etc.
So the bottom line is:
You poll from PollableChannel
You subscribe from SubscribableChannel

I understand you come from the Mule background and trying to look at Spring Integration as something similar. Similar we might be but not identical. If you go through the Enterprise Integration Patterns (which we treat as specification for Spring Integration) http://www.eaipatterns.com/ you may notice how misrepresented some of the EIP concepts are in Mule. That is one of the reason why we have more and more people and organizations migrating from Mule to Spring Integration

From a *producer's* perspective, every MessageChannel looks the same (they all have a "send" method), but on the consuming side there are two main EIP components: PollingConsumer and EventDrivenConsumer. Our two categories of channel implementations mirror those (PollableChannel and SubscribableChannel being the two sub-interfaces extending MessageChannel where the former provides receive() and the latter provides subscribe(handler)). Therefore, in a MessagingTemplate, an explicit RECEIVE call means you are effectively playing the role of a PollingConsumer. In the typical Spring Integration application configuration, you would only have things like <router> or <service-activator> connected to *some* <channel>. THEN, the proper consumer type is automatically instantiated based on whether that channel is pollable or subscribable.

I would like to encourage you to look at the <gateway> which Oleg linked to above. That allows you to work with "just an interface" and the details of the downstream flow (whether sync, async, scatter/gather vs. linear pipeline, etc) are all hidden behind that interface so you can do simple operations that can be request/reply or one-way depending on the method signature.

Finally, if you really do want to add a PollableChannel (to buffer messages as Oleg mentions and therefore provide the receive() method), you can add a <bridge> from a subscribable channel to a pollable one.

Comment

I'm pretty aware of the EAI patters, and I do recon the differences of the messaging patterns. Anyway that was a very good explanation, thank you!

From my point of view, neither MessagingTemplate or the MuleClient implements any kind of pattern, and I just was hoping that there was an equivalent of the client in Spring Integration.

As MessagingTemplate resides on the spring integration 'core' I do totally understand that you don't want to 'pollute' it with non completely necessary stuff, like this, that will be probably only useful (Although quite a lot) for testing.

But I do feel that this kind of test tools, even if they don't reside in the core, are quite needed, all unit tests found in the samples repository won't actually test orchestration and if they do, they will just use pollable channels that only cover a minimum fraction of the needs of an integration architect.