Consumer vs. Provider

Back Draft

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 looselyassociated 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 Webapplications to work at all. Elegance and extensibility were luxuries that wereally couldn t afford. Frankly, they just weren t possible at the time withCGI scripting.

Shortly thereafter, the first generation of Active ServerPages (ASP) emerged. We now had an easy way to program Web sites, but it wasstill mostly procedural in nature, with a few include files and COM objectsthrown in to give us some minute semblance of application design. The realaction didn t come in until ASP.NET came into focus in 2000, when Webapplications became event-driven like client Windows applications.

Because Web development is so much easier using ASP.NET, Webdevelopers have finally been able to begin leveraging design patterns to maketheir Web applications more powerful, extensible, and reusable. Two suchpatterns that have emerged are the Consumer Model and the Provider Model. Bothpatterns stem from the recent trend across all software development channels tocreate a Service Oriented Architecture, or SOA (http://msdn.microsoft.com/architecture/soa/default.aspx).Basically, SOA calls for the creation of mutually exclusive components thatprovide services that other components and applications can subscribe to andconsume. As with any network, the utility of SOA increases exponentially withthe addition of each new service.

There are a couple of different angles by which you canapproach SOA, though. The Consumer Model has gained a lot of attention latelybecause it is usually implemented via Web services. The idea behind theConsumer Model is that you build an application that interfaces with the worldthrough a series of Web services. Any number of third-parties can then buildapplications (e.g., consumers) that interact with your application through yourapplication s Web services interface, as long as they adhere to the interfacecontract.

The power behind this approach to SOA is that the consumercan be anything from a Smart Client application to a Compact Frameworkapplication to an ASP.NET application to another Web services interface to acompletely non-Microsoft platform (because Web services use platform-agnosticXML data to transfer information). In the Consumer Model, the informationproducer is locked and the consumer is dynamic. A good example of the ConsumerModel 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. Instark contrast to the Consumer Model, the Provider Model calls for the creationof a common user interface that can consume data from any number of differentsources (e.g., providers). The key is that each data provider must adhere to aninterface that is established by the consumer. As long as that contract iskept, the consumer does not care where the data it consumes is coming from, norwhere the data it submits goes.

The Provider Model is being used quite effectively inASP.NET v1.1 by the DotNetNuke portal application (http://www.dotnetnuke.com). Although nota new design pattern in general, Microsoft has recently codified the usage ofthe Provider Model in ASP.NET v2.0. The ASP.NET team has created a suite of Webcontrols that can consume a set of built-in data providers to giveout-of-the-box Provider Model support for common Web application features likeMembership, Role Management, and Personalization. You can create your own dataproviders to consume these Web controls as well, so you can avoid having toreinvent the wheel if your data source isn t on the list of out-of-the-boxproviders (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp02182004.asp).

In an ideal development world, the Consumer Model and theProvider Model could peacefully coexist. In fact, they would work together tocreate an almost infinite combination of data source and data consumer options fromwhich to choose. The sticking point, of course, is who creates the interfacecontract. In the Consumer Model, the provider sets the interface contract. Inthe Provider Model, the consumer sets the interface contract. As timeprogresses, though, the creators of both providers and consumers will realizethe power they can unleash by working together. I urge you to try both theConsumer Model and Provider Model design patterns in your Web applications andsee in what new directions they take you.

Jonathan Goodyearis president of ASPSoft (http://www.aspsoft.com),an Internet consulting firm based in Orlando, FL. Jonathan is MicrosoftRegional Director for Florida, aMicrosoft Certified Solution Developer (MCSD), and author of Debugging ASP.NET (New Riders). Jonathan alsois a contributing editor for asp.netPRO.E-mail him at mailto:[email protected] orthrough his angryCoder eZine at http://www.angryCoder.com.