WiredChurch.com allows churches to deliver key community management services to their members without having to install and maintain additional infrastructure. I used the .NET platform to implement this system when I worked as a consultant on this project. In this article, I’ll explain the details of one aspect of this project: designing and implementing the presentation layer.

.NET Case Study

This is the second installment in our look at a .NET-based Web services rollout. Click here if you missed the first article.

One of the key design goals of the WiredChurch system was to enable system users (the churches) to allow their customers to continue accessing their sites by using the same familiar URL of their church. We could have accomplished this by taking over the Web sites and moving them to a new set of centralized servers, but that would have put us in the Web hosting business rather than the Web services business.

The challenge was to design a system that would allow the actual presentation layer to run on distributed servers but deliver the data required to produce that presentation using Web services technology. Because of this decision, the system is inherently scalable at the front end. There is no single point of failure for the Web presentation layer. In fact, since most customers are using hosting services that employ multiple front-end servers using failover and round-robin DNS, we get the benefit of their existing hosts’ redundancy and scalability.

This architecture allowed us to focus on the next layer of the distributed architecture. Many architects use the term “business services layer” to describe the layer of service that sits behind the presentation services in a 3-tier system. But after years of system design, development, and research on Windows DNA 3-tier systems, Microsoft consultants have determined that in many systems, there’s actually a fourth layer that sits between the presentation layer and the business layer: the business façade.

The purpose of the business façade is to package the results returned by the business layer in a format more easily consumed by the presentation layer (Figure A). This allows the developers of business services layers to focus on implementing business rules in the most efficient way while not restricting their creativity. If properly designed, the business façade also enables the system implementation team to add more scalability by eliminating the bottlenecks caused by an overburdened set of business objects.

Figure A
WiredChurch logical architecture

Implementing the business façade
In the WiredChurch system, we chose to implement the business façade as a collection of XML Web services and ASP.NET user controls. Using these technologies allows us to meet two of our key design criteria: ease of implementation at the presentation layer and broad (potential) reach. By using XML Web services to implement the business façade, any downstream system that wants to consume our services can do so in one of two ways:

  • If they’re able to communicate with us only via HTTP, they can send us a URL with a request for the results of a business services function. The business façade returns an XML package that the sending system can parse and display on its Web site.
  • If the downstream Web server can communicate via SOAP, it can consume our XML Web services and then programmatically format pages for their customers.

The beauty of the XML Web services decision is that it allows downstream servers to use any combination of operating system and Web server software but still consume the services.

As we spoke with potential customers, they generally fell into two camps: those who had a paid development shop (or technical staff) who worked on their systems full-time and those who either did it themselves (administrative staff) or had volunteers who worked on their Web sites.

Interestingly, there was also a parallel distinction between those who used a variety of software from different vendors (paid developers) and those who used Microsoft software (FrontPage, Visual Interdev, and Internet Information Server) almost exclusively (unpaid or nontechnical staff). The vast majority fell into the latter category. We thought it was essential to give this second category a simple way to implement the presentation services layer. The ASP.NET user control turned out to be the best solution.

The ASP.NET user control encapsulates the XML Web services call and the resulting HTML display in a single object. User controls are not like ActiveX controls or Java applets; that is, they don’t require any runtime or JVM on the client machine. The user control uses the .NET Framework to render a page based on the capabilities of the incoming browser. (Obviously, this requires that the .NET Framework be loaded on the downstream Web server, but there’s no charge to install the Framework to either the ISP or the end customer.)

For example, the AddEvent user control allows the Web developer to drop a single control on a Web page and then accept information that defines a new event. If the downstream browser is only HTML 3.2 capable, the validation for the data entered takes place by making a round trip to the server. But if the browser is capable of executing client-side scripts, all of the validation takes place without a round trip. The beauty of this configuration from the standpoint of Web developers is they can configure the appearance of the control by manipulating properties but also place the control within a page that maintains the site’s own look and feel (Figure B).

Figure B
User controls make XML Web services calls to retrieve data but render for the client based on browser type.

Scalability requires stateless implementation
The business services, Web services (business façade), and user controls (presentation services) distribute the processing required to deliver a finished page to the final consumer—the person who browses the Web. At the intersection of each layer, the two sides communicate in a single, stateless call that returns a batch of data for processing. By implementing each layer in a loosely coupled, stateless fashion, we can scale the system easily by adding additional servers to the business services or business façade layer. Since each call to the business façade doesn’t require reconnection to a specific server, the Web services can be implemented using a round robin DNS or other technology (hardware load balancing, for example) that spreads the load between the servers providing the Web services.

You can have your cake and eat it too
.NET gave us one more key advantage. We were able to implement rich, Windows-based administration front ends for the churches we serve without requiring them to do anything except install the .NET Framework one time. How does this work? .NET enhances the Windows deployment model by allowing users to start a Windows application from a browser and then deliver the code dynamically to the browser cache. While the business façade delivers formatted Web pages to end users via the user control, it also serves the church administration users by supplying data to a set of Windows forms applications that consume the Web services. This double duty allows us to give a rich, drag-and-drop, highly usable system to the people who have to “live in the system” all day (Figure C).

Figure C
The same business façade Web services are consumed by both Web pages and Windows applications.

Wrap up
As developers, we achieve development scalability by reusing code and services wherever possible. We achieve runtime scalability at the presentation level by consuming services provided by the business façade in a stateless manner. The next article in this series will look at how the business services layer is designed to provide data to the business façade in a similar fashion.