Figure 1: Five-layer MIA
This document will form a section of the MIA Requirements Analysis Study being carried out by UKOLN under the MODELS initiative.
Version 0.2 (Draft version for discussion) Tracy Gardner with Paul Miller and Rosemary Russell - Monday July 5th 1999
The main purpose of the MIA logical architecture is to facilitate understanding and discussion of the issues that must be considered in the development of hybrid information environments (a term which includes hybrid libraries and other online resource discovery and access systems). Earlier versions of the architecture have already proved useful in achieving these goals and the architecture will be further extended here to support more varied and more detailed investigation of hybrid information environments.
Additionally, the architecture is generic, it is not intended to be implemented directly but to support the discussion and comparison of alternative solutions. In order to implement a hybrid library system you would need to specialise the MIA logical architecture to suit a particular hybrid library environment.
Additionally, it may be possible to say that existing systems implement the MIA logical architecture to some degree. It is not a requirement that the MIA architecture be a generalisation of all existing architectures (the result could be unmanageably complex), however the architecture should provide comprehensive support for hybrid information environment functionality.
The purpose of dividing an architecture into layers is to achieve local simplicity while still supporting complex functionality. Each layer has its own purpose and abstractions and interaction between the layers should be limited.
The architecture set out in this document has five layers as shown in figure 1. Those familiar with earlier versions of MIA will notice the addition of the 'Provider' layer at the bottom of the architecture; MIA has previously been presented as a broker architecture with data providers outside - in order to describe a complete hybrid information system it is necessary to incorporate the providers into the architecture.
Figure
1: Five-layer MIA
The responsibilities of the layers are as follows:
Presenter - This layer is responsible for presenting information to and accepting input from the user. The layer may need to generate HTML, a non-web GUI interface, a spoken interface, a command-line interface, an email-interface or whatever is required in a particular application. Information entered by the user must be passed on to the Coordinator; this may involve creating `objects' to pass through agreed API's or it may involve encoding the data in a particular transport format - e.g. XML. The Presenter should not be aware of application logic it should only be concerned with display and data entry. For example, the Presenter's understanding of a result set should be limited to knowledge of how to display that result set on the screen (or other presentation medium).
Coordinator - The Coordinator is responsible for application logic including user modelling (where we include the possibility that the user may be a human or a software agent) and session maintenance (which is concerned with taking into account previous actions within the current session). The Coordinator contextualises requests to the current situation. When input is received from the Presenter, e.g. a query request, the Coordinator must manipulate the query according to the user's profile (e.g. adding a request for a particular thesaurus to be used) and the current session; when the result is returned similar contextualisation may occur - for example removing resources that have already been seen within the current session.
Mediator - The Mediator is responsible for understanding the meaning of 'actions' (such as search, locate, request and deliver) that may be performed within the hybrid information system. The Mediator receives action requests from the Coordinator and must determine which service providers (in parallel or in combination) can satisfy the request. Requests may be complex - e.g. search for a book and then locate libraries that hold the book (and may be online bookstores that sell it).
Communicator - The Communicator is responsible for communicating with external services, it shields the Mediator from details such as communication protocols and service locations and may also provide basic mapping between metadata vocabularies to achieve a vocabulary understood by the Mediator. In some cases services may directly support communication with the Mediator (they may have been developed to be compatible with it), in such cases the action carried out by the Mediator will be trivial.
Provider - The provider layer represents the external services accessed by the Mediator. The layer most obviously includes the 'primary' services for which the system exists to provide access, for example library catalogues, abstracting services and subject gateways. The provider layer also includes 'secondary' services that the system must access in order to provide primary services, for example, registries, authentication services and user profile directories. It is recommended that all services that could be shared with other systems be externalised in this way. These services have a responsibility to handle requests as described in their service profile.
Here we consider the `modules' within the layers. Note that in an actual system we would expect to find further modules providing supporting functionality. The aim here is to provide sufficient detail to discuss the functionality of hybrid information systems. Too little detail will mean that it is not possible to discuss common scenarios in sufficient detail; too much detail will overcomplicate the system making discussion difficult.
The MIA architecture aims to be a generic architecture supporting multiple architectural choices. For example, it would be possible to perform result ranking at a number of places within the architecture - simple orderings such as alphabetical by author or title may be achievable within the Presenter, some systems may choose to perform user-preference based ranking as a post-processing activity in the Coordinator whereas others may choose to include the ranking information in the request sent to the Mediator, similarly the Mediator may in some cases request that ranking is carried out by the external services that are contacted. The MIA architecture does not dictate the level at which such ranking takes place, it provides a framework in which such issues can be discussed.
The presentation layer - Presenter for short - is responsible for communication with the end-user, typically this will mean a GUI although alternatives are possible. The GUI may be user-configurable but the Coordinator layer is responsible for managing configuration parameters and providing them to the Presenter. The Presenter may be able to respond to certain display-related requests without contacting the Coordinator, for instance it may be able to switch between full and summary views of search results.
The internal architecture of the Presenter is shown in Figure 2.
Figure
2: MIA Presenter Layer
Generic Usage: The Presenter receives user input (e.g. a form is submitted in a web browser interface); the input is encoded into a format suitable for the Coordinator and passed to Presentation Logic, if the query can be dealt with within the Presenter (e.g. change of font size) then the query will be forwarded to the Display Generator which will update the display, if the query cannot be dealt with locally (e.g. a new search request) then it is passed to the Coordinator the results from the Coordinator are then sent to the Display Generator for output.
The coordination layer - Coordinator for short - is responsible for maintaining the 'user landscape'. The Presenter shields the Coordinator from user-interface issues while the Coordinator shields the Mediator from user-specific and context-specific issues.
Note that user profile information may actually be provided by an external service, in fact, requests for user profile information may be routed through the Mediator. The User Profile module in the Coordinator layer is reponsible for making user profile information available to other modules in the layer.
Figure
3: MIA Coordinator Layer
Generic Usage: A request is received from the Presenter, the request is contextualised based on the User Profile (e.g. specifying acceptable natural languages for the results) and the Session Control, in some cases it may be possible to resolve the request within the Coordinator layer (e.g. next 10 results from the current query) more generally it will be necessary to pass the request to the Mediator, the result will then be contextualised (e.g. marking items that are already in the user's 'shopping basket') and passed to the Presenter to be displayed.
The mediation layer - Mediator for short - is responsible for mediating between brokered services to provide results for requests coming from the Coordinator. The Communicator shields the Mediator from the low-level details of communication with remote services, the Mediator is concerned only with the semantics of those services.
The Request Server module of the Mediator must understand the services that are offered by service providers that are being brokered across. The most obvious kind of service is a 'search' or 'browse' but other services such as a thesaurus or language translator may also be accessed. In some cases the Mediator will be combining results from homogeneous services (e.g. cross-searching) in other cases the Mediator will be building up complex services from simpler ones (e.g. adding third-party quality ratings or annotations to search results). In other cases, the Mediator will simply be providing a unified way of accessing an existing service.
In the Mediator a standard set of result schemas are specified, result combination is based on these schemas. The Communicator must handle translation to and from these formats. For example, an instantiation of the MIA architecture might choose the Dublin Core as its internal format for resource description.
Figure
4: MIA Mediator Layer
Generic Usage: The Request Server receives a request from the Coordinator and must determine how to service that request, if the request is complex it may be broken into multiple sub-requests, for each sub-request the Request Server must determine which services are capable of responding, forward knowledge may then be used to determine whether the services are likely to respond positively. The Request Server will send multiple sub-requests to services via the Communication layer, the results will be combined and returned to the Coordinator.
The communication layer - Communicator for short - deals with interactions with external services. The Communicator receives multiple requests from the Mediator to be executed in parallel, the results should be returned to the Mediator as they become available.
Figure
5: MIA Communicator Layer
Generic Usage: The Communicator receives multiple requests and handles them in parallel. A request must be translated into a format that is understandable by the target service (based on the Service Profile of that service), this may include translation of terms in the metadata vocabulary; a request including the location of the service is then sent to the Protocol Gateways module and on to the appropriate service; a translation is also performed in the reverse direction, for example transforming results into a standard format and vocabulary.
The service provision layer - Provider for short - includes the services to be brokered across in a hybrid information environment.
MIA does not provide an internal architecture for the Provider layer, this is because a hybrid information system has no control over externally developed services. In addition the services in the Provider layer are likely to have complex architectures of their own.
The logical architecture presented above considers hybrid information systems at the module level. When considering the issue of extensibility it is useful to consider the architecture at a lower level. An important requirement for a hybrid information system is the ability to `plug-in' new functionality, this can occur at a number of points in the system - its extension points. New functionality is contained within `components' or `software agents'.
For the purposes of the logical architecture it is useful to consider each of the modules as having a management component which can delegate tasks to appropriate worker components. For example the Mediator may have access to a number of ranking components which can rank search results in various ways - e.g. alphabetical, using various relevance rating strategies, using third party or collaborative ratings - these components will be available to the management component within the Request Server module in the Mediator layer.
When specialising MIA for a specific hybrid information environment it is necessary to define the extension points that are required - i.e. the points at which it should be possible to add new functionality to an existing system.