W7 gets raves for a great user experience features and improvements. Many of the consumers I’ve spoken to love the W7 Task Bar and some of the new desktop arrangement features like Snap and Shake, but some of the really important enterprise capabilities like Federated Search and DirectAccess have been somewhat overlooked. I want to focus on Federated Search here so I’ll save DirectAccess for another day.

Searching is a key component of daily activity in most enterprises. Although we tend to take it for granted, information workers need to have a lot more savvy to find what they are looking for than they are given credit for. Here’s why. Information is all over the place. It lives in documents in a dozen different repositories—if you’re lucky—if not, a dozen different file shares.  Sometimes the information sought lives on the local desktop file system or any one of half a dozen different company databases. Sometimes it’s in email and, of course, sometimes it can only be found in some remote reach of the internet. But, hey, that’s only part of the story. In addition to knowing where to look, they have to know how to look? Each location may require knowing a different search dialect. In each place they search, they have to know whether two search terms get and-ed or or-ed. They half to know whether stem searching is automatic or whether wildcards are needed—and which ones!

Anything that makes searching easier for these information warriors typically translates into direct cost saving and better productivity. That’s where Federated Search can make a positive impact on the bottom line.  If you take a look at the user experience of this built-in Windows 7 capability, it’s very natural, immediately accessible and easy to use. Just click start and type in your search. If you live near Boston (like I do) or you are a conspiracy buff and you type in ‘JFK’ the results might look like this:


So far, this is just an ordinary desktop search but there are a couple of things worth noting about this. First, if I haven’t found what I’m looking for, I can extend the scope of my search using any of the federated search connectors that W7 knows about. For example, I could extend my search to the Internet by clicking on the Bing Search connector. If I do that the results look something like this:


The search results are returned directly to the W7 Explorer window and the search context is preserved. At this point, you can do anything with the federated search results that you would do with an ordinary desktop search. For instance, you can save the exact search itself. You can also search other scopes with other connectors just by clicking. (You could also search with other browsers or internet search engines, but who would want to?) In my case, for example, I could search across the Microsoft intranet using the custom connector labeled MSW Intranet or narrow my search to internal IT information using the ITWeb provider.  Both of these latter are custom federated search connectors created by MSIT to make it easier to wade thru intranet information which is—quite frankly—all over the place.

Secondly, no matter which search I decide to do next, all I have to do is click it. W7 saves my search terms and automatically forwards them to whatever connector I click on. Without this, I would have to first copy my search terms to the clipboard, load the browser and the appropriate web page, and then paste it into the search control before I finally clicked ‘Search’. Millions of people use this second approach all day long, wasting precious time and productivity. With a robust collection of search connectors, a single search can be fluidly diverted from one information source to another until you find what you are looking for.

Good News for Developers

Federated search in W7 is actually based upon an open standard called OpenSearch 1.1. So, in addition to being easily integrated with W7, custom search connectors are extremely easy to build and deploy. At their simplest, a custom search provider can be constructed with nothing more than a single XML file called an OpenSearch Description File (.osdx). In the simplest form, the connector points to an OpenSearch web service. At first this sounds like a big deal until you realize that the OpenSearch standard only requires that the web service results are in RSS or Atom format and have basic elements like title, link and description. OpenSearch providers may be more readily available than you think. Sharepoint can be used as a provider, making federated search is a great way to seamlessly integrate Sharepoint information and searching directly into the W7 desktop.

The OpenSearch standard is flexible enough to allow for custom elements in search results too.  It’s also complete enough to put a little polish on large result sets with nicely formatted and reasonably sized pages. So if you already have web services that comply, all you need is the connector.

On the other hand, OpenSearch can also be leveraged to do some more sophisticated searching (with some assembly required on your part). Let’s say, for example, that your company has a database that contains valuable profile information for employees and you want to make this information more easily accessible for everyone. In .NET, you could build a WCF service and a LINQ query that execute the search and convert to Atom or RSS format in about 15 lines of code. Then all you need is your Connector and you’ve integrated this search provider directly to the W7 desktop. Connectors can be deployed from a web page link, a file share or an email attachment,  so there’s not much muss or fuss there either.

If you want to know more about the details and basic guidelines, a great place to start is the Windows 7 Federated Search Provider Implementer’s Guide. Despite the title, it covers connectors as well as providers.

Security Qualms?

While we are on the subject, some have implied or expressed vague security concerns about Federated Search, which are probably a bit overblown. In general I take security very seriously but before queasiness sends you running for the air-sickness bag or your network security officer starts to freak out, here are a few things to consider.

There isn’t anything about a search connector that subverts standard network security measures. Even if the provider is on the Internet, results will still arrive at the firewall over http/s—we’re talking standard port 80/443 stuff here. In that respect, a federated search is comparable to standard browsing or an RSS feed.

The connector itself is not an executable; it’s a standard XML file so now worries there. In fact, there are no provisions in OpenSearch for any type “add-ons” so in this respect it is arguably safer than browsing.

Having a custom connector on the W7 desktop doesn’t mean you have to forgo standard authentication mechanisms either. W7 federated search providers can support NTLM, Kerberos, and Basic (over https) authentication machinery, plus any custom (SSPI compliant) Security Support Providers.

So relax, have fun, and make searching a little easier for the information warriors in your organization. They might even thank you for it.