Federated Search Overview

Article
07/24/2014

Microsoft Search Server 2008 provides two approaches for processing queries to return search results:

**Content crawling **In this approach, results are returned from the search server's content index based on the user's query. The content index contains content that is crawled by the search server, and includes text content and metadata for each content item. This is the same process that is described for Enterprise Search in Microsoft Office SharePoint Server. For more information, see Enterprise Search Architecture.
**Federated search **In this approach, you are enabled to display search results for additional content that is not crawled by your search server. With federation, the query can be performed over the local content index, or it can be forwarded to an external content repository where it is processed by that repository's search engine. The repository's search engine then returns the results to the search server. The search server formats and renders the results from the external repository within the same search results page as the results from search server's own content index.

This topic provides an overview of federated search in Search Server 2008.

Comparing Federated Search to Content Crawling in Search Server 2008

To help you decide whether to crawl a repository's content directly or by using federated search, you should consider the differences between the two approaches. You must determine which is most appropriate based on the content repository, and your requirements for the search results you want to return. There are advantages to both approaches.

Advantages of crawling content with Search Server

By querying the search server's content index for search results, you can do the following:

Sort results by relevance.
Control how frequently the content index is updated.
Specify what metadata is crawled.
Perform a single backup operation for crawled content.

Advantages of federating content with Search Server

By using federated search to return search results:

You require no additional capacity requirements for the content index, as content is not crawled by search server.
You can take advantage of a repository’s existing search engine. For example, you can federate to an Internet search engine to search the Web.
You can optimize the content repository's search engine for the repository's specific set of content, which might provide better search performance on the content set.
You can access repositories that are secured against crawls, but which can be accessed by search queries.

Federated Locations

A federated location defines the federated search connection to the external content repository, and is composed of the following:

Location type
Query and More Results link templates
Triggers
Display information
Restrictions
Authentication and credentials information

Location Type

Search Server 2008 supports the following types of federated locations:

**Local Search Index **SharePoint sites local to the search server.
**OpenSearch 1.0/1.1 **The RSS feed for any remote search server's results page, or any searchable feed that supports the OpenSearch standard, and returns search results in structured XML format (for example, RSS or Atom results).

You can federate to other repositories by building a lightweight interface that exposes the repository with a searchable XML feed. You can then create an OpenSearch location that connects to the lightweight interface. For more information about how to expose repositories as searchable XML feeds, see Architecture Guidance for Building Federated Search Connectors [Search Server 2008].

Query and More Results Link Templates

The query template contains the parameterized URL that points to the location’s Web interface, and contains the search query and any other parameters that are required by the search engine.

The query template is equivalent to the URL template in the OpenSearch specification, and the syntax is based on the OpenSearch URL Template Syntax.

The more results link template contains the URL for an HTML page that displays results for the federated search location.

Triggers

A trigger is a query constraint that determines when a query is passed. Only queries that match the pattern specified for the triggers in the location definition are forwarded to the federated location. Triggers are essential to the federation experience, as they ensure you display only information that is targeted to the user’s query.

There are three types of triggers:

**Always ** An Always trigger always forwards queries to the federated location. If you specify this trigger for the federated location, ensure that the location has enough bandwidth to handle the additional query traffic.
**Prefix ** A prefix trigger contains an exact term, with which the query must be prefixed for the location to match the query. For example, if "weather" is specified as the prefix trigger, then the query "weather New York, NY" will match but only "New York, NY" is forwarded to the federated location.
**Pattern ** A pattern trigger contains a specified regular expression pattern, which the query must match for the trigger to forward the query. To forward only a portion of the query to the federated source, you can create a capture group. The capture group can then be referenced in the query template. For more information on regular expressions and capture groups, see.NET Framework Regular Expressions.

Display Information

The display information specifies how display the search results that are returned, and includes the following:

The XSLT specifying how to format and render the search results XML
The list of properties to display in the search results UI

Note

Search Server retrieves all the properties returned for OpenSearch federated locations.
The sample data that is used to provide a preview of the Top Federated Results Web Part when it is edited in a Windows SharePoint Services 3.0-compatible editor

Restrictions

You can specify restrictions in the location definition to limit the sites that can use the federated location.

Authentication and Credentials Information

In the authentication and credentials information section of the location definition, you specify the authentication type for the federated location. The authentication type can be one of the following:

**Anonymous **No credentials are required to connect to the federated location.
Common Each connection uses the same set of credentials to connect to the federated location.
**Per-user **The credentials of the user who submitted the search query are used to connect to the federated location.

For the common and per-user authentication types, you must also specify one of the following authentication protocols:

Basic
Digest
NTLM Application Pool identity (common authentication type only)
NTLM
Kerberos (per user authentication type only)
Forms
Cookie

Note

If the federated location is configured for per-user authentication and the content repository for the location is on a remote server, you must either use Kerberos authentication or create custom versions of the federated search Web Parts. These custom versions must include UI elements to request the user's credentials so that they can be passed in the request to the federated location.

Federated Search Results UI

Search Server 2008 includes the following new Web Parts for displaying search results from federated locations.

Federated Results Web Part

This Web Part displays the results from a specified federated location. You can specify only one location in a Federated Results Web Part. By default there are two Federated Results Web Parts, one that displays related searches from Live Search, and the other that displays Live Search results.

Top Federated Results Web Part

This Web Part displays the results from the first federated location to return search results. You can configure multiple locations for the Web Part, in priority order. By default, there are no locations configured for this Web Part.

Customizing the Search Results UI

The search results for federated locations are returned to the search server as XML. The results are formatted and rendered based on the specified XSLT. This can be specified at the search service level, in the location definition configuration, or for a specific instance of the Web Part in the Web Part's properties. For information about modifying the XSLT to customize the search results view, see Enterprise Search Core Results XSLT Transformation.

Note

The XSLT for the federated search Web Parts and the Core Results Web Part, described in this article, differ. However, the approach for using the XSLT to customize how the search results are displayed is the same.

Federated Search Programmability

The Search Server 2008 object model is based on the Enterprise Search object model in Microsoft Office SharePoint Server 2007, with the addition of specific members in the search-related namespaces to serve federated search. For information about the Enterprise Search object model, see the following topics:

Query Object Model

Search Server 2008 does not provide programmatic access to search results from federated locations through the Query object model. For federated search results customization scenarios, you must create custom Web Parts that extend the federated search Web Parts.

Search Administration Object Model

The Microsoft.Office.Server.Search.Administration namespace includes the following new classes that you can use when programmatically creating and configuring federated locations:

LocationConfiguration
LocationConfigurationCollection
LocationType

Federated Search Web Part Object Model

The Microsoft.Office.Server.Search.WebControls namespace includes new classes for the federated search Web Parts.

Following are the base classes for the federated search Web Part classes:

SearchResultsBaseDatasource
SearchResultsBaseDatasourceView
SearchResultsBaseToolPart
SearchResultsBaseWebPart

Following are the classes that implement the Federated Search Results Web Part:

FederatedResultsDatasource
FederatedResultsDatasourceView
FederatedResultsWebPart

Following are the classes that implement the Top Federated Results Web Part:

TopFederatedResultsDatasource
TopFederatedResultsDatasourceView
TopFederatedResultsWebPart

You can extend these classes to create custom federated search Web Parts. As mentioned earlier in the "Authentication and Credentials Information" section, in any scenario where the federated location is located on a remote server, is configured for per-user authentication, and the authentication mode is not Kerberos, you must create custom federated search Web Parts that provide a user interface to request credentials from the user to pass to the federated location.

Share via