• Choose a category
• All
• Classic-Fiction

How would you build the HTTP façade?

The HTTP Façade

The HTTP façade is the list of public URLs known to, and managed by, the Ajax presentation layer. In an Ajax scenario, the presentation layer is made of only JavaScript code. All the logic you can’t or don’t want to code in JavaScript must be referenced on the server.

Public HTTP endpoints are the only point of contact between Ajax clients and server applications. You can write endpoints callable by Ajax clients using a number of technologies.

Note

In the context of Ajax, Web-hosted services are instrumental to the definition of a public, contract-based API that JavaScript code can invoke. It doesn’t mean that you can call just any public Web services from an Ajax client. More precisely, you can call only services that live in the same domain as the calling page in full respect of the Same Origin Policy (SOP) implemented by most browsers. This is a security measure, not a technical limitation. You should think of Web services as a sort of application-specific façade to expose some server-side logic to a JavaScript (or Silverlight) client.

To start off, an AJAX-callable endpoint can be an .asmx ASP.NET Web service. If this is your choice, you need to configure the server ASP.NET application so that its hosted Web services can accept JSON calls in addition to, or instead of, SOAP calls.

You can also use a Windows Communication Foundation (WCF) service to contain all the logic you want to expose to Ajax clients. As you’ll see later in the chapter, though, you get only the Web WCF programming interface and, as such, only a subset of the typical WCF features. In particular, the area of security is thinned down. A common solution for ASP.NET Web Forms Ajax-enabled applications is hosting WCF services and interacting with them via JSON payloads.

If you don’t want to add WCF to your application but still need a service, you can then opt for a custom, handmade HTTP handler. An HTTP handler is just a public URL exposed by a Web application, so it can reliably serve any purpose the presentation needs to address. Compared to WCF services, plain HTTP handlers lack a lot of facilities, including the automatic JSON serialization of input and output data. (You can use the same tools that WCF uses, but that’s just not…automatic.)

WCF Services

A WCF services is exposed as an .svc endpoint. To be invoked from within an ASP.NET Ajax page, a service must meet a number of requirements, the strictest of which relate to the location of the endpoint and underlying platform. Ajax-enabled services must be hosted in the same domain from which the call is made. If we consider using WCF services to back an Ajax front end, the service must be hosted in an Internet Information Services (IIS) application on the same Web server as the ASP.NET application.

Important

By default, AJAX-enabled WCF services run side by side with the ASP.NET application in the same AppDomain. Requests for an .svc resource are first dispatched to the ASP.NET runtime, but then the WCF hosting infrastructure intercepts these requests and routes them out of the HTTP pipeline. ASP.NET doesn’t participate in the processing of WCF requests past the PostAuthenticateRequest event in the request life cycle. At that point, in fact, the WCF infrastructure intercepts the request and starts processing that in total autonomy. In the default configuration, the WCF service method has no access to ASP.NET intrinsics, ASP.NET impersonation and URL authorization settings are ignored, and HTTP modules interested in filtering the WCF request past the PostAuthenticateRequest event never get a chance to do their work.

To support Ajax calls, you also need to expose service methods through HTTP requests and subsequently map methods to URLs. This is just what the WCF Web programming model has to offer. The WCF Web programming model enables services to support plain-old XML (POX) style messaging instead of SOAP, which is the key step to enabling