Lifecycle of .Net Web Service

[P Chase]

I am new to .Net Web Services, having done similar stuff in Java
before.

The life-cycle of a particular Web Service is presumably not the same
as that of the container in which it runs. Therefore, I wonder if
there are hooks that I can use to get something done when the Web
Services starts up, and something else done when the Web Service shuts
down.

At the moment, I'm using the constructor for the start-up hook, but
that seems wrong. And I haven't thought of an equivalent for shut-
down.

I'm using C#, by the way, if that matters.

 

[John Saunders [MVP]]

I am new to .Net Web Services, having done similar stuff in Java
before.

The life-cycle of a particular Web Service is presumably not the same
as that of the container in which it runs. Therefore, I wonder if
there are hooks that I can use to get something done when the Web
Services starts up, and something else done when the Web Service shuts
down.

At the moment, I'm using the constructor for the start-up hook, but
that seems wrong. And I haven't thought of an equivalent for shut-
down.

I'm using C#, by the way, if that matters.

There is no container. This is not J2EE.

You should probably not be doing things "when the web service starts" or
"when the web service shuts down". What did you have in mind to do?

 

[P Chase]

There is no container. This is not J2EE.

You should probably not be doing things "when the web service starts" or
"when the web service shuts down". What did you have in mind to do?

OK, so hopefully I understand another difference now between Java
servlets (what I'm used to) and .Net Web services.

However, I still have issue to sort out. For part of its operation, my
Web service depends uses a DLL that is single-threaded. Therefore, I
have a dedicated thread to interact with the DLL, and use a queue to
post requests to that thread. I need to know when to start and when to
stop that thread.

At the moment, I start the thread when the first request is received
at my Web service. But I would like to find a time when i can shut it
down cleanly; currently, it just runs until the process is killed,
which is ugly.

Note that I don't want to make my whole Web service single-threaded
(if, indeed, that option is available in .Net), because it does plenty
of other processing that is not restricted to single threads. As the
intended throughput of the system is high, and we're supposed to get
some fancy hardware to run it on, I need to use multi-threading
wherever possible, to keep those many cores busy servicing users.

Any suggestions?

 

[John Saunders [MVP]]

OK, so hopefully I understand another difference now between Java
servlets (what I'm used to) and .Net Web services.

However, I still have issue to sort out. For part of its operation, my
Web service depends uses a DLL that is single-threaded. Therefore, I
have a dedicated thread to interact with the DLL, and use a queue to
post requests to that thread. I need to know when to start and when to
stop that thread.

At the moment, I start the thread when the first request is received
at my Web service. But I would like to find a time when i can shut it
down cleanly; currently, it just runs until the process is killed,
which is ugly.

Note that I don't want to make my whole Web service single-threaded
(if, indeed, that option is available in .Net), because it does plenty
of other processing that is not restricted to single threads. As the
intended throughput of the system is high, and we're supposed to get
some fancy hardware to run it on, I need to use multi-threading
wherever possible, to keep those many cores busy servicing users.

Any suggestions?

Yes. I suggest you take your single thread and put it into a Windows
Service. It should not be in the web service at all. Communicate between the
web service and the Windows Service by using either .NET Remoting or by
using WCF (over a TCP-based channel).

This should actually simplify the testing, as the two concerns will be
separated. You can also get automatic restart of the windows service if the
single-threaded DLL crashes.

 

[P Chase]

Yes. I suggest you take your single thread and put it into a Windows
Service. It should not be in the web service at all. Communicate between the
web service and the Windows Service by using either .NET Remoting or by
using WCF (over a TCP-based channel).

This should actually simplify the testing, as the two concerns will be
separated. You can also get automatic restart of the windows service if the
single-threaded DLL crashes.

Thanks for this.

I guess being a .Net Web Service is quite a restrictive role.

I can see that moving the DLL's functionality into a separate process
is probably the right thing to do, if retaining the Web Service idea.
However, I am concerned about performance, as the size of data to pass
to and from the DLL is large.

As we don't really need to deliver our service as a Web Service (it
just seemed like a convenient and buzzword-compliant delivery
vehicle), perhaps I'll reconsider. Perhaps I will just write an
ordinary application, and receive data over sockets in a low-level way.