tags:

views:

360

answers:

2

I have to create a Java EE application which converts large documents into different formats. Each conversion takes between 10 seconds and 2 minutes. The SOAP requests will be made from a client application which I also have to create.

What's the best way to handle these long running requests? Clearly the process takes to much time to run without any feedback to the user.

I can think of the following ways to provide some kind of feedback, but I'm not sure if there isn't a better way, perhaps something standardized.

  1. The client performs the request from a thread and the server sends the document in the response, which can take a few minutes. Until then the client shows a "Please wait" message, progress spinner, etc. (This seems to be simple to implement.)
  2. The client sends a "Start conversion" command. The server returns some kind of job ID which the client can use to frequently poll for a status update or the final document. (This seems to be user friendly, because I can display a progress, but also requires the server to be stateful.)
  3. The client sends a "Start conversion" command. The server somehow notifies the client when it is done. (Here I don't even know how to do this)

Are there other approaches? Which one is the best in terms of performance, stability, fault tolerance, user-friendliness, etc.?

Thank you for your answers.

+3  A: 

Since this almost all done server-side, there isn't much a client can do besides poll the server somehow for updates on the status.

#1 is OK, but users get impatient really fast. "A few minutes" is a bit too long for most people. You'd need HTTP Streaming to implement #3, but I think that's overkill.

I would just go with #2.

NullUserException
We had to face a similar situation and only #2 seemed like a workable solution.
Hemant
A: 

For 3 the server should return a unique ID back to the client and using that ID the client has to ask the server the result at a later time

Lisa
That is what #2 does
NullUserException
Server doesnt have to be sateful.Client will persist the id to a persistant store and the Server also would persist the id to a persistant data store and then at a later time the client would use the id persisted from the store to request the information from the server
Lisa
we have used what i have outlined above and it works perfectly well.The only issue is we have two versions of our clients and some clients have not migrated to the later version where they used a id to request the information back from the server at a later time
Lisa