What is a "web service"?

I was recently asked a question at work about an application, EQuIS Professional, that uses TCP/IP to connect to Microsoft SQL Server (aka ADO.NET Sql Provider). The answer was somewhat lengthy, but may be useful for some discussions:

That is a great question. The answer to that question can be somewhat technical, and may vary depending on the context of the question. The term "web service" or "web service interface" can be defined in a variety of ways. Most definitions include the transfer of data between the client and the server. Often the term "web" implies HTTP (Hyper Text Transfer Protocol). One way of defining "web service" is a service that facilitates the transfer of data, typically in some text-based representation (e.g. XML or JSON), over the Internet via the HTTP protocol. The main benefit of sending the data in a text-based representation is to allow application integration. For example, text-based representation of data allows communication between a client application developed separately from and independent of the server application. Converting the data to/from the text-based representation incurs processing overhead; but that overhead may be a worthwhile cost for this type of web service.

When it comes to security, HTTP is no more secure than any other protocol. In fact, running a web service directly over HTTP would be very insecure (and not recommended). The security of a web service typically comes from SSL (Secure Sockets Layer). Using HTTP with SSL (i.e. HTTPS) is secure because all of the packets sent over the Internet are encrypted with SSL. That is why all secure websites use HTTPS; you would not, for example, want to use an online banking site that uses HTTP.

All network communications happen over a given port. There are "standard" ports used for specific protocols. For HTTP, the standard port is 80. For HTTPS, the standard port is 443. One reason that HTTPS-based web services are popular is because port 443 is typically already open in most firewalls; so using HTTPS does not require any additional firewall configuration. So an HTTPS-based web service takes advantage of the already open port. For a generic web service designed to facilitate the transfer of data between disparate systems, HTTPS is typically the best choice.

However when both the client and the server are designed to work together (e.g. EQuIS Professional and SQL Server), a text-based representation of the data is inefficient. HTTP is built on top of TCP/IP, and it is more efficient to transfer the data in well-defined binary representation that is known by both the client and the server. This type of communication is typically done directly over TCP/IP (without the additional HTTP layer). At this lower level, a "web service" may be a service that facilitates the transfer of data (in some mutually agreed binary representation) over the Internet via TCP/IP.

While transferring the data in binary form over TCP/IP is more secure than HTTP, it is still not inherently secure. So a web service using TCP/IP should still be encrypted with SSL. Microsoft SQL Server natively supports SSL encryption for all cient/server communications. When SQL Server acts as a web service using TCP/IP via forced SSL encryption, the communication is essentially as secure, and more efficient than, an HTTPS web service.

Because TCP/IP is lower in the network stack than HTTP/HTTPS, it does not have a "standard" port. Many different network protocols run over TCP/IP on different ports. When configuring SQL Server as an SSL-encrypted web service, it is important to consider the port that will be used. The default port for SQL Server is 1433. However, that is not the best choice for an Internet-facing instance of SQL Server (even if it is SSL-encrypted). One option is to use port 443, for the same reasons that an HTTPS-based web service uses port 443. Since most firewalls already have port 443 open, it greatly reduces the potential firewall related issues when establishing connections. Having SQL Server listen to port 443 on a public facing IP address is not much different than having IIS (aka HTTPS server) listen on port 443 on a public facing IP address. Another option is to have the public facing machine (or the firewall) use port forwarding from the public IP/port to the internal IP/port.

Given this background (I apologize if I have provided too much detail), let me answer your original question. If your question is "Can EQuIS Pro consume an HTTPS-based web service?", the answer is "not easily".  It would require a fair amount of implementation and testing to make something like that work, and the performance would likely degrade. Also, using HTTPS does not actually remove the dependency on TCP/IP ... it simply wraps TCP/IP in HTTP and in SSL (two additional layers) and runs it on a known port (port 443).


However, if your question is "Can EQuIS Pro (running externally) make a secure connection without requiring additional open firewall ports?", then the answer is "yes". By configuring SQL Server to force SSL encryption and to listen on port 443 (either directly or via port forwarding), you can achieve the same benefits of an HTTPS-based web service.