Careful with Web Services in ASP.NET AJAX
I've never been a quick learner student since high-school. It always took me time to figure out things, tell pros and cons apart of any technology or topic. So when ASP.NET introduced Web services -- sure MS didn't invent Web services, but I'm not sure it would have been the same had ASP.NET not fully supported Web services <g> -- I promptly picked it up the wrong way. For quite some time, I perceived Web services as a smart way of building BLL and make it remote with no significant effort on my own.
Then friends and colleagues explained the right way to look at a Web service. Can you see the "service" in it? Is there any "service" in it? Web is just the transportation layer. Oh cool... thank you.
So what about ASMX Web services in ASP.NET AJAX?
They're ASP.NET Web services, although local to the same hosting application. And they seem to suggest they're a way for you to call into the back-end of the application. Yep, just your BLL.
From an AJAX perspective, ASMX Web services are to be a simple facade to route calls to proper BLL after a proper filtering. It is worth noting, in fact, that AJAX Web services have no security layer around. And any security layer you might want to consider would make AJAX apps complex and cumbersome and anyway sending packets via clear text unless HTTPS is used.
AJAX applications using ASMX web services should consider the following:
- Use ASMX as a facade pointing to the real BLL -- the critical part of it at least -- only after due checks or through a weak account.
- Use ASMX to point to UI-level BLL -- that is, the security neutral part of it. For example, methods that return products catalog but not methods that verify credit card or start checkout procedures
- Do not use ASMX for security critical postbacks, but resort to UpdatePanel controls
There's more, though, about ASMX in ASP.NET AJAX applications.