Strategies for Web Service to Unmanaged DLL

D

David Palau

We have a C#, .NET 1.1 web service that will be interacting with a
third-party, unmanaged DLL.

The idea is that this web service will be called with certain
parameters from within our intranet, passing along these parameters to
a function ( DoSomething() ) in this third-party DLL which will return
back to us a double number which we will return from our web service.
This web service method will be hit ~2500 times per day.

However, in order to interact with this third-party DLL, we need to
start it up so to speak. Basically this means that we need to notify
this third-party DLL that we will be interacting with it through an
initialization function ( Open() ). This Open() call will return to us
a unique integer number to use in any subsequent calls to
DoSomething().

When we are finished calling DoSomething(), we need to notify it that
we are done with our requests and it can 'release' this unique
license number from being used (Close() ). If we attempt to call
Open() again before we call Close() we won't be given a new license
number to use.

Due to stability issues and the amount of resources it takes to call
the third-party DLL Open() and Close(), it was recommended to us by the
vendor of this DLL that we only call Open() once and then do as many
DoSomething() calls as we need to. Only doing a Close() call when we
need to shut everything down - which I guess only happens when we
have to reboot the web server or reset IIS completely or something.

Initially we were storing our 'license' number as a static variable
in a static class in a separate assembly referenced by our web service
and calling Open() on the DLL during the Application_Start event in
Global.asax and calling Close() during the Application_End event. Our
actual DLLImport references were also in this static class.

However, due to when IIS recycles the worker process, which obviously
gets rid of the static variable, and I guess 'unloads' the third-party
DLL, the Application_End event wasn't being called in the normal
process of the recycle (at least it wasn't before a new
Application_Start would fire off). This would result in a failure when
we tried Open() or DoSomething() again.

So we need to come up with a new way to make sure we handle the Open()
and Close() calls intelligently. Do these ideas make any sense:

1. Totally disable the IIS recycling feature in the application pool we
are using in IIS so theoretically the process will never recycle,
always leaving that static variable and reference to the DLL around.

2. Putting the interaction of the third-party DLL in some sort of
windows service for the web service to interact with. We don't allow
anonymous access to this web service and use Basic authentication using
SSL so we should be able to impersonate the caller or set up some
service account that we can grant access to reference this windows
service. This way this windows service can be around at web server
startup and it can manage the Open()/Close()/DoSomething() calls. How
do you interact with a .Net managed windows service from a web service?

3. Something else???


Sorry for the long post, but if anyone has any leads, it would be
greatly appreciated.

Thanks,

-David
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,764
Messages
2,569,567
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top