Thu, 09/09/2010 - 13:30 — projectmember

The Fredhopper Access Server (FAS) is a component-based, service-oriented and server-based software system, which provides search and merchandising IT services to e-Commerce companies such as large catalog traders, travel booking, classified advertising, etc.

Conceptual Architecture

We present the structure of FAS in the following way: query engine, business manager, indexer, data manager, search engine optimizer and targeting diagnostic tool. An architectural view of how these components are related in FAS is shown Figure 1.

Figure 1

In the following paragraphs we describe informally the functionalities of each component:

Business Manager The business manager component provides to clients the management console for managing, monitoring and measuring searches, catalogs, navigations and promotions. There is also a graphical user interface, which allows non-IT business specialist to interact with the component.
Data Manager The data manager is an Extract, Transform and Load (ETL) toolkit. It provides mechanisms to extract data from a variety of data sources such as ERP systems, databases etc.; to transport extracted data and carry out transformation such as normalization and aggregation etc, and to save transformed data as FAS input XML.
Indexer The indexer component is composed of three subcomponents -- XML loader, search indexer and tree builder. The XML loader takes an input textual (XML) description of operations on data items and performs those operations. Operations include adding items to the FAS index and annotating (enriching) items with more information. The search indexer is responsible for processing the loaded raw item into index structure, allowing efficient search. The tree builder is responsible for constructing tree model index from loaded items, which is then used for faceted navigation within catalogs of items.
Query Engine The query engine provides the core query and response mechanisms. It serves request from both (web) search engines and customers.
Search Engine Optimizer The search engine optimizer component implements a white hat method to guide (web crawler) search engine when indexing web sites with faceted navigation. Faceted navigation provides users the technique for accessing a collection of information represented using a faceted classification, allowing users to explore catalogs by progressively filtering available information.
Targeting diagnostic tool FAS provides a mechanism allowing end users to specify business rules that regulate what, how and where the FAS system retrieves and presents content. FAS integrates a third party rule engine that infers rules at run time. Nevertheless, employing a third party library has the limitation that the FAS system cannot easily track how the rule engine works. For this reason, we introduce a diagnostic tool (run time monitor) component to provide the capability to access information about particular inferencing and provide corresponding debug information such as if and why a particular business rule did/did not allow displaying of expected/unexpected information.

Deployment Architecture

To minimize the possible disruption caused by updates of data and configuration in a FAS installation, each FAS installation is deployed for a customer according to the FAS deployment architecture. Figure 2 shows an example setup. A FAS deployment consists of a set of ``environments''. In this case study we focus on two types of environments: live and staging. Briefly, the staging environment is responsible for data and configuration updates while the live environment is responsible for serving queries from client-side web applications.

Figure 2

A live environment processes queries from client web applications via the Web Services technology. FAS aims to provide a constant query capacity to client-side web applications. In the deployment example in Figure 2 there are two live environments.

A staging environment is responsible for receiving client data updates in XML format, indexing the XML, and distributing the resulting indices across all live environments using the Replication System.

The communication between the live and the staging are governed by the replication protocol, which is implemented by the Replication System Product Line. Specifically, the Replication System Product Line consists of a synchronization server residing in a staging environment, a set of synchronization clients residing in the live environments. The synchronization server determines the schedule of replication, as well as the content of each replication item. The synchronization client is responsible for receiving data and configuration updates. A replication item is a set of files representing a single unit of replicable data.

Variability

The Replication System Product Line consists of several variants of the replication system. We express these variants as features. Figure 3 shows the feature diagram of the replication system. The feature diagram has five main sub-features: Installation, Resources, Replication Item, Load and Job Processing.

Figure 3

To take all the variability of the Replication System Product Line into account, we construct the Full ABS model of the Replication System Product Line using the Delta Modeling Workflow [5,6]. A full ABS model of Replication System Product Line constructed using the Delta Modeling Workflow can be found at [7].

Main menu

You are here

Fredhopper Access Server

Conceptual Architecture

Deployment Architecture

Variability

Further Reading

Main menu

You are here

Fredhopper Access Server

Conceptual Architecture

Deployment Architecture

Variability

Further Reading

Login