What should be the role of web services in a web site?

Question

I'm building a web site which includes a control that will use a LOT of data. So I thought of doing that through web-service, in order to improve scalabality- that way I'll be able to use a different server for this purpose.
Is this a good idea? If so, where does it stops? Why not have web-services all around, and a very "thin" web site? What are the pros. and cons. of that?
Am I not getting the purpose of web services?

Answer 1

My understanding is that the main purpose of web services is their ability to be able to expose application functionality to external applications in a loosely coupled manner.

In order to improve scalability, what is usually important is the layered approach in your application -wherein your layers can be independantly scaled up / out depending on the needs. Now, yes, it is very possible that from an implementation perspective, you could implement this layer as a web service but that is hardly the performant option.

If external integration is not a requirement, you are usually much better off using faster means of communication across layers like TCP / named pipes . If you are on .NET platform and using WCF to create your services, then TCP / MSMQ / Named Pipes are options that are considered more performant than regular web services (HTTP). In previous versions of .NET, it was common to use .NET remoting to communicate across layers as well as that too was much more performant than web services.

As to having web services all around, there is a cost associated with them and thats performance so you dont want them around except in places where you will really benefit from having them. In most cases, exposing the business logic to external applications via a Service Layer on top of your business layer - is usually one of the common places to have services.

Answer 2

Rich Internet/Intranet Applications, running in the browser, with nice presentation widgets are pretty commonplace today. Most serious companies I deal with at the very least want some degree of RIA in their Web presence.

So, AJAX, Flash etc. are very widely used. Such apps need to get the data they are displaying from somewhere and typically this is a an background (asynchronous being a term often used) service call. Often that a REST service call, but it can also be a traditional WSDL-based service call too.

So I'd say:

1. The logical Separation of presentation logic and business logic is a good thing.
2. In the RIA case it's perfectly natural to separate the business logic to a different tier than the presentation, when the latter is in the Browser.
3. The scalability argument you make is then one liekly benefit of this architecture. In the JEE world App Servers do this kind of scaling quite naturally.
4. In cases where the presentation login is running in the same tier as the business logic you may find that the serialisation costs of Web Services are quite noticable and hence you may prefer to use simple procedure calls instead.