SES-to-SES Federation vis-à-vis Suggested Content

Timothy lists out the differences between the SES-to-SES Federation and Suggested Content.

SES-to-SES Federation
Federation between SES instances is used when the SES datasources are spread over more than one SES instance.

Reasons for using SES-to-SES Federation includes:

• Scalability - If there are large number of documents to be indexed, then indexing them on one Oracle SES instance can be be less efficient than splitting the documents across multiple Oracle SES instances and federating to these instances.
  
• Multiple identity managers - Since we only support a single ID manager per SES instance, you need to use separate instances if your datasources use more than one identity manager (For example, OID and Active Directory).
• Administrative separation - The support organization may have their SES instance, which they maintain, and the data center may have theirs. Nevertheless, they may want to make their searches available to each other. SES-to-SES federation allows this.

The requirement for federation is that the remote source is an SES instance.

Suggested Content
Suggested Content is generally (but not necessarily) used for accessing content, which is NOT indexed in an SES system. This might be because there is no connector available for that source and/or it maintains its own text indexes, or because the nature of the content is such that is doesn't need to be free-text-indexed, but fetched by some unique string or identifier; For example, typing "bug 999999" to retrieve the text for that bug.

Other reasons for using the Suggested Content include:

• For certain use cases, you do NOT want the results from multiple repositories to appear in one merged result set. These cases include:
  
  - Cross-repository relevance: While SES provides the ability to intelligently score and rank results coming from different repositories, sometimes it simply doesn't make sense to merge. A good example is if you have two repositories - one, which is very rich in metadata and the other, which is purely unstructured information. In that case, there will be a natural tendency for the metadata-rich results to be favored by SES.
  
  - Separation of results: There are use cases where you simply want all results from one repository grouped together, presenting the first N hits only (e.g., show me the top 3 hits from this repository). Furthermore, if you want to see more results from that repository, you can click a link to show all results from just that repository (a drill down into that particular SES instance). This can be implemented with Suggested Content.

The requirement for Suggested Content is that:

• The data should be accessible at a URL, which can include the search string(s) as a parameter. For example, for the bug example, if the user enters "bug 999999" then it must be possible to have a URL where you can substitute or insert the number 999999 and fetch the information for that bug.
• A stylesheet must be provided which can translate the page produced by the URL into a form that can be used in the hitlist page. This is easiest if the URL returns XML, but HTML can usually be processed as well.

End User Perspective
In terms of the user experience, a major difference between federation and suggested content is that the federated results will be merged into the results from the local machine to produce a single hitlist. In suggested content, the results are listed in a table at the top of the hitlist and not merged. They also do not need to conform to the standard hitlist entry layout of title, snippet, author, date, URL etc. Instead the layout is purely down to the stylesheet provided by the admin user.