I have an ejb that have to interacts with a request/reply queue. Solution is quite simple: dependency injection and go.... but.... but....
IMHO ejb implements business logic, gathering information from external system through a queue could be done but is really business logic? Maybe yes, today the only business is interact with an external system, tomorrow will be other...
A proxy could abstract queue interaction and leave ejb concerned on its purpose, business!
so collaboration will be:
but with a proxy I loose benefits of dependency injection and I have to implement a service locator and so on.....
Maybe I'm missing something but are not consumer? Listening on a queue.
My SLSB is a producer, send a message on queue e wait for a response ( this with a sync approach ) because requirements are a sync request from presentation tier and a jms integration with external system ( I have only this integration mechanism).
What would happen if you put your code that is in your Session EJB in a Message-Driven EJB's onMessage() method?
In regards to your doubt, in software design there are shades of good and shades of bad, and there is "working" and "not working." There is no "correct" and "incorrect" like a multiple choice question on a test.
Your decision to even use a Session EJB is questionable as you have not shown why a simple POJO business object is not sufficient. The client object in your Presentation can certainly communicate with a POJO business object. Here you still have separation.
Anyway, ideally you would not want to create a dependency between your application and the EJB API, so it is best to code the message handling in a plain Java class and then use one of these objects in your Session EJB. You never want to code actual business logic code statements in the EJB's bean class. The EJB is best used as a proxy itself.