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:
with server and clients authenticated.
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
request or send files, mainly between 1 and 5 mb).
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:
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
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).
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.
REST/HTTP. While REST might be perfect for serving files, a richer
interface is needed for some of the other functions.
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.
Using your own protocol is not future proof, as you are the only one that can support it. It is also a lot more work than is necessary.
WCF is a tried and true framework that is very capable for almost any service need you may have. You can create a single service (class / interface) and expose it in different ways depending on your requirements, meaning the same service can be an Https external endpoint for external clients, tcp.net internal endpoint, and a REST endpoint all at the same time with just some additional configurations.
WCF has been around for a long time, and it is not going anywhere. On top of that there is tons of support / information on it around the net.
Pure TCP has more disadvantages: you probably need to create your own host. What about redeployments? Need to shutdown first and have downtime.
In my view the next step for you would be to test WCF configurations and find out if you can make the latency go down. Clearly, 100s of milliseconds cannot be "normal". With connection pooling I'd expect the usual network latency plus a small amount of CPU time to process the request. Probably < 1ms.
If you can make WCF work all other points become moot because WCF is clearly the best choice besides performance requirements.
Forget Webservices, they are too slow.
I would use my own protocol on top of UDP or TCP. It's fast, leightweight and easy to extend. You just have to document your protocol well. Socket communication is a standard!
WCF I've never used.