January 28th, 2013, 06:41 AM
Web Service vs ASP page
Thanks for reading. To date I have been using ASP server side pages to accept communication from my VB apps and also of late a couple of Mobile apps I have.
The ASP pages accept http / xml and do the processing, returning a response to the remote apps.
One of the mobile apps does use a web service that I set up, written in VB.Net
My question now relates specifically to the mobile apps and the expected increase in users. Specifically ;
a) response time
b) server load
What I would like to know is, taking into account the above 3 items, with the expectation of say 100,000 users devices, what is best for ;
i) minimal server load
ii) best response time
iii) best security
While I am reasonably technical I know very little about how a web service runs compared to an ASP page.
For example, is an instance of the web service loaded every time a user hits that service ?
and how does that compare to an ASP approach if say 300 requests come in at the same moment.
Appreciate any comments and thoughts,
January 28th, 2013, 08:59 PM
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.