We are extending an existing application (.NET with SQL Server) with a server component. This component plays two roles: it performs background tasks (long running calculations, and cron job like tasks), and it acts as an application server by providing an API to applications running on the local network.
The question is: which technologies (within the .NET world) to use to implement the application server bit. The requirements are as follows:
- Should be easy to install, with only few dependencies.
- All communication with the server should be reliable, encrypted, with server and clients authenticated.
- Throughput is less important than response time (< 100 calls per second), each request should be answered without delay (like when querying sql server with SELECT 1 over a TCP connection); I guess that means as little overhead as possible by the technology that sends/receives requests.
- Many calls will have a heavy binary payload (basically clients request or send files, mainly between 1 and 5 mb).
- Be extensible and future proof.
- Have the ability to make the API “public” at some point in the future, so that it can be used by third party applications (SOA-style) without the need for adding yet another server component (and opening yet another port in the firewall).
Actually the biggest task (at the moment) for this application server is to serve files, and allow uploading revisions of these files.
I spent a considerable amount of time looking around the net and came up with the following list of possible approaches/technologies:
- Pure TCP with own protocol on top. (Going this way is the knee-jerk reaction in my case.) Advantages: future-proof, flexible, efficient, SSL is moderately easy to add (described here), connection-oriented (that is, open a TCP socket when application starts, close it when application ends, SSL handshake and authentication are only performed once). Drawbacks: nothing standard with which a third party could easily integrate, primitive development model.
- ASMX Webservice. Advantages: standard interface based on WSDL/Soap, SSL is easy to add, code generation hides messy implementation details. Drawbacks: not future proof, only SOAP over HTTP, not efficient for file transfers (base64 in XML), requires IIS for hosting (thus not easy to install).
- Windows Communication Foundation (WCF). Advantages: many supported bindings (some of which are open standards like WSDL/Soap), possibility to expose several interfaces concurrently, SSL is easy to add, code generation, can be hosted in any .NET process (thus easy to install), using NetTcpBinding WCF appears to be very efficient (although completely unusable by a third-party). Drawbacks: learning curve.
- ASP.NET Web Api. Drawbacks: requires IIS for hosting, only REST/HTTP. While REST might be perfect for serving files, a richer interface is needed for some of the other functions.
- .NET Remoting. Superseded by WCF.
Based on this, it appears as if WCF were the way to go.
Question 1: Am I missing some important technologies/drawbacks/advantages in the above list?
Question 2: Would those with expertise in the area agree that WCF is the way to accomplish said requirements?
Question 3: What about efficiency in WCF? Seeing questions such as this one makes me wonder whether not being connection-oriented won't be a performance issue. The post describes how response times increase to the order of hundreds of milliseconds after some time of inactivity. Moreover, creating an SSL handshake for each and every request appears to be very inefficient.