User Information Access (structured data)::Runtime pattern
Design Last Updated: 12-14-2004
(Click a node to get a detailed explanation.)
User Information Access runtime patterns are more conveniently divided into those that access structured data and those that access unstructured data.
The figure above represents the basic Runtime pattern for structured data including a representation of drill-through corresponding to the User Information Access application pattern.
In the figure above, the Presentation/Web Application Server node handles the user interaction originating from a Browser. This component or a fat client operating via a product API (represented by the Win32 node in this Runtime pattern) passes requests to the Query and Analysis Server node, which then processes them and returns the results to the user on the Browser or the client. The underlying interaction between two Data Servers to support the drill-through function can be seen in this diagram.
User Information Access (unstructured data)::Runtime pattern
Design Last Updated: 12-14-2004
(Click a node to get a detailed explanation.)
The figure above represents the basic Runtime pattern for unstructured data corresponding to the User Information Access application pattern.
In the figure above, we illustrate the case of the Search & Indexing accessing data from two independent Data Servers. (The two redbooks Patterns: Information Aggregation and Data Integration with DB2 Information Integrator, SG24-7101, and Patterns: Portal Search Custom Design, SG24-6881, also used the terms "Search" and "Search Server" for "Searching & Indexing.")
User Information Access (unstructured data)::Runtime pattern=Search adapter variation
Design Last Updated: 12-14-2004
(Click a node to get a detailed explanation.)
In a portal implementation, a search technology will often be expected to have "brokering" capabilities. This is the ability to search multiple data indices simultaneously, and provide a seamless consolidated result set with reasonable response time. In most cases, such multi-source brokered search solutions will be implemented via the inclusion of "search adapter" nodes, as depicted in the figure above.
The search adapters, then, contain the logic to interface with the actual data indices - either interacting directly with the index at a database level, or interacting with a controlling application's search interface (normally via a product API). In some cases, multiple search adapters may exist to process queries against a single data index. The idea here is to eliminate any single node in the process from becoming a bottleneck, if too many search requests run against one source. The data indices themselves are regularly updated by the "population" based capabilities discussed in other Runtime patterns.
The search adapters then return the search results from each individual data index, which the search brokering node must then aggregate and normalize so that the results appear to be from one "virtual" source. The aggregated results are sent back to the presentation/Web application server node, which must format the results for sending back to the client that requested the original search. Search results may be sent back to the presentation node in an already formatted manner (that is, full HTML), or may be passed in a manner that requires the presentation node to transform the data (that is, XML) into the appropriate formats. Similarly, the presentation/Web application server node may then pass the search results to the client in either a fully formatted manner, or may leave the final formatting of the search results up to the client application.
Overall, this separation of the search capabilities into multiple nodes in the Runtime pattern, when they were simply defined as a single "data integration" tier in the application pattern view, provides for a level of flexibility in terms of maintenance and performance tuning that would otherwise be unavailable should only a single node provide the required capabilities.
User Information Access (unstructured data)::Runtime pattern=Search services variation
Design Last Updated: 12-14-2004
(Click a node to get a detailed explanation.)
Another variation of this Runtime pattern to consider is support for the cases in which the "data" being searched is not data itself, but rather a "search service" with a defined API for interaction. In such a case, an additional variation would apply to highlight the fact that the search adapters may not directly access a data index, but may interact with an existing search service to actually perform the search. This variation is shown in the figure above.
The main difference between this variation, and the search adapter variation, is the inclusion of another search node - representing the external "search service" to be accessed by the search adapter. As far as the user of the application is concerned, they do not know that the search is being performed against a data index directly, or via such a search service.
For more details on Runtime patterns for unstructured data, please refer to the redbook Patterns: Portal Search Custom Design, SG24-6881.