I am using TcpListener (Clase) example https://msdn.microsoft.com/es-es/library/system.net.sockets.tcplistener(v=vs.110).aspx in order to process TCP requests.
But It seems like at the same time this TCP Listener is gonna accept multiple requests that should be processed later in a couple of Web Services together and result must be returned to the TCP client.
I am thinking to do following:
Get a stream object for reading and writing NetworkStream stream = client.GetStream(); and save it in special container class.
Put this class to special Queue helper class like this one C#: Triggering an Event when an object is added to a Queue.
When Queue is changed fire implemented event to process the next queue item asynchronously using Task.
Within a Task communicate with Web Services, and send the response to TCP Client.
Please, let me know this architecture is vital and able to resolve the multiple requests to TCP Listener.
Using queue is definetly viable idea, but consider what purpose it serves. It limits how many requests you can process in parallel. You may need to limit that in several cases, and most usual is if each request processing performs CPU-bound work (heavy computations). Then your ability to process a lot of them in parallel is limited, and you may to use queue approach.
In your request processing performs IO-bound work (waiting of web request to complete). This does not consume much server resources, and you can process a lot of such requests in parallel, so most likely in your case no queue is needed.
Even if you use queue, it's very rarely useful to process just one item at a time. Instead, process queue with X threads (where X again depends on if work is CPU or IO bound, for CPU you might be fine with X = number of cores, with IO you need more). If you use too few threads to process your queue - your clients will wait more for basically nothing, and can even fail by timeout.