1.1.1 Architecture

A central part of the Information Service is the IS repository which holds the information provided by applications. This repository supports three main types of interactions which are shown on Figure 1.1.

Figure 1.1   IS architecture (UML Collaboration diagram)

The Information Provider can create information in the IS repository and also update or delete an already existing information. The Information Reader can get the value of the information from the repository by sending request to it. The Information Subscriber can subscribe for the repository to be notified about the changes. Each time the Provider creates, updates or deletes information the Subscriber will be informed. Obviously, an application can use any combination of interactions described above.

In addition to the interactions with the IS repository any application is able to send commands to any of the running IS Information Providers. This can be done if the IS repository contains at list one information item, which was published by the target Information Provider.

---

The IS commands facility is not an alternative for the general control commands. It must be used only to control the IS information flow. For example an application may ask a particular information provider to increase the frequency of information updates or to republish a particular information.

---

1.1.2 Implementation

In the current IS realization the IS repository is implemented by a number of processes, called IS servers. Each server has unique id which user application can use to access this particular server.

The IS Application Program Interface (API) exists in C++ in a form of library and in Java in a form of JAR file.

The IS uses three level object model1 for the information definition. It provides access as to an information objects as to the classes that describe those objects (see Figure 1.2).

Figure 1.2   IS 3 level object model

The IS meta-type level describes structures of an IS information types in XML format. This description includes definition of the type' attributes, including name, type and optional text explanation for each attribute. User can define his own information types using procedure described later in this document.

The second level contains programming language declarations which are automatically generated from the IS meta-types. The IS information types described in XML are mapped to a classes in C++ and Java programming languages.

The third level contains an information itself in a form of the instances of the programming language classes from the second level of the model. These instances can be used to put the information to the IS repository or to get the information from it.

Each information object has a unique name in the IS repository. In the current implementation, name is a character string which must have the following format:

---

InformationName::=ServerName<.>ObjectName

---

The ServerName must be a valid name of one of the running IS server applications. The information object will be stored in the part of the IS repository which is implemented by this IS server. The ObjectName must be unique for each information object in this IS server.

The current IS implementation is based on the Common Object Request Broker Architecture (CORBA)[5] standard. The C++ implementation is done on top of the omniORB broker. The omniORB [6] is the fully CORBA compliant broker, which is a successor of the Inter Language Unification (ILU) broker[7], which has been used for several years by the Online Software group. For Java implementation the JacORB broker[8] is being used for the moment.

Nevertheless, both C++ and Java IS APIs are independent of the underlying communication technology. This allows to change the communication mechanism in future (if it becomes necessary) without affecting the IS user applications.