asp.net webservice design/ component issue

[Evelyn]

I'm in the process of rewriting an ASP.net webservice.

This service exposes functionality provided by a resource intensive
COM component. The problem with the current implementation is that
the overhead associated with creating an instance of the component
each time the service is invoked is not trivial and results in an
unacceptable performance drain on the server.

My goal is to redesign this so that, one way or another, a single
instance of the component can remain resident in memory and handle all
incoming requests.

My initial idea is to design a wrapper component that could hold the
single instance of the beastly object and manage incoming requests
(though some sort of queuing mechanism). Even though I hope that the
performance of the web service will be improved by this approach, it
is not really a problem if it turns out the that the client needs to
wait (the problem is overall server resources, not performance of the
service in particular).

This is where my thought process breaks down. How would I set up my
wrapper class so that is available to the web service each time it is
invoked? Can this be done via the Application object?

Am I on the right track? Am I overlooking a more simple approach?

Any help would be appreciated.
Thanks.

Evelyn Wong

 

[Jan Tielens]

You could create a singleton in .NET Remoting. By doing so you can specify
the LeaseTime for that "shared instance" (= the time that object stays in
memory).

Here's a nice tutorial:
http://www.codeproject.com/csharp/DotNetRemotingBasicTutor.asp

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan

 

[Michael Pearson]

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.591 / Virus Database: 374 - Release Date: 2/17/2004

 

[Evelyn]

Thanks for the info. I've read the tutorial and plan to work through
the example.

I'd like to avoid deploying the remoting objects as web services
through IIS. This is primarily because my clients are from a variety
of languages/platforms (it is my understanding that even when using
SOAP over HTTP, a client of a remoting web service needs to be aware
to a certain extent of the remoting infrastructure).

This leads me to wonder: would it be reasonable for me to set up a
ASP.NET web service that in turn relies upon a singleton remoting
object to provide the functionality (i.e., handling the requests to
the resource intensive component)? Would this approach give me the
best of both worlds -- being able to use the benefits of .net remoting
to share a single object while at the same time insulating the client
from the details of remoting?

Also, could someone please explain briefly the negative impact of
using the Application state object to maintain an instance of my
component?

Thanks again, Jan for your timely and helpful response.

Evelyn Wong

 

[Jan Tielens]

Would this approach give me the

best of both worlds -- being able to use the benefits of .net remoting
to share a single object while at the same time insulating the client
from the details of remoting? Exactly!

Also, could someone please explain briefly the negative impact of
using the Application state object to maintain an instance of my
component?

By default web services are stateless (so you can't use the session). In my
opinion you should try to keep this like that. Also suppose your web server
(IIS) goes down, the session state will be lost forever (unless you put it
into sql server).

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan

 

[Evelyn]

Thanks again, Jan.

By default web services are stateless (so you can't use the session). In my
opinion you should try to keep this like that. Also suppose your web server
(IIS) goes down, the session state will be lost forever (unless you put it
into sql server).

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan