
Signature
--------------------------------------------------------------------------------
John Saunders | MVP - Windows Server System - Connected System Developer
On 2 Apr, 21:28, "John Saunders [MVP]" <john.saunders at trizetto.com>
wrote:
> > I am new to .Net Web Services, having done similar stuff in Java
> > before.
[quoted text clipped - 18 lines]
> --------------------------------------------------------------------------------
> John Saunders | MVP - Windows Server System - Connected System Developer
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] - 03 Apr 2008 13:16 GMT
> On 2 Apr, 21:28, "John Saunders [MVP]" <john.saunders at trizetto.com>
> wrote:
[quoted text clipped - 44 lines]
>
> 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.

Signature
--------------------------------------------------------------------------------
John Saunders | MVP - Windows Server System - Connected System Developer
P Chase - 03 Apr 2008 13:50 GMT
On 3 Apr, 13:16, "John Saunders [MVP]" <john.saunders at trizetto.com>
wrote:
> > On 2 Apr, 21:28, "John Saunders [MVP]" <john.saunders at trizetto.com>
> > wrote:
[quoted text clipped - 59 lines]
> --------------------------------------------------------------------------------
> John Saunders | MVP - Windows Server System - Connected System Developer
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.