A Web Service inside a Webpage

Ok take this example... you are on an internet site booking your travel arrangements or ordering the latest Harry Potter novel. The site takes you through a sequence of one internet page after another to get the job done. Why?

Because that's the way it is normally done? Because everyone loves it like that? Nah!

It is because to send information to the server the current web page must sadly die. Happily though, the server (usually) receives the information from the dead page that you sent. It can then process your information... check the hotel room you are requesting is available for example. In response it must build a completely new web page for you, but hey its just forgotten what the previous one looked like. The previous one might have held a list of twenty alternative hotel rooms that you were interested in. Sometimes it tries to rebuild something looking like the previous page - so you don't notice the difference. But this is loads of work for it, especially considering it is potentially having to do this for 1000s of people at the same time. More often than not you get a completely new looking page, and if you want the previous page again you have to press the back button which, by the way, sometimes fails. (Note, the reason for all this lies with the stateless nature of the HTTP protocol and the way Html forms work, but we will not go in to that here).

This often adds up to a disjointed and sometimes frustrating experience. People have come to accept it though, because this is the way the web works, right? Think again: would you be happy if after every time you pressed a calculation button in your Spreadsheet the whole page disappeared only to be redrawn differently 10 seconds later with some of the previous information missing?

That is why this model is so cool... full page refreshes are not required. And this means we can build interactive web pages that look and feel like desktop applications.

• No full page refresh is required
• We can build an entire Internet Application that looks like a desktop application (with a richly interactive user interface), except running in a browser. This means our rich web application has a global audience without a single distribution or installation cost
• The server does not have to try to remember loads of things (client state) that it should not need to = better performance = quicker response for the user
• The server does not need to serve so many full web pages = better performance
• Less data transfer over the line = better performance
• Architects / developers are freed from a large part of the burden of client state management, thus allowing them to concentrate on more important business functionality


• Reduced complexity leads to lower project and maintenance costs
• The same web services used for the Browser interface can be reused - perhaps in a regular thick client interface (i.e. we can call the same methods from a C++ program for example - calling a web service should be language independent !)

Well it is only working here in IE5+... the client side technology makes heavy use of Dynamic HTML and Javascript. The support for this varies from Browser to Browser. Certainly, we have got more chance of getting bitten by a dinosaur than getting this working on an older Browser or Web TV!

We must pay close attention to security issues using this model... functions that would have been otherwise securely hidden on the server might be exposed.

The other side of the coin from not working on the server is that we have to do more work on the client - in the browser in this case. This can lead to large and complex DHTML Javascript files (Nb. certain techniques can alleviate this - use of XML with XSLT for example). At the extreme we might be tempted to put important business logic code down on the browser because this is where our state information exists. This is often a bad idea!

In conclusion, the "Web Service inside a Webpage" model can offer huge benefits. But as with any particular technique we must weigh its merits with its relevance to the requirement. If a richly interactive user interface is required then this model is certainly a good option. But if a wider browser audience is necessary then there are many alternatives still available to us.. some more traditional, some not, such as Microsoft ASP.NET web forms!