Data Source Agnosticism using the Business Data Catalog

There are a couple of main connection options that are available when using the Business Data Catalog (BDC) to access your non-SharePoint applications: a direct connection to databases, or to web services. The latter option is intriguing because we can couple it with some new .NET 2.0 functionality to add some real flexibility to our system.

While it may be tempting to hook the BDC straight up to a database, using a web service provides us with far more options. To begin with, the web service can just be populated with dummy data to get it up and running. Doing the same thing with a database would involve creating lots of tables and columns, making sure the contraints and other database objects are appropriate and functional, and then populating the dummy data either by hand (a potentially painful task) or by some code (which may or may not exist). Even if the database is already set up, connecting to the web service provides us with far more flexibility and even “future-proofing”.

For one thing, the web service guarantees that as long as future versions of the BDC support SOAP, they can continue to connect for years to come. This may or may not be true with databases (although it is hard to imagine SQL Server support being dropped!). The web service also allows us to provide disconnected data and can even mash together other data sources before feeding the BDC.

Finally, using a web service introduces a potentially huge flexibility option. I’m talking about using the new Provider model to populate the web service which the BDC will call. What are some of the advantages of this, and how would you do it?

The obvious advantage is that while you currently support Oracle or SQL Server, you may wish to provide yourself with the flexibility of using an alternative data source. Data Source Agnosticism, while a noble goal, has always been problematic due to the complexity of writing and maintaining the code. New to .NET 2.0, the Provider model is essentially a combination of Abstract Factory pattern with an XML configuration file. The burden of writing agnostic code is vastly reduced. After your first attempt to create a custom provider, the number of places you will want to use Data Agnostic Code will blossom!

To begin with, creating a custom provider is not a lot more work than usual. You need to create a web application that will expose the web service. The code of the web service will call a custom provider that will return data in some format. The web service is likely to just expose this directly through its method stub, although it could do various interesting things, such as validation, caching, and even mashing up a variety of data sources into one resulting data set. The BDC will then call the web service using XML that you’ve written. I’ll try to put together a working example shortly.