We are designing a web application which will among other things talk to the SAP box. When the system administrator creates a new user in our system, it has to validate the data with SAP and will allow to proceed ONLY if everything is ok. Now, the communication with SAP is via JMS and it's easy enough to send a message to SAP and proceed to the next step. However, we need to wait until the reply is received before proceeding (and, mind you, it's pub/sub, not point to point!).
Anyone got good suggestions on the best way to implement this? Got a couple of ideas myself but none of them seems simple and elegant enough...
Just wanted to mention the solutions to that problem that came to my mind.
But first the process in detail:
1. Input user details
2. Verify their data is correct with SAP (by sending JMS message)
3. Receive confirmation from SAP (ie receive JMS message)
4. Save user details.
As you can see, steps 2 and 3 are asyncronous, so that we can't really do it all as a part of a "normal" EJB method.
So, below are the ways to solve the problem:
The UserDetailsEJB calls another object (UserConfirmManager) that sens a JMS message to SAP, and goes to sleep. When the reply JMS message is received, it invokes an MDB that somehow wakes up the UserConfirmManager. We expect the whole thing to take about 2-3 seconds seconds or so, if it's over that then UserConfirmManager returns an error. A problem with this approach is that I don't know yet how to avoid thread-related functions here. Another problem is that there's a fairly long-running EJB call.
We make the whole thing exposed to the front end. The user will input details and they will be saved. A JMS message will be posted to SAP and the status of the data is 'being verified'. The web page on the front end shows a message sayng "please wait while the data is being verified". The user browser will be "stuck" on that web page until the verification is complete and then re-directed to the next page saying "success" or "failure" (could be easily achieved with meta tags). So here we basically make the client do the polling.
A problem with this approach is that the front-end is not as simple as we'd like it to be, ie unnecessary complexity is exposed to the web layer.
There's absolutely ***NO WAY*** to avoid managing threads with your Option A, and as you should know threads are a no-no with J2EE servers. Forget about it, start looking at Option B instead.
What about Option C?
Send message in a (session) bean method. Then wait for the reply in the same method by creating a MessageConsumer and invoking receive method. Message reception should be synchronous with a timeout, so that the bean won't block forever (well, more likely until transaction timeout).
This way you won't have to manipulate threads, but the call will still be long-running. The only drawback of long-running is that you can potentialy deplete thread pool. You can't really avoid this unles you opt for something like option B.