
January 28th, 2013, 07:59 PM
|
 |
Lost in code
|
|
|
|
|
A "web service" has no precise technical meaning beyond being something that is accessed over the internet, although it tends to be more commonly used to describe a service that is accessed over HTTP as opposed to a service that uses a long-lasting socket connection with a custom protocol. You could write a web service in ASP if you wanted.
There are no inherent security differences between any type of web service. The service will be secure as you program it to be, regardless of which language it is written in or what communication architecture you use to build it.
Whether an HTTP-based web service or a long-lasting socket based web service is more effective depends on the application.
If the application communicates infrequently with the server, then an HTTP-based web service will be able to handle more users. For example, if your application has 600 users who, on average, send 1 request per minute, then an HTTP server needs to be able to handle 10 requests per second. However, a long-lasting socket based web service would need to be able to handle 600 active connections at once. So in this case, an HTTP-based service is more efficient.
However, if your application involves 600 users sending 1 request per second, then your HTTP server would need to handle 600 requests per second. In this case, it would be more efficient to use a long-lasting socket based service.
Sending a message over an HTTP request has a much higher per-request load cost than sending a message over an existing socket. So, a long-lasting socket based service will normally have lower latency for communication. However, when the connection is not in use you still have to maintain it, unlike an HTTP connection. A long-lasting socket type application is often more expensive to build, deploy, test and maintain.
|