Figure 1: Five-layer MIA
This document is part of the MIA Requirements Analysis Study being carried out by UKOLN under the MODELS initiative. This draft is made available for comment.
Version 0.3 (Prepared after July 26th Meeting)
Tracy Gardner with Paul Miller and Rosemary Russell - Monday
September 13th 1999
Version 0.2
(Draft version for discussion) Tracy Gardner with Paul Miller and
Rosemary Russell - Monday July 5th 1999
The MODELS Information Architecture (MIA) aims 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.
MIA is a logical architecture, it is not intended to be implemented directly but to support the discussion and comparison of alternative solutions. MIA is also generic, in order to implement a hybrid information system you would need to specialise MIA to suit a particular hybrid information environment. Additionally, it may be possible to say that existing systems implement or conform to MIA 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.
MIA is presented here in terms of 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. A Presenter layer, which is responsible for presenting information to the user (either a human user or a software agent) and obtaining information from the user, is also separated out to allow lower layers to be independent of presentation issues.
MIA assumes that a consistent interface must be provided across multiple protocols (e.g. Z39.50, WHOIS++, LDAP) and multiple services (e.g. discover, locate, request, deliver). A central Mediator layer understands the services that are on offer, but not differences in their implementation - a Communicator layer provides the Mediator with uniform access to services. The Coordinator layer tailors the information landscape for a particular user community, for example, providing pre-configured searches, information management tools such as bookmarks, and user-profile based services such as recommendations. A Presenter layer is responsible for communicating with users (either people or software agents), ensuring that multiple interfaces can be provided to the same Coordinator.
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. Software clients may also need to be catered for, providing for example, Z39.50, WHOIS++ and LDAP interfaces to the system. Information entered by the user must be passed on to the Coordinator; this may involve creating `objects' to pass through agreed APIs or it may involve encoding the data in a particular transport format, e.g. XML.
Coordinator - The Coordinator provides an application layer on top of the Mediator. The Coordinator may provide high-level services built on lower-level services provided by the Mediator appropriate to its user community (e.g. search for local resources) and may add offer value-added services to its user community, such as maintaining bookmarks and providing services tailored according to user profiles. The Coordinator is responsible for application logic including user profiles (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, such as a search request, is received from the Presenter, the Coordinator must manipulate the request 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 (e.g. removing resources that have already been seen within the current session).
Mediator - The Mediator is responsible for understanding the meaning of services (such as search, locate, request and deliver) that may be offered by providers and requested by the Coordinator. The Mediator receives 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). [An issue currently under discussion is whether the Mediator should incorporate rights management functionality with service requests becoming deals between a user (or a broker, on behalf of a user) and a provider.]
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. The Communicator provides a gateway between the Mediator and providers based on a Network Service Profile associated with each service associated with a provider. The Network Service Profile provides details of the location, protocol, query and response formats and metadata vocabularies that required in order to meaningfully access a service.
Provider - The Provider layer contains the external services accessed by the system. 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, schema 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.
Here we describe the responsibilities of the layers and 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.
MIA 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 interaction with users, typically this would be via a GUI or a network protocol. This layer is separated out to enable the Coordinator to be independent of the various ways in which a system may be accessed, this allows the Coordinator to focus on application specific issues. The Presenter is effectively a gateway between the user and the internal information model used by the Coordinator. If for example, the user is a Z39.50 client, then a Coordinator must be able to act as a Z39.50 server, converting Z39.50 requests into a form suitable for the Coordinator and converting responses back. If the user is accessing the sytem via a web browser then the Presenter will need to display information as HTML and collect user input via HTML forms.
The internal architecture of the Presenter is shown in Figure 2.
Figure
2: MIA Presenter Layer
Generic Presenter 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 Output 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 Output 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 if user profile services are among the network services to which it brokers access. The User Profile module in the Coordinator layer is responsible for making user profile information available to other modules in the layer.
Figure
3: MIA Coordinator Layer
Generic Coordinator 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 so that it can offer joined up services based on multiple individual services.
The Mediator supports a pre-defined, but extensible, set of services; the Service Profiles module maintains details of the services offered by each service provider. 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 service requests and results are handled using a consistent format, independent of the formats that may be used by individual services, the Communicator must handle translation to and from these formats. For example, a system might choose the Dublin Core as its internal format for resource description.
In a broker environment it is often necessary to provide query routing to avoid sending every request to every service provider that supports the requested service. Query routing makes use of `forward knowledge' to decide whether or not to send a query to a particular service provider. Forward knowledge can vary from details of the subject classifications covered by a service provider, to `centroids' containing detailed summaries of content, through to harvesting or caching of actual results.
Figure
4: MIA Mediator Layer
Generic Mediator Usage: The Request Server receives a request from the Coordinator and must determine how to respond to 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 Communicator 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 Network 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, 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. Each provider is responsible for providing the services described in its associated Network Service Profiles. Services to discover these profiles and to gather forward knowledge may also be provided.
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 providers in the Provider layer are likely to have complex architectures of their own. In a network architecture some Providers may actually be further MIA systems, that is, the Communicator of one system may talk to the Presenter of another system.
Should MIA provide a model for brokered authentication? This would need to be generic to cover multiple authentication models, including: (i) users authenticate themselves to the system (with authentication managed by the Coordinator) and then the Mediator authenticates itself to services, and (ii) all actions are fully authenticated and authentication information is passed on the Provider. The chosen model would depend on how authentication details are used by service provides: for authorisation; for charging; for tailoring the service.
Should the Mediator layer provide `market place' services with rights management functionality? Currently, access to network services is often provided on an IP address basis. There are various possible models that MIA could adopt, we could assume that there is a deal between a Coordinator or a Mediator and a provider, the users may be indirectly charged for services but not charged at the point of access. Or, we could move to a fine-grained INDECS-like model where access to a service or resource can be charged to an individual authenticated user.
What form should a MIA network architecture take? Two main alternatives have been suggested. The first, is to treat each layer as a separate component that can be at a different location, with multiple Coordinators accessing the same Mediator, and so on. The second, is to require that every node in the network provides the top four layers of the architecture, with some layers inevitably being thin, each of these nodes can then play the role of Provider to other nodes. A combination of both approaches may be the most appropriate.
Interoperability is an important issue for MIA. MIA is generic and does not specify particular standards or APIs to be used, but it does support the identification of areas where a standard, or API is required. For instance, a common format for network service profiles, and a common protocol for obtaining them, would mean that multiple HIEs could share the same profiles. It is desirable to keep MIA generic, however, it may be useful to develop a specific instantiation of MIA which does specify standards and protocols and which could be shared by HIE providers.
Comments to Tracy Gardner - t.a.gardner@ukoln.ac.uk - UKOLN