SOMA-based Virtual Museum Infrastructure

On the basis of the SOMA general architecture, we have designed a specific MA-based infrastructure for Virtual Museum (VM) services. The main guidelines in the implementation of the VM infrastructure are:
to overcome the heterogeneity problems due to the intrinsic open nature of the considered data. To realize a completely open framework, we have followed the principles of data resource encapsulation, and we have pursued the compliance with most accepted data access standards (JDBC, ODBC, and CORBA access in case of legacy data resources).
to improve the efficiency and the effectiveness by the realization of a persistent information infrastructure to accommodate user-subscripted queries, i.e., queries that one user is permanently interested, integrated with the Web. The VM infrastructure can maintain distributed cached results for subscripted queries and can automatically update this information at predefined intervals, as specified in the user profile information. This can significantly reduce the on-line connection time needed by the user since she has only to receive the already retrieved query results.

The VM infrastructure results from the interaction of several MA-based components (see Figure 1).

The Access Agent (AA) is responsible for accepting queries from authorized users. We introduce different types of AA tailored to the recognized different user roles: manager, expert and normal visitor. Normal visitors can only submit simple queries and explore the provided results with no possibility of specifying a required QoS level on reception. Experts can also subscribe for query repetition and are accounted on the basis of both the VM resource consumption and the obtained QoS. In addition to the functionality available to experts, managers can modify the VM data under their responsibility, e.g. for dynamically adding a link to a new publication about a particular artifact. AAs are in charge of authenticating the connected user and associating her with the proper role, by exploiting the underlying SOMA security facility. Then, they collect the requested query, decide how to answer the query by coordinating a group of query agents, control the work progress up to its completion, and finally yield back the results to the user according to the corresponding user profile information. Any of the aforementioned AA comes in two flavors depending on the fact it implements or not the Web-enabled CORBA server interface (see Figure 2): it can directly run on client hosts, or it can reside on a Web server and be accessed via a CORBA-client applet integrated in a standard Web page.

(Other MA-based components follow...)

Figure 1. The SOMA Architecture for VM Services
(click here for a larger view of the picture)