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...
Alex
-
Asynchronous request/wait for reply from ejb (4 messages)
- Posted by: Alex Reznikov
- Posted on: August 19 2004 21:38 EDT
Threaded Messages (4)
- Asynchronous request/wait for reply from ejb by Alex Reznikov on August 22 2004 21:39 EDT
- Asynchronous request/wait for reply from ejb by Ken Padga on August 23 2004 04:11 EDT
- Asynchronous request/wait for reply from ejb by Bostjan Dolenc on August 23 2004 05:08 EDT
- Asynchronous request/wait for reply from ejb by James Nuzzi on August 26 2004 08:47 EDT
-
Asynchronous request/wait for reply from ejb[ Go to top ]
- Posted by: Alex Reznikov
- Posted on: August 22 2004 21:39 EDT
- in response to Alex Reznikov
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:
Option A.
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.
Option B
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. -
Asynchronous request/wait for reply from ejb[ Go to top ]
- Posted by: Ken Padga
- Posted on: August 23 2004 04:11 EDT
- in response to Alex Reznikov
Alex,
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.
K. -
Asynchronous request/wait for reply from ejb[ Go to top ]
- Posted by: Bostjan Dolenc
- Posted on: August 23 2004 05:08 EDT
- in response to Alex Reznikov
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. -
Asynchronous request/wait for reply from ejb[ Go to top ]
- Posted by: James Nuzzi
- Posted on: August 26 2004 08:47 EDT
- in response to Alex Reznikov
The following article may be of some help to you:
http://www.javaranch.com/newsletter/200403/Journal200403.jsp#a4