Can a Web Servive send it's status to a client?

[Ethan Strauss]

Hi,
I have a web service which is doing a lot of processing and taking 4-5
minutes to do so. The processing is split into several discrete steps and I
would like for the service to be able to tell the client when it is done
with each step.
I have tried to do this in a couple of ways and neither have worked. Any
ideas how I might get it to work?

What I have tried was:

1) Splitting out each processing step into a different web method and then
having the client call each method as the one before it finished.
The sort of work, in that the client knew what was happening when,
but the I could not get the service to remember the intermediate results and
thus it did everything after the first step on null objects. I thought of
passing the results back to the client and then having it pass them back to
the service, but there is too much data in the intermediate results for that
to be reasonable.

2) Having the WebService class have a private status string and a public
WebMethod GetStatus which returns that string. The service then updates the
string as appropriate and the client asks for it periodically.
The value of the status string never actually changed. I wrote code
(C#):
status = "Starting Blast analysis.";
BlastSolutionSet thisSolution =
DatabaseAccess.GetExperiment(experimentGuid);
thisSolution.BlastAll();
status = "Collating Blast Data";
thisSolution.AssignBlastResults();
status = "Querying NCBI";
thisSolution.CollectNcbiData();
status = "Done";
In debug mode, the value of status was always "".


Ay thoughts?
Thanks!
Ethan

 

[Scott M.]

No.

 

[Mark Rae]

I would like for the service to be able to tell the client when it is done
with each step.

I don't believe this is possible due to the disconnected nature of the
WebRequest / WebResponse architecture ...

 

[MasterGaurav \(www.edujini-labs.com\)]

I have a web service which is doing a lot of processing and taking 4-5

minutes to do so. The processing is split into several discrete steps and
I
would like for the service to be able to tell the client when it is done
with each step.
I have tried to do this in a couple of ways and neither have worked.
Any
ideas how I might get it to work?

Use one service to start the process
And another service to query the status.


--
Happy Hacking,
Gaurav Vaish | www.mastergaurav.com
www.edujini-labs.com
http://eduzine.edujini-labs.com
-----------------------------------------

 

[John Timney \(MVP\)]

The only solution would be to use async web service calls from your client,
probably using threads in your client. The concept is certainly well
documented on google.

Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog

 

[Guest]

What I would do in this case - to "keep it simple" is have a GetCurrentStatus
WebMethod that you can poll on a timer from the client. You could either
return a percentcomplete number, or an enum that represents the current state
of the "job". Since ASP.NET WebServices have access to all the ASP.NET
infrastructure, you can use session, Global.asax, etc. for state storage on a
per-session basis. Probably you would not want to try to use ASP.NET Session,
instead a GUID representing the current "job" being a key into a hashtable of
"JobState" objects.
Peter

 

[Ethan Strauss]

Thanks to everyone who responded.
At this point I have more or less given up on this. It would have been nice,
but
it isn't needed. FWIW, I am running an ansynchronous service with another
web method which is GetStatus(). That didn't work :-(
I considered having the service write the status to a database and have the
client poll the database periodically, but decided that was more overhead
than it was worth.
I hope to have more time to look into this because I am sure it will come up
again for me.
Ethan

 

[MasterGaurav \(www.edujini-labs.com\)]

it isn't needed. FWIW, I am running an ansynchronous service with another

web method which is GetStatus(). That didn't work :-(

My personal suggestion.... avoid async service-calls as much as possible.

They are more pain practically than theoretically.

I considered having the service write the status to a database and have
the client poll the database periodically, but decided that was more
overhead than it was worth.

Well, instead of putting in database, you may want to cache it.

A simple solution may be something like this:

1. StartService (web service to start) returns a simple string - may be a
GUID
2. QueryStatus takes this GUID as a parameter and returns a simple %age on
completion.

Now, the %age completion doesn't need to be in database. You may very well
put it in server-cache whose key is this GUID.

That should do.

Keep in mind that it would fail in the case of web-farm deployment since the
cache would not be in session-server but on the same machine as in
ASP.Net... I hope I am wrong.


--
Happy Hacking,
Gaurav Vaish | www.mastergaurav.com
www.edujini-labs.com
http://eduzine.edujini-labs.com
-----------------------------------------

 

[Alvin Bruney [MVP]]

My personal suggestion.... avoid async service-calls as much as possible.
You need to explain this or at least qualify the statement. Async calls are
there for a reason, when you go against the grain, you need to provide
justification to support your position.

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
OWC Black book on Amazon and
www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley


z> My personal suggestion.... avoid async service-calls as much as possible.

 

[MasterGaurav \(www.edujini-labs.com\)]

My personal suggestion.... avoid async service-calls as much as possible.

You need to explain this or at least qualify the statement. Async calls
are there for a reason, when you go against the grain, you need to provide
justification to support your position.

In practice, what I have noticed is that is the response time is on the
higher side, one tends towards timeouts.

AFAIK, the main reason behind async-calls is to be able to monitor or at
least not get into a situation where application stops responding.

If any method is taking a long time for execution, I have always found it
better to go for regular check (periodic check for the progress). Yes, it
does consume a little bit of bandwidth but may be better otherwise.

For timeouts, we have various nodes:

1. Execution time of the service (ASP.Net configuration)
2. Response from the execution (IIS Configuration)
3. Firewall / Proxy configuration
4. Client configuration -- client may have its own timeout

I do agree that in terms of bandwidth utilization, async-calls may be
better. But then, there are various nodes that may need configuration
otherwise... like probably 4 of them as mentioned above.

On how many of them do we have a control may be a question to ask.


--
Happy Hacking,
Gaurav Vaish | www.mastergaurav.com
www.edujini-labs.com
http://eduzine.edujini-labs.com
-----------------------------------------