One of my on-going projects uses a light weight client to call a web service, which runs a fairly long running process, part of which will take at minimum five minutes. Testing has proved that the request to the webserver will cause a timeout. I belive the default is about 90 seconds. There are probably many ways to circumvent this problem, but the two that i am concidering are:

• Increase the time out settings to cover the longest anticipated duration.
• To implement fire and forget by the client, and let the webservice spawn an additional thread to carry out the long process, returning the request almost imeadiatley.

Increasing Timeout settings

Solution

From a little web reasearch it appears that there are three settings that may be able to assist me.

• The timeout property on the webservice proxy
• The http-runtime setting in App.Config of the calling assembly
• The http-runtime setting in Web.Config of the webservice.

Pros

• Allows trapping of exceptions during the process and passing them back to the client in the form of a SoapException.

Cons

• Process time may vary over operational lifetime of project requiring changing of configuration files, and possibly recompliling everytime the threshold is exceeded.
• If the request times out there is no way of knowing if the process is still running.

Fire and Forget

Solution

My second solution would be to use the BackgroundWorker to spawn a new thread in the code called the from the WebService's WebMethod.

Pros

• Allows imediate return of the WebMethod request so very little risk of time out, and therefore virtually limit less total process time.
• Because the client needs to request whether the process has finished any way, if an exception occurs this can be handled and the status relayed back to the client at the next request.

Cons

• Requires state of progress or completion to be stored by webservice (in database, text file, or similar).
• Requires the calling client to keep "asking" the webservice if the task has finished. This will involve more coding and the client having to "know" that it has to keep asking for the progress and or status of completion of the task.
• Requires extra coding to provide client with information if an exception occurs during the process.

So which is the best method to choose? Well this is probably going to sound like a bit of a cop-out, but it really does depend upon the application and how it is to be used. Each solution has it merits and its drawbacks as you can see.

For the project that I am concerned with I will no doubt use the fire and forget solution so I am not limited to time outs, as one of the processes (Archiving) will gradually take longer and longer to complete over the working life of the application, and I do not wish to be having to change the timeout and recompile frequently. I am also concerned that the timeout required couls easily surpass acceptable limits.

So how would you choose to carry out this task? Do you have any other solutions? Can you see any more advanatages or disadvantages of using either of the two solutions presented? your thoughts are welcom as always.

To be continued...

Background

As part of an ongoing project where a light weight client application needs to communicate with a database via a webservice I have been trying to get my head around a the best way to encapsulate data within custom objects and pass it from the client 's GUI to the Web Service's Data Access layer without replicating too much code or having the the client hold a reference to the same assembly as the webservice.

The intention is for the client application to have 3 layers, the presentation layer, a Business Entity / Business Logic layer and an Webservice Adapter layer. The Webservice will have the WebService layer, it's own Business Entity / Business Logic layer and a Data Access layer.

Initial Thoughts

My initial thoughts were to create an assembly which would hold a set of interfaces that will describe the business entities that both parts of the application would use. For example the interface fot the job object would be:

public interface IJob
{
    int Id;
    string CreatedBy;
    DateTime CreatedOn;
    .
    .
    DateTime LastAccessed;
}

This would require that both pairs of business entity assemblies would need to have a reference to the assembly. My plan was then to return from the webservice's webmethods the interface rather than the object. For example.

[WebMethod]
public IJob GetJobById(int id)
{
.
.
}

My plan was then bind the form controls to the properties of the interface but among a couple of minor flaws in my plan, there was one big one... It appears that you can not return an interface from a web service. I assume do to it not being serialisable. A little research later it appears that a better way would be to would be to use a shared base class for the business entities on both sides of the void, so to speak. So back to the drawing board slightly..

Second Thoughts

So now I'm thinking I need to create an abstract base class for the objects in the business entitiy assemblies in both the client and the webservice to inherit from. If I ensure the base classes implement the interfaces, then I can still bind my controls to the interfaces properties. So ignoring the various properties of the class I now have a bas class that implements the previosu

protected abstract class BaseJob : IJob
{
.
.
}

So now the Job class in each business entity layer will inherit from the BaseJob abstract class which implements the IJob interface.

public class Job : BaseJob
{
.
.
}

So this means that now rather than just having a reference to the assembly with the interfaces in for each business entity assembly I now have a reference to the base class assembly too. Is this really the way I want to go?

To be continued...

As part of the preliminary research and design process for a prospective new project at work one of the requirements will be for the application to provide a webservice that can be consumed from a third party's Java application.

So without further ado a quick .Net webservice was nocked up in C# with a single WebMethod. The WebMethod would return a formatted string containing within it the value passed in as a string parameter. The Webservice was deployed to localhost and tested using the simple webform test that is present on a local instal.

All good so far.

Next is to build a small Java web project that can consume the webservice. So having never written a Java application before, it's a quick trip to see Mr Google for a working example of how to call a webservice from Java. ( See My First Java App ) Google thankfully turned up David Hobbs' example "How to consume an ASP.NET webservice from Java via SOAP" on CodeProject. After a an hour or after nocking up a quick Java webpage with an embedded applet that will call the webservice and display the result, it should be a case of running it and seeing it work like clockwork.... After all the whole idea of a webservice is to platform unspecific, isn't it?....

Well, I shouldn't really have expected miracles, should I? After a whole afternoon of checking and double checking that the code was correct and using a free trial of ExamDiff Pro to ensure that XML that the java code was out putting was exactly what the XML that the server was expecting to receive I came to the conclusion that it must be something perculiar to our network. The XML output was identical except for the physical value of the parameter.

So at the end of the day I was at a loss. I'm not sure if it is an error in the code, or if the webservice expects different XML than what the description page offers up. Or if there is a network security issue which isn't allowing communication between the two applications. One of my .Net Windows applications calls a .Net webservice which is built in the same way as this test one perfectly, and has done for the last year! Event the third party representative was at a bit of a loss.

So I am at a bit of a loss with this one. May be a fresh look in a new week will shed some light. Who knows? If any one else has come accross this issue, and resolved or not resolved it, please post and let me know your findings!

Postscript: #1
I have just noticed on the botttom of David's CodeProject artical the following:

Notes
Some Java Virtual Machines (like the Microsoft one) only allow you to make a socket connection to the same machine that hosts the Java class files. Therefore, if you're using an applet like me, you will need to host the Java class files on the same machine where the webservice resides.

I wonder if this has anything to do with the problem... Oh well, maybe tomorrow I'll waste another fruitless afternoon trying to find out!!

Postscript: #2
Well after further investigation I haven't managed to determin the fault, but today we tried a different approach and used the "Web Service proxy" object from the Business Tier > Web Services category in the New Gallery.

We then followed the wizard and let it generate the code. The outputted code was tested and hey presto!!

So I guess this topic is closed for me now!