Consumer vs. Provider
By Jonathan Goodyear
Back in 1997, Web development was really awful. The job of Web developer didn t really exist yet. Anybody who was even loosely associated with the World Wide Web was immediately referred to as a Webmaster. At any rate, as budding Web developers, our chief concern was getting our Web applications to work at all. Elegance and extensibility were luxuries that we really couldn t afford. Frankly, they just weren t possible at the time with CGI scripting.
Shortly thereafter, the first generation of Active Server Pages (ASP) emerged. We now had an easy way to program Web sites, but it was still mostly procedural in nature, with a few include files and COM objects thrown in to give us some minute semblance of application design. The real action didn t come in until ASP.NET came into focus in 2000, when Web applications became event-driven like client Windows applications.
Because Web development is so much easier using ASP.NET, Web developers have finally been able to begin leveraging design patterns to make their Web applications more powerful, extensible, and reusable. Two such patterns that have emerged are the Consumer Model and the Provider Model. Both patterns stem from the recent trend across all software development channels to create a Service Oriented Architecture, or SOA (http://msdn.microsoft.com/architecture/soa/default.aspx). Basically, SOA calls for the creation of mutually exclusive components that provide services that other components and applications can subscribe to and consume. As with any network, the utility of SOA increases exponentially with the addition of each new service.
There are a couple of different angles by which you can approach SOA, though. The Consumer Model has gained a lot of attention lately because it is usually implemented via Web services. The idea behind the Consumer Model is that you build an application that interfaces with the world through a series of Web services. Any number of third-parties can then build applications (e.g., consumers) that interact with your application through your application s Web services interface, as long as they adhere to the interface contract.
The power behind this approach to SOA is that the consumer can be anything from a Smart Client application to a Compact Framework application to an ASP.NET application to another Web services interface to a completely non-Microsoft platform (because Web services use platform-agnostic XML data to transfer information). In the Consumer Model, the information producer is locked and the consumer is dynamic. A good example of the Consumer Model is the Microsoft MapPoint Web service (http://www.microsoft.com/mappoint/products/webservice/default.mspx).
On the other side of the fence is the Provider Model. In stark contrast to the Consumer Model, the Provider Model calls for the creation of a common user interface that can consume data from any number of different sources (e.g., providers). The key is that each data provider must adhere to an interface that is established by the consumer. As long as that contract is kept, the consumer does not care where the data it consumes is coming from, nor where the data it submits goes.
The Provider Model is being used quite effectively in ASP.NET v1.1 by the DotNetNuke portal application (http://www.dotnetnuke.com). Although not a new design pattern in general, Microsoft has recently codified the usage of the Provider Model in ASP.NET v2.0. The ASP.NET team has created a suite of Web controls that can consume a set of built-in data providers to give out-of-the-box Provider Model support for common Web application features like Membership, Role Management, and Personalization. You can create your own data providers to consume these Web controls as well, so you can avoid having to reinvent the wheel if your data source isn t on the list of out-of-the-box providers (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp02182004.asp).
In an ideal development world, the Consumer Model and the Provider Model could peacefully coexist. In fact, they would work together to create an almost infinite combination of data source and data consumer options from which to choose. The sticking point, of course, is who creates the interface contract. In the Consumer Model, the provider sets the interface contract. In the Provider Model, the consumer sets the interface contract. As time progresses, though, the creators of both providers and consumers will realize the power they can unleash by working together. I urge you to try both the Consumer Model and Provider Model design patterns in your Web applications and see in what new directions they take you.
Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, a Microsoft Certified Solution Developer (MCSD), and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angryCoder.com.