5. Common Bridges (CS, Communication System)

5.2. The Bridges System Manager

5.3. Definition of Bridges Messaging System (MS)
5.3.1. MS First Role: Message storage and translation
5.3.2. MS Second Role: The Transmission of messages

5.4. Software implementation of Bridges Messaging System
5.4.1. First alternative: Mail Box System on disk managed by Bridges Communication System
5.4.2. Second alternative: Dynamic RAM structures based on "atoms".

5.1. Objective: tools to build open multi-software systems

The software architecture to be adopted for any complex support system (including information and modelling, as well as decision support) should ideally be defined as an "open, decentralised and highly intercommunicated network of autonomous components, most of them able to work on an stand alone basis". Only such open and scalable architectures are able to satisfy both today's requirements and have the potential to evolve over time so as to be adaptable to the changing needs of users and ongoing software and hardware innovations. A complex information and modelling system dependent on a single software application has more problems meeting all user requirements while still being flexible enough to be updated. For these reasons, the software industry is moving towards open and decentralised network like structures, bypassing centralised hierarchical structures .
Software providers are increasingly making it possible to drive their applications from external user friendly interfaces. However, because only a part of the functionality provided by each application is actually applied by users, the industry is beginning to develop such applications as independent modules or objects (Component Software) which can be called up from external applications.

While the software industry is providing a large number of applications, components, routines etc., options to "bridge" these into integrated multi-software systems make use of Microsoft OLE/COM/ActiveX protocols in the Windows Intranet environment and largely Java-based options for both Intranet and Internet. For large corporate databases there are a number of software solutions available to program communications systems but these options require very intense and expensive programming work and a great deal of software expertise.

Bridges has developed its own royalties free original Communication System in C++ for Intranet (Windows NT) based on OLE/COM/Active X. This technological solution was considered the most suitable for a transport information and modelling system . In principle, the Bridges Communication System was designed to be linked to the Internet as well as interconnecting to other Communication Systems but the implementation of these options requires further research. In Bridges technology no single component is indispensable. Even the Communication System could be substituted although this is not recommended.

The Bridges Communication System is composed of two main modules:

• System Manager (SM)
• Messaging System (MS)
  

The System Manager (SM) takes care of the development and maintenance of all personal work spaces linked to the system and provides registration, status declaration and control of users' priorities and confidentiality for the applications and databases linked to each personal work space. It also provides help to system developers in modifying the system. A work space is a particular set of applications and databases driven by a personal user interface within a specific multi-software system developed using Bridges Communication System. The Bridges System Manager (SM) controls user work spaces, applications and DBS in an Intranet supported by Windows NT.

The Bridges System Manager has three main characteristics.

• A hierarchical structure. Many databases could be linked to a single work space, which is made available to users according to their status (open, restricted to certain user categories, confidential).
  § Within a single work space, information is organised in "Projects". A project is an arbitrary list of DBS (Databases and Tables) and CAD files, attached to common classes of network objects, geographical layers and thematic levels.
• Bridges System Manager is located in the Server of a LAN controlling all common databases and applications, maintaining the registration and status of work spaces and users, and, optionally, taking charge of the development of new work spaces.
  The SM works on a Windows NT LAN of multiple users, work spaces, applications and database sets. A hierarchical organisation is established as a first step of management strategy. The LAN will have a Server and a Central SM responsible for maintaining common database sets, applications and work space.
• SM keeps a register of users and categories of users
• SM keeps a register of work spaces and the status of work spaces.
• SM keeps a register of common applications registered for LAN use
• SM registers common and specific database sets, together with their availability for application (depending on formats), work spaces (depending on status) and users (depending on their category)
• The SM facilitates definition (and modification) by the work space developer of the application composing the work space.
  

The Messaging System (MS) receives, processes and transfers the "Bridges messages" between applications (stand alone system modules) included in personal work spaces. The Bridges Messaging System consists of the following components:

• A library of Bridges messages, which contain information, data or addresses of memory structures where data is located; they also contain the name of the application sending and the application receiving the message (a reference to this can be found in Bridges User-Guide)
• Messages are stored and transferred as simple "strings" using the "SendMessage (Resize)" function, a Windows API Core function . Bridges Messaging System is the module taking care of the transmission of these messages.

Third, the actual translation between Bridges messages and the specific functions required to drive each commercial application, is carried out by independent Bridges modules (translators) linked to each commercial application. The software provider of each commercial application declares a number of "OLE compatible functions" a developer can invoke from an external application to drive the application; usually only a limited number of functions can be invokes by using the application's programming language.

Two different kinds of Bridges messages have been defined:

• System messages [Sys]: Basically, they are warnings and help messages between the MS and the user interface of a WKS.
• Application messages [App]: They are sent by one application to another in the same work space and contain all the information needed for channelling it to its target through the messaging module, to be translated by the translator module and executed by the receiving application.

For example, "OPENGIS (file)" is a standard Bridges message requesting a GIS application to display a file. This message leaves some freedom to the translator of the receiving application: each GIS application will use its own default commands to determine the zoom level of the file it is displaying after receiving OPENGIS (file). Bridges Mapinfo translator (Bridges TTAB) would request Mapinfo to use the latest zoom level defined by the user. OPENGIS (file, zoom, x, y) is a standard message which controls the scale and position of the file ([x,y] are the file's central coordinates). The message "WSELECT (book, sheet, cell)", when it is translated by the EXCEL translator (Bridges TXLS) opens a particular sheet from an EXCEL book and focuses on a particular cell.

There are messages which do not require any additional information: for example, "REGENGIS" regenerates all active views in a GIS application, "RESET_ELEMENT" removes the selection, if any object has been selected. There are messages with information attached, limited to a maximum of five parameters, for example: "MAP_RSELECT (number of fields, name of file, command)". Other messages contain information addresses. The message includes, together with the command and any necessary parameters, the address of the information. The information is stored on DBF Exchange Files to allow it to be read easily from the C++ based Core applications. DBF default files contain a single table with a predetermined maximum number of variables in columns. The first two columns contain identifiers for the objects, which belong to the same class and therefore share attributes (variables). The number of objects (files) is unlimited. The message contains the address of the DBF file (directory path).

In conclusion, Bridges messages [e.g. OPENGIS (file) or WSELECT (book, sheet)] are sent between Bridges MS and all translators, and the actual translation to the internal functions of each application is the responsibility of each translator (e.g. TXLS for EXCEL, TTAB for Mapinfo etc.).

Translators have been implemented for most common CAD, GIS and DBS applications and the methodology can be applied to develop others. For original stand-alone applications (e.g. NISystem modules) the executable files have to contain the translator capabilities.

The Bridges communication approach is, to some extent, similar to the SQL library of messages that different Database manager applications can execute after being translated through ODBC drivers ("translators"): The Bridges Messaging System channels the Bridges messages to the translation module of each application and then the translator "translates" the message to (and from) the specific functions of the application.
In practice, the Messaging Module works as follows: it receives messages from the applications included in the system, stores them in a FIFO queue (if they have no special priority), reads them, identifies the receiver and transfer them to the translator of the receiver application, assuring channel synchronism. Each Translator Module is programmed as an OLE container of its application, so it is able to drive the application to execute the translated message automatically. Both the Translator Module, and the application contained by it, are active simultaneously in the work space and remain in a standby situation, keeping the communication channel open.

As has already been described, the Bridges Messaging System was designed to perform two fundamental roles: Message translation and Message transmission.

• The first role is needed to store Bridges messages and translate them to and from the specific OLE functions of each application.
• The second role is needed to notify to the translators that a given translated message is stored, waiting to be read.

The following sections describe the software solutions adopted to implement each role.

Once a given application has to send or receive a Bridges standard message, a translation is needed to (or from) its internal OLE/COM automation functions.

This translation is carried out by a translator, built using Visual Basic, with one translator for each application. The translation of a given Bridges message may require several steps and checks, and therefore the Translator Module is not just the list of Bridges standard messages followed by their OLE translations. Often, the internal macro-language of each application (e.g. Mapbasic for Mapinfo) has to be used also. For example, the TTAB.EXE translator translates standard Bridges messages to Mapinfo Pro by an extensive use of Mapbasic language, given the relative low level of Mapinfo OLE functions.

To explain how the translators work, consider the translation of a particular standard Bridges message: "MAP_RSELECT (number of fields, name of file, command)".

Four separate commands have been implemented within this message:

1. Show the objects selected,
2. Generate a thematic map considering the first field as a parameter to be viewed,
3. Generate a bar graph (each bar represents one field) and
4. Create new arches and assign information from the transferred file to them.

To translate this message to Mapinfo, many Mapinfo OLE functions (each with several Mapbasic functions as attributes) need to be used. The fourth command (Creation of new arches) requires Mapinfo "DO OLE [...]" function, together with the following MapBasic functions: "CREATE TABLE [...]", "CREATE MAP FOR TABLE [...]", "ADD MAP LAYER [...]", "SET MAP LAYER (table) EDITABLE (on/off)", "CREATE LINE [coordinates origin [x,y], coordinate destination [x,y], pen type]".

In the case of "DO CREATE LINE", coordinates [x,y] from points of origin and destination are obtained by using Mapinfo "EVAL OLE function". Depending on the previous use of the OLE DO function, Mapinfo may consider different queries, which makes the translation a little more complex and requires double checking.

This sample illustrates how in a given OLE functions and the programming language of each application (e.g. MapBasic) need to be used to translate a common Bridges Message. To summarise, the translator contains the list of Bridges messages and corresponding application messages. The Translator Module of each application included in the work space remains in a RAM standby situation once the work space is opened by the user. When the translator module receives a message from the central work space Messaging Module (see second Role) it processes the message as an event, generates the OLE translation which its contained OLE application executes.

The message transmission process consists of the following steps:

• The user clicks an available option in the interface which requires the work of one or many applications, and then the MS automatically establishes the communication between these specific applications linked to the work space.
• The Messaging Module receives the click as an event which causes it to write a message in the Translator Module mail box of the application to be activated. The particular message written in the box depends on the command assigned to the "click".
• The Messaging Module sends a warning to the Translator Module of the application (through a "SendMessage" API function) to ask it to read its box
• The Translator Module reads and translates the message to the OLE server application it contains, causing it to execute the command.
• Depending on the specific message involved, the Messaging Module may send it to one or more other applications.
• If needed, the Translator Module writes a message in the Messaging Module box. The Messaging Module will read it immediately it is received.
• The Translator Module sends a message back to the work space Messaging Module telling it "the process has been completed successfully".

The transmission process is actually channelled by the MS as follows:

• The Messaging Module declares to Windows NT its "hwnd" (the window where it receives and send messages).
• The Translator Modules for all the applications registered in the work space declare their "hwnd". Because translators are programmed as "OLE containers" of their respective applications, they will drive their user interface according to the messages they receive (e.g. open the application in a fixed window situation -hidden or visible, maximised, minimised etc.- execute the tasks ordered, close or remain open etc.).
• All hwnd windows (from the MS and translators) are hidden from the screen in order to free the user from viewing information which is of no interest to him, but remain open in a RAM standby situation until the work space is closed. Messages between applications can be sent automatically by a given Translator Module if it has been pre-programmed this way.

The process described above could follow, for example, the following sequence:

1. The user selects a range in EXCEL
2. The user clicks a button in the work space interface to display EXCEL data as a MapInfo thematic map. The button belongs to Bridges Messaging Module. The click is processed as an event which initiates the following sequence:
3. Send the message "XLS_WSELECT (book, sheet)" to the EXCEL Translator, TXLS.
4. TXLS writes the selected range of the mentioned book and sheet in an Exchange File
5. TXLS sends the message "SYS_NWSELECT (number fields, name of the exchange file)" to Bridges Messaging Module.
6. Bridges sends to TTAB the message "GIS_RSELECT (name fields, file, operation code). The operation code depends on the work space configuration (in the work space interface different buttons may be linked to different operations, in this example different types of thematic maps (bars, arches etc.).
7. TTAB translates the message into a series of OLE functions (based on the OLE functions MapInfo provides plus the MapInfo language: MapBasic).
8. The message is executed: MapInfo displays the required thematic map with all the objects selected on EXCEL
   

Based on the previous definitions, two alternative ways of implementing MS have been simultaneously developed:

• The first one is based on a conventional mailbox system built on the Windows O.S. and managed by Bridges. It is composed of several static memory structures located in disks ("boxes") capable of holding a single message and a dynamic queue in RAM where messages from boxes are transferred immediately and classified according to priority for execution [for example, the message "Stop workspace" will have the maximum priority, while most other messages will follow the FIFO processing].
• The second one is based on the Win32 API Atoms concept, a shared dynamic memory on RAM managed by Windows O.S. itself, which removes the need for static boxes.

Both approaches have been developed and implemented for testing during the research.

The obvious alternative to both approaches would be an OLE application (or several) with infinite loops checking boxes permanently. This would represent a waste of memory and has therefore been rejected. However, in some cases where multiple messages are sent with great frequency, this could be useful and save processing time.

This alternative is based on the following modules:

• "WkS Box" is a simple ASCII file where the sender applications write their messages. The WkS Box contains only one message. The sender opens the file (therefore preventing other applications from writing to it) and writes its message. In order to view and read it easily, the WKS Box has been specified as an ASCII file.
• "Wks Queue Box of messages: this is a space reserved in memory, where Bridges Messaging System transfers messages from the WkS Box and where they wait to be processed in FIFO priority ("First In is First Out").
• "Application WkS boxes": There is one box for each application in the work space. Applications read their messages in their WkS boxes.

MS is provided with a timer, an API function which every 250 milliseconds sends a message from the queue. Timer signals are continuously processed as the event "Read Queue" (in FIFO order unless otherwise stated) for Bridges Messaging System. Once the message has been read from the Queue, it is transferred to the Application Box together with a "SendMessage (Resize)" as a warning to activate the application.

For each application, a specific Translator Module has been developed (for example, TXLS for EXCEL, TTAB for MapInfo), which, after being activated by receipt of the "Send Message (Resize)" notification, reads its box, translates the message and executes it according to its own rules, afterwards deleting the message from its box and leaving room for the next message to be written.

According to this first approach, the design of the Messaging System is based therefore on three crucial points:

• The use of "SendMessage ("Resize Window") as API function for warnings. The usefulness of "Resize Window" is that it will be always linked to a request to read a box if the windows are defined as hidden (the user can not resize a hidden window).
• Synchronising the flow of messages through an intermediate queue box. Synchronisation is essential because of Windows NT's capacity to carry out simultaneous processes (applications must be activated and stopped according to the messages they are sending and waiting for). In addition, the communication system has to be fast enough not to delay processes already running and it has to be as simple as possible so as not to interfere or be dependent on the applications (see below).
• The establishment of specific modules to translate Application Boxes messages to the language of each application, as OLE container applications.

An "atom" is a unique 16-bit value that is associated with a constant value string. Using an atom as a reference to a string is similar to using a memory handled to reference a block of shared global data. Just as an application can pass a memory handled to the Win32 API to obtain a pointer to the contents of a block data by using GlobalLock (...), an application may call the Win32 API to obtain the value of a string associated with an atom. The string value that an atom represents is known as its "atom name". The use of atoms to exchange strings between applications is one of the foundations of Dynamic Data Exchange (DDE). Atoms are also used to store variable-length strings in Object Link Embedding (OLE) object descriptors.

In order to use Global Atoms for Data Exchange (in particular, strings representing commands between applications), the Translator Module of the sender application adds a string to the global atom table. Using GlobalAddAtom (), Windows fixes a particular address for the string in the table, which is transferred as a parameter to the Translator Module of a receiver application. The receiver uses Global FindAtom (...) to find the contents of the received data and deletes the atom using GlobalDeleteAtom (...).

The main advantage of atoms is the speed of the process (managed on RAM), its simplicity (because Windows O.S. takes charge of box creation and management) and easy C++ programming. However it may require more sophisticated Visual Basic programming, and reduce the Bridges developers' options to control the priorities and flow of messages.
Bridges Messaging System allows the simultaneous use of both approaches (static boxes and dynamic RAM atoms), and could also permit the option of infinite loops to substitute for notification of messages, if needed.

info@mcrit.com