The Search Developer Story in SharePoint 2010 - Query Interfaces
SharePoint 2010 includes a number of features that make the platform easier to use for developers. An improved Visual Studio integration, the addition of LINQ to the SharePoint platform, sandboxing for deployment, and the new developer dashboard are just a few examples of how developing and deploying SharePoint solutions have become much easier.
As a member of the enterprise search development team that has worked to bring FAST Search into SharePoint 2010, I can tell you that a lot has also been done to benefit developers of search-based solutions. SharePoint 2010 Search and the new FAST Search for SharePoint 2010 have been designed to share a common platform so that search developers can integrate with both SharePoint Search and FAST Search for SharePoint 2010 using the same query side interfaces. This means developers don’t have to learn new APIs or programming models, but can leverage the same object models, services and a common query language for both products.
SharePoint developers and architects implementing search-driven applications should understand the available integration options. Depending on requirements, tools, and preferences, one can choose from among several integration points, including a brand new object model in SharePoint 2010. Here’s a list of the different integration points with a brief description of each:
The Federation Object Model (OM)
This is a new search object model in SharePoint 2010. It provides a unified interface for querying against different locations (search providers), giving developers of search-driven Web Parts a way to implement end-user experiences that are independent of the underlying search engine. The object model also allows for combining and merging results from different search providers. Out-of-box Web Parts in SharePoint 2010 are based on this OM, and SharePoint 2010 ships with 3 different types of locations; SharePoint Search, FAST Search and OpenSearch. The Federation OM is also extensible, should you want or need to implement a custom search location outside of the supported types.
The Query Web Service
This is the integration point for applications outside of your SharePoint environment, such as standalone, non-web based applications, or Silverlight applications running in a browser. The Query Web Service is a SOAP based ASMX web service, and supports a number of operations, including:
- Querying and getting search results
- Getting query suggestions
- Getting meta data, e.g. a list managed properties
The same schema is shared for SharePoint Search and FAST Search, and both products support the same operations. For querying, clients can easily switch the search provider by setting a ResultsProvider element in the request XML. A number of extensions are available for FAST Search, e.g. refinement results, advanced sorting using a formula, issuing queries using the FAST Query Language.
The Query RSS Feed
Certain scenarios, like simple mashups, may need only a simple search result list. The RSS feed is an alternative, lightweight integration point for supplying applications outside of SharePoint with a simple RSS result list. The Search Center - the default search front-end in SharePoint 2010 - includes a link to a query-based RSS feed. Switching the engine to the RSS format is done by simply setting a URL provider. Because of its intended simplicity, there are some limitations to what can be returned and customized in the query RSS feed. The object models or the web service integration scenarios are recommended for more advanced applications.
The Query Object Model
This is the lowest level object model, used by the Federation object model, the Query Web Service and the Query RSS feed. Both SharePoint Search and FAST Search support the KeywordQuery object in this object model. While the Federation OM returns XML (to Web Parts), the Query OM returns data types.
The Search Web Parts
Search Web Parts in SharePoint 2010 are common in SharePoint Search and FAST Search, and are now based on the common Federation OM. The Web Parts on a page communicate through a shared Query Manager, a central component of the Federation OM. This makes adding new Web Parts that interact with existing Web Parts simpler than before. For example, a new Tag Cloud Web Part for visualizing the query results can utilize the shared Query Manager for getting results. Developers will also be able to extend out-of-box Web Parts as they now are public in SharePoint 2010 (no longer sealed).
The Common Query Language
Both SharePoint Search and FAST Search support the Keyword Query Language syntax. This is the default query language for both products, and the end-user language supported from the Web Parts in the search centers (including the advanced search page).
FAST Search Extensions
FAST Search has a number of extensions beyond the standard SharePoint Search that are available on both the Federation and Query object models, and as well as on the query web service. Some examples are:
-
- The FAST Query Language, which supports advanced query operators like XRANK for dynamic (query time) term weighting and ranking.
- Deep refiners over the whole results set, and the possibility of adding refiners over any managed property
- Advanced sorting using managed properties or a query-time sort formula.
- Advanced duplicate trimming, with the ability to specify a custom property on which to base duplicate comparisons.
- “Similar documents” matching.
- FAST Search Admin Object Model for promoting documents or assigning visual best bets to query keywords/phrases.
Building powerful search applications is easier than ever in SharePoint 2010. FAST Search is now integrated into the SharePoint platform and developers of search-driven solutions and applications can leverage a common platform and common APIs for both SharePoint Search and FAST Search. This means applications can be built to support both search engines and then extended if and when desired to take advantage of the more advanced features available with FAST Search, such as dynamic ranking, flexible sort formulae, or deep refiners for insight into your full result set.
Arnt Schøning, Senior Development Engineer | Microsoft Enterprise Search Group
(o on Twitter as @aschoning)
Comments
Anonymous
February 15, 2010
The comment has been removedAnonymous
February 16, 2010
Hi Robert, Thanks for testing out the query web service against FAST Search. Are you testing this on the beta bits of SharePoint 2010? We've seen this issue in the past, but it has been fixed for RTM. Hopefully you can continue your development using the QueryEx operation for now. Note that FAST Search supports both the Query and the QueryEx operations on the web service, but only the QueryEx operation is extended to return results like deep refinements and visual best bets. So to leverage these new features, you need to use the QueryEx operation.Anonymous
March 04, 2010
Thanks for the info Arnt. Is there anything happening around Connectors (the old protocol handlers)? We're keen to get the FAST 2010 RC hooked in with CRM, SharePoint (2007 & 2010), Hummingbird DM 5 and a DB/filesystem based email archive. Thanks CraigAnonymous
March 04, 2010
The comment has been removedAnonymous
March 10, 2010
Hi Craig, Thanks for your answer, I have tested that in the RC query method is working. :) //RobertAnonymous
March 20, 2010
I think this is a wonderful idea to talk about it, and I am really grateful I found your websiteAnonymous
October 17, 2010
Hi *, looking for some clarification on this topic: We are using the Query Web Service from a web part and the web part send FQL formatted queries to the service. (e.g. <QueryText language="en-US" type="FQL">...). I f we rund the query as "QueryEx" (this returns a data set) we are able to find a node "<RefinementResults>" in the query result. This node is missing if we are executing the same FQL with the method "Query" (this returns xml) instead of "QueryEx". Is it possible to get this refinement result information also in the result by using the xml based answer? Thanks in advance Dirk