No, your session bean should definitely *not* know about its caller, as that would be tight coupling, leading to rigidity of the system - everytime a caller changes, or a new caller gets added, there is a likelihood that you also need to change the session bean. It's also hard to reuse the session bean in a different context. Not good.
What you could do - if this needs to be done by the session bean at all - , is using the Strategy design
pattern: create an interface for handling the message, for example called MessageReceiver, with a single method that simply gets a message. Have to implementations, one for synchronous, one for the asynchronous case. Pass in the right implementation when you call the session bean. The session bean then just needs to delegate to the receiver, without knowing at all what happens to the message after that.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus