Data Exchanger Component for Information System of University

Vlasta Leporská

Abstract

The Data Exchanger is designated for the information system integration purposes. This component serves as the central node of the system that maintains and controls data flows between all separate components that the system is consisting of. The Exchanger provides its own data structures representing the union of all data exchanged among components and assures the transfer of data from the source component to the target one(s) in the real time. It stores the copy of all currently actual data being exchanged within the system keeping their consistency. It prevents data transfer process from providing more format conversions than is necessary.

1   Introduction

The main goal of the Data Exchanger component is to bring more efficiency and clarity to the process of the data exchange among components of the information system. In principle the Exchanger is a kind of middlewear solution, applied to not very large information system, like university information systems used to be. In comparison to middlewear in general it doesn't have to be so complex as usual solutions are but it must solve some distinctions. What makes the task the Exchanger solves easier is the fact the information system of our university works on one database system namely Oracle and most components even use physically the same database. What's non-standard it's for instance the problem with several sources of data with the same meaning within the system, especially data of the same subject coming from different source components. It concerns mainly personal data of persons that study at the university and at the same time they work for the university. Their personal data in this case come from the information system of studies component and they are also registered as employees in the standard personal agenda of the university. When the student/employee changes his/her data in one source component the other one might not have its data of that person up to date. The Exchanger solution is trying to match to the information system of Czech technical university environment and means it offers.

2   Base Ideas of Solution

The Data Exchanger Component implementation follows a few base ideas that are general for solutions like that. These topics are discussed in this section.

2.1 Data Source and Target

In general a component of the information system works with data that have the same meaning like data of one or more other components. Data like that is necessary to exchange among components to make the system working properly.

From the data flow point of view we can define "the source component" where data is created and "the target component" that needs data coming from a source. In some cases can happen that more than one component produces data of the same meaning and type within the system, for example personal data as was presented in the Introduction section. The Data Exchanger solution requires the only one source of data that have the same meaning and type for further processing. It means that in this case there is necessary to provide the Exchanger subcomponent that collects such data assigning system wide unique identifier to every item and guarantee that any change of data is distributed back in other source components. This solution ensures that these data are any time up to date and consistent within whole system and is ready for distribution.

In case of data exchange between every source and every target component the more data transfers are run than is optimal. The Data Exchanger purpose is to take data from a source put them in its internal data structure and then to distribute them in target components.

2.2 Common Data Structure

Data that flow through the Exchanger are stored in the Exchanger's internal data structure that is permanent even if it keeps just actual state of data. The Exchanger has to provide its own data structures representing the union of all actual data shared by at least two components of the system. That data structures are independent from the data formats provided by single components.

[S] – source component

[T] – target component

Fig. 1 Exchanger data structures idea

This approach prevents data transfer from multiple format conversion between component specific data formats. The only remaining conversion will be the source component -> Exchanger, the Exchanger -> target components. So for instance if a source component data format has changed, only source component -> Exchanger conversion could be updated instead of N conversions of the source -> target.

2.3 Real time data exchange instead of batch processing

The simplest philosophy of system integration on the database level is providing "interface views" from a component's database to let another component access data. Information system components usually provide system integration support based on a set of views as the standard interface. Using those views invokes the way of batch processing view data that is provided usually once a day, best over the night when the information system is 'sleeping'. That method has some disadvantages. The first one is the time delay between entrance data in the system and their delivering in a target component. In addition the batch data exchange spends much time because of processing bigger amount of data than is actually needed to process. The main disadvantage is that data are distributed 'one to one' component within the system, what's just an approach opposite to the Data Exchanger idea.

Theoretically this approach could be accepted also in case of Data Exchanger solution. Data Exchanger can read data from component views, put them in its data structure and provide views towards target components. But when we are going to establish the 'system central data transfer node' why not to try the real time transfer approach? At the database level is a way to do it using database triggers providing transfer single records from the source component to the Exchanger data structures and then into appropriate target components when triggering event like insert or update data happen. Alternatively instead of trigger on the data source entity the interface procedure called by the component application when user makes an action can be provided. Anyway in both cases the data entered in a component are transferred in the Exchanger immediately in the real time and then depends on target components whether they need to let data flow in their data structures immediately too or if they prefer starting data transfer on a user action or if they load data from the Exchanger in a time interval.         

3   Data Exchanger of the Information System of Czech technical university in Prague

The information system that Czech Technical University in Prague provides, has been built in sequence by needs of particular areas like economy, study, science and research regarding assets available. Consequently this system is currently consisting of several independent components like the Financial Information system component, the Personal Record-keeping system component, Studies Maintenance component, the component for Science, Research and External relationships and some else ones each supplied by different vendor. The information system of the university also provides its own part for providing student/employee smart cards internally used for various purpose: entrance identification, payment services within the University etc.

The Data Exchanger component idea was worked out during the fall of 2003, so the design and development this component is currently in progress. Regarding the fact the most of the Information System of Czech Technical University in Prague is put in Oracle environment, procedures providing Data Exchanger functionality, are implemented in Oracle using PL/SQL programming language.

The Data Exchanger is developed incrementally step by step where one step represents one data flow. At first it is necessary to process data that are most urgent to provide them efficiently, currently the data of persons that are shared by almost all components of the system. Just in case of personal data there are two source components that bring them in the system (students and employees) and sometimes data conflict occurs when the same person is stored in both components with different data. To have the only one source component for one kind of data exchanged via Exchanger there was developed the central Persons Register subcomponent that collects basic personal data of all persons stored in the Information System within whole university.

3.1 Central Persons Register Subcomponent

In detail the Persons Register works following way: both components - the Personal Record-keeping system component that maintains employees data and Studies Maintenance component that maintains students data, write a record to the Persons Register any time when some new person data is created or updated by the component. When a person is created first time, the Persons Register generates and assigns the personal number, unique within the system, to that person. When opposite component is going to create new person, it must ask Persons Register first whether that person already exists in the system being created with other component. There is used the personal identity number valid in the Czech republic like unique identifier of person for this purpose. If that person exists in Persons Register - i.e. a person having this identity number is found in Register, his/her data are shown in the form of component that is going to create that person's record in its database. Any change of data of a person is logged and if that person is kept also in the opposite component, the change is immediately announced to competent clerks. This solution enables to control all personal data consistency and prevents possible conflicts. Communication between components and Register is provided in real time via PL/SQL interface procedures called by components.

3.2 Common code-lists as a part of the Data Exchanger

The Data Exchanger as the central node of the system is the best place where to put central code-lists common for all components. It concerns various kind of common data used by many components like currency code-list, degrees code-list, position names list etc. The Data Exchanger of the Czech Technical University will maintain also the data structure containing system wide general coding the organisation units that several components work with and until Exchanger solution comes they have been using its own coding each different from others. Data like that are not exchanged between components but they are shared by components so that's why we decided that functionality belongs to the solution of the Data Exchanger.

4   Conclusion

 The Data Exchanger information system component solution is probably simpler than standard middlewear but more complex than some similar approach that many institutions, solving system integration problem, apply. Most often solution used to be providing not a real data transfer node but only some 'data collector' that brings data from various sources into one heap. There are commercial products, that are able to collect and structure wide sort of data from many different data sources and store them, but the result data set is not distributed along the system, it is presented on web or reported some way instead. Data kept by Exchanger internally also can serve for analysis purpose or can be distributed or reported outside of the university information system including web publication.

The Data Exchanger represents a simple middlewear solution that could be interesting for another institutions, similar to our university, that need to integrate data of various components of an information system.

[back]