Transmitting Locale and other ctx alongside a message

[william_ferguson_au@yahoo]

What is the recommended approach for transmitting Locale and other context information with a message?

This might sound simple in principle and perhaps it is but consider ..

An application that supports many Locales and many industries. Each industry has its own set of terminology. So when a user logs in they see industry terminology and language pertinent to who they are. This much can be achieved with a specialised ResourceBundle.

But as part of that user's webflow they generate several messages that are processed asynchronously. Some of those messages may result in a document or email being generated and dispatched to a user that displays content generated in the context of an industry and Locale. Generally this would be the same context as that of the originating user.

So what is the best mechanism for transmitting that context along with the message? Adding it to all messages seems a little heavy handed and warps the business intent of the message. Is there a better approach?

[oleg.zhurakousky]

Let me try, but first let me set the scope.

The way I understand your question:

• User could be anybody and located anywhere.
• Processing servers might be a few, which means they wold have to handle the load from multiple geographical locations with different Locales

Correct? (if yes continue. . .)

I agree, sending locale with the message is not the right approach, but not because it could be heavy. I think the server first must be ready to process such requirement. Just because I'll send some locale info doesn't mean that server is capable of interpreting it. Which means there has to be some type of Map of supported Locales and such Map should exist somewhere on the servers and all you need to include in your message is just a key for a locale (i.e., US)

[william_ferguson_au@yahoo]

I meant heavy as in a large weight to add to the overall service layer, not size of each message, though it would add weight their too.

So you're suggesting that I modify the signature of every message accepted by my server to include all context information? In this case a Locale identifier and an identifier for the industry.

What happens when I am required into accepting another degree of context? Do I modify all message signatures again to append the new context?

It seems to me that message context is a crosscut and that there must be a cleaner way of handling it, but I'm just not seeing it yet and haven't seen anything out there that even mentions it.

[Mark Fisher]

You might just want to define a key (e.g. "locale") and then implement a channel interceptor that adds the current Locale as a MessageHeader attribute with that key.

From a Spring-based webapp, you can use the LocaleContextHolder to retrieve the current Locale while in the Message sender's thread (see: http://static.springframework.org/sp...extHolder.html)

[william_ferguson_au@yahoo]

Thanks Mark, still chewing it over, but it sounds like it might be what I want.

But in whose Thread would the ChannelInterceptor methods be invoked?
By a Thread from the MessageDispatcher pool or the MessageHandler/endpoint's pool?

Is there a sequence diagram somewhere showing the interaction between the messaging components? This might help clarify it for me.

[william_ferguson_au@yahoo]

I really need to know in which Thread the ChannelInterceptor's pre/postReceive methods will be called. IMHO this is a crucial question.


If the ChannelInterceptor's pre/postRecieve method are called by the Channel's dispatcher Thread then there is no way to generally configure Thread context based on the Message as the endpoint will use the Thread of the endpoint's Scheduler.

Which is it?

[Mark Fisher]

William,

The ChannelInterceptor callbacks for message reception will indeed be invoked in the dispatcher thread (since it is the one invoking receive). It is therefore correct that the endpoint's handler *may* be invoked in a different thread. This would be the case if the endpoint has a concurrency policy (otherwise, the handler itself is invoked in the dispatcher's thread as well).

If you want to pass a value from the sender's thread to the handler, then storing that as a Message attribute value might be the right approach. We are adding interceptors for endpoints as well, so once this is in place, it should be easier to propagate values transparently (is this your general goal?).

The sequence diagram is an excellent idea, and we will include this (along with more architectural diagrams/discussion in general) within the next milestone release. The model has been in a state of flux but with the upcoming M4 release, these diagrams will be very useful.

Regards,
Mark

[william_ferguson_au@yahoo]

OK, good .. it seems I am following the doco :-) Good doco BTW.

To answer your question, yes, propagating values transparently is the goal.
So having an EndpointInterceptor or an interception point that will be executed by the Thread consuming the message seems like a good idea.


So this would mean that I would need a ChannelInterceptor to add the context to the message and an EndpointInterceptor to retrieve the context from the message.


An alternate would be to have the ChannelInterceptor called by the consuming Thread. If there is no Endpoint concurrency policy then as you point out, this is the Channel Dispacther, otherwise it would be an Endpoint Scheduler Thread. This would also make the invocation of the ChannelInterceptor symmetrical, ie called by either produciong or consuming Thread by never by a Dispatcher that does also consume. But this may not fit well with the rest of the SpringIntegration design.