Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-06-30
2004-11-30
Amsbury, Wayne (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
Reexamination Certificate
active
06826560
ABSTRACT:
CROSS REFERENCE TO RELATED APPLICATIONS
Applicants claim the foreign priority benefits under 35 U.S.C. § 119 of European Patent Application No. 99113020.4, filed in the European Patent Office on Jul. 7, 1999. The European application is incorporated by reference into this application.
FIELD OF THE INVENTION
The present invention is from the area of notification systems and message brokering. In particular, the present invention relates to the area of processing notifications and in particular of publish and subscribe requests.
BACKGROUND OF THE INVENTION
The present invention has a very general scope. Its basic principles can be applied in any situation in which any notification process or brokering, and in particular publish and subscribe processes take place.
The present invention introduces database technology into these matters of interest. It should be understood that for the sake of this invention the data model of the database system is irrelevant. Also, the database system might manage persistent data on disk or might manage data in main memory, i.e. a main memory database. Nevertheless, the terminology of relational database systems is persistently used in here for simplicity and increased clarity.
In general, a message broker is an instrument which is applied in a situation where messages are often and sometimes periodically sent from a plurality of message sources m to a plurality of message sinks n in a m
relationship. Special cases of 1:m and n:1 occur as well. Message brokers ‘share’ messages in a way that a source—often being any kind of program application—needs to transmit only one message and the broker delivers one or many versions of it to one or more sinks which are often applications as well. Further details on message broker systems can be found in R. Schulte, Message Brokers: A focused approach to application integration, Gartner Group, Strategic Analysis Report SSA R-401-102, 1996.
More particularly, a message broker is like a hub where messages are streaming in and are streaming out. The messages which are streaming into the broker are referred to hereinafter as being published. Messages which are streaming out of the broker are referred to as being subscribed. A subscription request specifies the subset of all incoming messages a particular application is interested in, and the format in which it has to be presented to the subscriber.
For example, various stock exchanges might publish stock data periodically, i.e. the stock data is sent to the message broker. Each stock exchange might use a different format to transfer its data. A subscriber might have registered to all messages about IBM stock data exceeding $103 and might request its delivery in XML format.
In state-of-the-art message brokers that provide publish/subscribe functionality significant effort is spent in managing the published messages and the subscriptions. This management is typically performed by using its own mechanisms. The present invention proposes to use object-relational database technology to implement publish/subscribe functionality.
State-of-the-art message brokers typically deal with messages that are being published and that subscribers would like to know about. However, subscribers are not just interested in messages that are being published, but also in changes that are applied to data stored in one or more tables in one or more databases. The present invention implements this functionality based on object-relational database technology.
Thus, it would be desirable to alleviate this big amount of programming, customizing effort. The above-cited prior art reference analyzes the feasibility of database technology used as a base for message brokering. It concludes that database systems lack many features that are necessary for message brokering, e.g., the middleware designed for performing the brokering, such as interface engines and message switches. Thus, a database technology as a base for message brokering is rejected in the above cited reference as being too difficult and complex to realize, and too slow in performance.
When analyzing the behavior of publish/subscribe technology using a database oriented view, the following observation can be made: a subscription request is similar to a query. Based on what has been specified in the subscription request, messages are filtered out and are delivered to its recipient. But there is a fundamental operational difference between a query and a subscription: A subscription does not operate on all messages stored for example in a message warehouse but only on a single message at a time, namely the message that has just been published to the message broker. Furthermore, typically many subscriptions will be registered with a message broker, i.e. identifying subscriptions with queries will result in the situation in which many queries will have to be evaluated on a single message: This situation reverses the situation typically found in query systems where the number of data items to be inspected exceeds the number of queries by many orders of magnitudes.
The proposal of the present invention to use object-relational database technology for publish/subscribe technology faces two problem areas that must be solved:
Firstly, how to efficiently identify operational data that is relevant to be published and secondly, how to perform subscriptions efficiently based on externalized database technology.
The first problem area results from the fact that most message brokers are not implemented based on database technology, and that in business environments having a natural need for management relevant enterprise data particular modifications of e.g., operational data are often seen as events that are relevant for external applications. This is depicted in FIG.
1
.
For example, if a new tuple is inserted into a table, a person might want to be informed about this fact via a corresponding e-mail, or an application must be invoked because of this, or a message broker in turn has subscribers that want to get this data. Thus, the database may be seen as a source for publications.
In particular, when a message broker is used to manage the subscription requests for the changes in operational data and thus the operational data changes need to be published to the message broker, the importance of pre-filtering of publications becomes obvious. If each of the huge number of changes of operational data is pushed to the message broker which then determines whether or not a subscriber for the subject change exists, lots of data may be processed unnecessarily. This might be a waste of resources. Thus, providing subscription functionality within a database system is beneficial, in general.
Otherwise, without having subscription features natively provided within the database system the modified data has to be transformed into a message, then has to be sent, i.e. published to a separate message broker, and this message broker has to determine all corresponding subscribers. In this approach the database would be considered to be a publisher only, the message broker's subscription engine is used to determine whether or not any subscriber is interested in the modified data.
If no subscriber is interested in this data communication between the database system and the message broker including associated data transformations etc. then much work and traffic is performed in vain putting unnecessary load onto the overall environment. Furthermore, a usage of a separate subscription engine would ignore the fact, that the database system's query capability can be immediately used to process the subscriptions directly without needing a separate message broker engine—this will further improve efficiency.
The second problem deals with efficiency of implementing subscriptions based on database technology itself. Nearly all relational database systems are supporting trigger mechanisms today. Triggers allow the database system to automatically perform an action based on a registered interest on relevant modifications of data. There seems to be a suggestion for r
Leymann Frank
Roller Dieter
Amsbury Wayne
International Business Machines - Corporation
Nguyen Cindy
Sawyer Law Group LLP
LandOfFree
Subscription and notification with database technology does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Subscription and notification with database technology, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Subscription and notification with database technology will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3343021