Usage of Socket programming in Webservice

Question

We have a requirement to develop a reusable service(webservice) that need to be consumed by our Hetrogenous clients running in .Net and Foxpro(webservice will be an idle candidate to use in foxpro).

The functionality of our webservice is going to be:
1) Getting input data from clients
2) Build a stream of data with the input data
3) Open a client Socket connection and transmit the data stream to a server(to a predefined ip and port)where a mainframe application will be running as listener program to recieve and and process the data.
4) After processing it returns a response back as stream of data.
5) Recieve the response and return it to client apps
6) The socket will be opened for a maximum of 45 seconds to send and recieve the response. If not the webservice will automatically close the socket and return a failure message to clients.

To accomplish the above Webservice requirement. Please advice me with an optimized way of writing a service in .net. My doubts are
1) Is it a good approach to write webservice that implements socket programming?
2) Do we face any threading issues when the service is holding a dedicated thread(for each call) up to 45 seconds max.
3) This webservice is going to be running in our middle tier server cluster(4 servers). This server cluster is going to host multiple middle tier components. So we are concerned about the resource utlization also


Please give you valuble inputs...thanks

 
 

Answer 1

1.) Using Sockets behind the scenes in a web service is a perfectly fine approach.

2.) Yes - it limits your scalability significantly (1000 users = 1000 threads = yikes).  Instead of using the synchronous (Send, Receive, etc) methods, which tie up a thread for the duration of the operation, you should use the asynchronous equivalents (Begin* or *Async).  This lets you service a large number of clients simultaneously with a relatively small number of threads.

3.) Some things to think about with respect to resource utilization:

      - If the data returned from the backend server is large, don't hold it all in memory on the middle-tier server.  Use a smaller buffer to receive multiple times and send them immediately to the client as they arrive.

      - Reuse buffers whenever possible rather than creating new ones.  Sending or Receiving multiple times using the same buffer (but with different contents) uses less memory AND is faster than using multiple buffers.

      - If you have clients hitting the middle-tier servers pretty often, that will result in a lot of socket connections being opened and very quickly closed.  It might be more efficient to have a smaller number of socket connections that are left open for a longer time and shared between multiple requests (if your backend server can support this).


-dave