I'm looking for some advice on how to proceed.
Here's the scenario:
I've got to develop a high availability VB.Net web service that basically
acts as a middle man between the web service clients and a third party data
provider. The third party data provider is accessed over a well defined TCP
interface. The third party data server can accept about 25 concurrent TCP
connections from the same client.
The web service will accept client requests, translate the requests into a
format suitable for the third party service, forward the request to the third
party service, wait for the replies from the third party service, translate
the replies into a format suitable for the web service client and return the
response to the web service client. This web service will need to handle
many simultaneous client requests.
Establishing a connection to the third party data service is a rather
lenghty process and I'm thinking the web service needs to maintain a number
of TCP connections in some kind of object pool. Also, the connections made
to the third party service need to be asynchronous, able to handle
unsolicited messages from the data server, maintain a heart beat requests,
identify broken or out of sync connections, and destroy itself and create a
new connection if a problem is identified.
A prototype version of the web service uses a public variable defined in a
VB module to hold the array of objects that maintain the connections to the
third party web service. After reviewing how ASP.Net manages the application
domain and its associated threading behavior, I'm concerned that it's
possible that ASP.Net may create multiple instances of the application and in
turn attempt to create even more new connections to the third party data
server exceeding the maximum allowable connections and causing all sorts of
problems.
If I create my own object pool using a singleton model, I have similar
concerns regarding ASP.Net's threading behavior.
If I use component services for object pooling, I'm concerned that I can't
properly manage object creation and destruction if there are problems
identified with the underlying TCP connection.
I'd really like some advice here on how to manage a pool of connections to
the third party data provider and how to manage the use of these objects
through a web service. Thanks
Jim Rand - 12 Apr 2005 23:10 GMT
Here is an idea for you which is a little out in "left field".
Our client had a third party VB DLL which produced a customized "widget".
They wanted to call this DLL from a web page to produce these widgets on
demand for subsequent download. They are in license compliance but here is
the kicker. The DLL required that it be part of a Windows form project. If
there was no form, nasty error messages were emitted from the DLL.
To get around this little dilemma, we created a Windows service project that
had a form which talked to the DLL. The DLL was happy. This project also
acted as a multi-threaded socket server listening for inbound requests from
other processes on the same machine.
From the ASP.NET page, we connected to the socket server, sent a request to
create a widget and waited for the response. Once the response came back, we
disconnected from the socket server and returned the widget to the outside
caller.
In your case, your Windows service could talk to your third part data
provider. Your ASP.Net page connects to your socket server. This way, you
can keep the ASP.NET threading behavior separate from your service.