Browse Prior Art Database

Database bound notification communication between distributed components

IP.com Disclosure Number: IPCOM000132428D
Original Publication Date: 2005-Dec-15
Included in the Prior Art Database: 2005-Dec-15
Document File: 3 page(s) / 42K

Publishing Venue

IBM

Abstract

Distributed applications, which are not hosted on an Application server with the underlying communication stack, still might have the need for exchanging messages between the application components. Often it is necessary to exchange information, triggered by event, between a server and several clients or even between client components. This article describes how event driven communication can be performed on the base of a database connection only. The technique is independent from specific database vendors and is based on standard SQL functionality. It allows sending any kind of message token between several related server or client components, using database tables and locking mechanisms. This allows to implement a basic communication layer with very low footprint that doesn't need anything else than a connection to a shared database.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 41% of the total text.

Page 1 of 3

Database bound notification communication between distributed components Database bound notification communication between distributed componentsDatabase bound notification communication between distributed components Database bound notification communication between distributed components

Summary :

The publication is defining a lightweight framework, which can be built into database application server and client components allowing to exchange notification messages from server to client, client to server or even between clients, using the server as relays. This lightweight framework doesn't need any additional network connections but performs the complete notification message exchange through the standard database communication layer (accessed e.g. via JDBC). So all distributed database applications having a server component could use this framework to exchange messages to perform synchronization or maintenance .

    A fundamental property of this publiction is to avoid polling for new information, what would normally be done to exchange information between different database application components that don't have a direct link (but instead just use a common information repository, e.g a set of tables). To achieve this database locking mechanisms are employed to passively "wait" for new data to be available before it is read and then distributed.

    On both sides - on the server and on each client - a background thread is waiting (i.e. it is actually blocked) for the lock to be released by the other side. At the moment the lock is released, the message to transport is read from a database table and propagated to all registered consumers of this background process . So each distributed database application component has its own little "message relay" which is receiving the information from the database. The different modules can register themselves as message consumer to this relay, which forwards arriving information to them. Due to the exploitation locking mechanisms instead of polling, there is no delay of the message transfer, which would otherwise happen due to the polling interval. The notification is almost delivered synchronous to all consumers .

Description:

    All notifications are string based. This way a notification can consist of a complex XML structure or just a simple command. The approach described here needs two database tables and a small stored procedure as database objects beside the notification framework code to exchange the information .

The publication defines
a) a "Notification Table" that is basically used as semaphore between server and client and just holds an ID of the last transmitted notification message .

Furthermore there is
b) a "Message Table" that holds the message by itself, together with a notification ID and other columns allowing the filtering of messages.

    The following diagram shows the flow of operations to send information between server and client.

1

Page 2 of 3


5. Dispatch Message

Server-to- Cli...