KR100324978B1 - message broker apparatus, method and computer program product - Google Patents

Abstract

The present invention provides a message broker data processing apparatus, method, computer program product, and information service providing method which are easy to change software programming. A message broker data processing apparatus that receives messages from a sender application, and determines a receiver application to process received messages and deliver the processed messages, receives an incoming message stream from the sender application. Means for, where each message is arranged as a tuple having at least one field; Means for combining the incoming message stream with database data stored in a database, wherein the database data is also arranged as tuples having at least one field; Means for processing said message stream such that a final message stream is delivered to at least one receiving application.

Description

Message broker apparatus, method and computer program product

Field of invention

The present invention relates to the field of client / server computing (also known as 'distributed computing'), for example, where one computing device requires another computing device to perform some of the client's work.

Background of the Invention

Client / server computing has become increasingly important in the information technology world over the years. This form of distributed computing allows one process ('client') to run on a machine to perform some of its work, for example, on another machine that may be more suitable for performing the work ( On behalf of the server. The client and server may also be two processes running on the same physical machine.

Message queuing data processing techniques are becoming more and more common in today's client / server networks. This technology allows the client computer system to communicate with the server computer system by means of operating system, data format and communication protocol, even though the client computer system and server computer system are very different from each other. Also, due to the asynchronous nature of this technique, the client can send a message to the server and the server can store the message in a queue and later process and reply to the message. This is very different from synchronous client / server models that require the client to communicate with the server in real time (eg, the client waits for the server to respond before the client performs another task).

Message queuing and commercially available message queuing products are published by McGraw-Hill in 1994, 'Messaging and Queuing Using the MQI' by B. Blakeley, H.Harris and R. Lewis, and the publications available from IBM. An Introduction to Messaging and Queuing '(IBM Document No. GC33-0805-00) and the MQSeries-Message Queue Interface Technical Reference (IBM Document No. SC33-0850-01). IBM and MQSeries are trademarks of IBM Corporation. IBM's MQSeries messaging software products synchronize transactions in messages within logic units of operation according to a messaging protocol that ensures once and once-only message delivery even in the event of a system or communication failure. Support message. MQSeries products deliver acknowledgment by using complex recovery functions and avoiding final deletion of messages from storage on the sender's system until it has been securely stored by the recipient's system. Prior to committing message delivery based on the confirmation of successful storage, deleting the message from the sender's system store and inserting the message into the receiver system's store both remain 'in doubt' and fail. ) Can be automatically backed out if Transaction concepts and recovery functions associated with this messaging transport protocol are described in International Patent Application No. 95/10805 and US Patent 5465328 and incorporated herein by reference.

Because relational databases are commonly used as built mechanisms for storing and retrieving large amounts of related data, IBM's DB2 products or Microsoft's access products (DB2 is a trademark of IBM Corporation, and access is a trademark of Microsoft Corporation). It is becoming more and more common to combine messaging and queuing systems with relational database systems.

Sun Microsystems, for example, describes a messaging and queuing system used to perform publish / subscribe functions (European Patent Application No. 806,731, published November 17, 1996). You specify a topic for each message, but the servers act as publishers and publish the message. Clients act as subscribers and specify the topics they want to receive messages from. Messaging and queuing brokers are placed between clients and servers and serve to distribute messages issued to the appropriate clients. The system allows a database to be provided as a publishing server so that large amounts of built data can be published to the network. The database may also be provided as a citation client, storing received publication messages for easy and structured retrieval of large amounts of messages. Such a system does not describe any specific integration between messaging and queuing systems and relational database systems.

Oracle specifies their Oracle8 Advanced Queuing (AQ) system ('Oracle8' and 'Advanced') by having the client application (subscriber) submit a structured query to a messaging and queuing broker to specify the publication message that the subscriber wishes to receive. TQ Queuing is a trademark of Oracle Corporation. The ability of a subscriber to use a standard database language such as Structured Query Language (SQL) to specify the topic of the Internet is a very high level of specificity in that it accurately represents the type of publication messages that the subscriber wants to receive. Consider the castle. For example, a subscriber can use a standard SQL query statement to specify to receive all accrued IBM stock quotes with a stock price of more than 100 US dollars per share. In addition to the SQL statement, the subscriber may also use a variety of visual relational database programming techniques, such as those provided by Microsoft Access products, to make it easier for the programmer to accurately specify the types of publication messages that the subscriber wants to see.

Open Horizon takes this integration and goes a step further by allowing messaging and queuing agents to add subject matter to the contents of published messages before sending messages to demanding subscribers. Ambrosia is a trademark of Open Horizon. The messaging and queuing broker receives published messages into the input queue. Like Oracle products, standard SQL techniques are used to specify exactly the type of publication messages a subscriber wants to see. However, Ambrosia products may further collate information into publication messages with records stored in a relational database. In particular, once a publish message is received, a portion of the data from the database records is appended to the contents of the publish message to produce a publish message with more details than the publish message originally received by the messaging and queuing broker. do. For example, if a publication message is received on the broker's input queue that specifies that IBM stocks, which are $ 125 per share, are listed, the broker is responsible for the identifier of the client (for example, C23) and the IBM stock currently owned by the client. Information including amounts (eg 225 weeks) may be programmed to retrieve from a relational database. The information retrieved from the database is combined with the issuance information to generate a more detailed message that customer C23 owns 225 IBM stocks currently traded at $ 125 per share, and then sent to customer C23 previously registered as a subscriber. .

Although Ambrosia products provide significant value over the other products mentioned above, the drawback is that dedicated software code must be written so that it can specify exactly how publication messages will be combined with database records.

ActiveWeb's ActiveWeb (trademark of Active Software) message broker product is similar to Open Horizon's Ambrosia product in that database content can be added to publish messages to add value to the publish message. The active web can use a specific piece of software code called a database adapter to perform a combination (eg, combining) operation. These adapters extract data from publication messages, convert this data into the exact type of database query required by the database, retrieve data from the database, and perform specific combination operations on the publication message and database data. Is required to do.

ActiveWeb therefore also has the disadvantage that it is necessary, for example, to provide a dedicated part of the software in order to perform a combination operation combining database records and publish messages. Modification of such software requires the user to be familiar with the programming structure and language of the dedicated portion of the software. Thus, although the programmer knows that it is easy to modify the rest of the message broker, it is necessary to switch to a new programming environment to modify the dedicated part of the software that performs the combinatorial operation.

1 is a block diagram illustrating the basic set up of a relational message broker according to a preferred embodiment of the present invention.

2 is a more detailed block diagram of a relational message broker in accordance with a preferred embodiment of the present invention.

3 is a block diagram illustrating a modified version of the relational message broker of FIG.

<Explanation of symbols for the main parts of the drawings>

11... publisher

12... Queue manager

13... Managed Message Broker

14... Database

15... Subscriber

According to one aspect, the present invention provides a message broker data processing apparatus for receiving messages from a sender application and processing the received messages to determine to which recipient application the processed messages are delivered, wherein each message comprises at least one field. Means for receiving an incoming message stream from a sender application, while being arranged as tuples with a; Means for combining the incoming message stream with database data stored in a database, wherein the database data is also arranged as tuples having at least one field; Provided is a message broker data processing apparatus comprising means for processing a stream of messages such that a resultant stream of messages is sent to at least one receiving application.

Advantageously, said means for receiving, means for combining, means for processing use a plurality of interconnected processing nodes to form a network of processing nodes, the processing functionality of each node being a standard relational language. As defined by the relational representation, streams of message tuples are passed between a plurality of nodes. In addition, for two adjacent nodes in the network, Node 1 and Node 2, the output of the relational expression that defines the function of Node 1 is interpreted as a stream of message tuples by the input of the relational expression that defines the function of Node 2.

Preferably, the means for receiving is in communication with a queue manager.

In a preferred embodiment, the sending application is a publisher and the receiving application is a subscriber.

Preferably, the standard relational language is a structured query language and visual database tools are used to generate relational representations that define the functionality of the node.

In one embodiment, each message tuple in the stream of message tuples present between two nodes has the same set of fields. In another embodiment, in a stream of message tuples existing between two nodes, each message tuple in the message stream does not necessarily have the same set of fields. Preferably, in the latter embodiment, the fields used in the relational representation that specify the functionality of the node but are not specified in the special message tuple of the stream entering the node are assigned invalid values.

In one embodiment, the apparatus is included in a single data processing unit, while in other embodiments the apparatus is included in a plurality of interconnected data processing units.

According to a second aspect, the present invention provides a method for performing the functions discussed in the first aspect.

According to a third aspect, the present invention provides a computer program product for performing the functions discussed in the first aspect when executed on a computer.

According to a fourth aspect, the present invention provides a method of providing an information service to a customer using the message broker data processing apparatus of the first aspect, comprising: (a) a reference from a customer as to which message the customer wants to receive; receiving a criteria; (b) receiving messages issued from the publisher; (c) comparing the criteria received from the customer with the issued messages; (d) providing an information service comprising sending issuance messages meeting the criteria received from the customer to the customer.

Since the present invention provides incoming data to the broker as a stream of message tuples, it is easy to combine incoming data with data in the database. Because database data is also organized in tuples. Thus, the data processing step of combining the messages in the data stream with the data from the database can be seamlessly integrated into the overall message broker system.

By seamlessly integrating these data processing elements into the overall message broker system, the same standard relational methods, such as visual tools, interfaces and models, used to program different parts of the broker, how the stream of data is from the database It may be used during programming to specify whether and must be combined (eg, merged and combined). This facilitates programming the entire broker system since the same tools can be used consistently.

The ability to use such relational techniques (especially visual tools) with respect to a perfect messaging broker makes it very easy to optimize the parts of the broker that may be inefficiently programmed.

In addition, the flow of messages through the broker is much more efficient due to the seamless integration into the unit of the overall broker system that combines incoming data streams with stored database data (compared to conventional Ambroseia and the Active Web).

Finally, the seamless integration associated with the present invention makes it much easier to treat the processing that occurs in other parts of the message broker as processing occurring within a collation unit as part of the overall transaction that also takes into account. In other words, tracking all aspects of the system-wide processing becomes much easier if all elements of the broker can be treated identically.

In FIG. 1, a publisher data processing unit 11 is provided to supply live up-to-the-minute data that subscribers would like to receive (in preferred embodiments, stock data is provided). It is used as a representative form of broker use, and also because stock data is constantly changing and a good example of data that is required on an immediate basis by many subscribers). The publisher data processing unit 11 may run on any of a number of available computer processing platforms.

Messaging and queuing units, such as IBM's MQseries product (represented by queue manager 12), are placed between publisher data processing unit 11 and subscriber data processing unit 15. Subscriber processing unit 15 may run on any of a number of available computer processing platforms, and the selected platform may be different from the platform used by issuer 11. Known queue manager 12 (such as MQseries) takes care of all necessary data format conversions (e.g., protocols, etc.) in order for publisher 11 and subscriber 15 to communicate with each other in an asynchronous manner (e.g., Subscriber 15 need not be active when messages are being issued by issuer 11, messages are stored in a queue and subscriber 15 can retrieve messages when subscriber 15 becomes operational again. ). A separate queue manager 12 is typically assigned to each issuer and subscriber, with the queue managers interacting to control the flow of messages between units. However, for ease of explanation, the queue manager 12 will be described as a single entity.

It should be noted that the issue message and the subscriber 15 can be executed on the same machine. In such a case, the need for data format conversion is reduced and the queue manager 12 simply routes the publish messages from the publisher application to the subscriber application.

The queue manager 12 sends the received messages to the relational message broker 13 (the relational message broker 13 may be executed on an intermediary data processing unit or a plurality of interconnected data processing units). The relational message broker 13 processes the messages (as described below) and returns them back to queue manager 12 to place them on the output queues of the appropriate subscribers so that the processed messages can be retrieved by the subscribers. For simplicity, only one such subscriber (and issuer) is shown in FIG. 1, but in general there will be multiple subscribers and issuers.

As indicated by the dashed line in FIG. 1, it should be noted that by bypassing queue manager 12, relational message broker 13 can be used to operate in a synchronous mode. In fact, the broker 13 can be used in an overall synchronous environment without the provision of the queue fixing means 118. This relates to, for example, a system that eliminates the need for the functions of queue manager 12 because the publisher and subscriber are always in operation.

In performing the processing, the broker 13 often accesses the database 14. For example, the information in the publish messages is joined with the information stored in the database to produce a more meaningful message and send it to the subscriber. For example, the issue message may indicate that IBM stock prices are up to 150 US dollars per share, and a database record stored in database 14 may indicate that a particular customer with identifier C3 owns 77 IBM shares. . The combining operation performed by the broker 13 will gather all of this information to produce a message longer than the issued message indicating that client C3 currently owns 77 shares of IBM stock worth 150 US dollars per share. .

As is well known, data stored in a database is organized into rows called tuples. For example, Table 1 shows three tuples.

(Samples of data stored in the database) company customer Volume IBM C3 77 IBM C2 44 Ford C3 120

The first tuple indicates that customer C3 has 77 shares of IBM stock. The second tuple indicates that customer C2 has 44 shares of IBM. The third tuple indicates that customer C3 has 120 shares of Ford.

According to a preferred embodiment of the present invention, the issue messages sent by the issuer 11 are also organized in tuples. Thus the stream of issue messages is a temporary ordered list of tuples. For example, Table 2 shows a sequence of two messages, each organized into tuples.

(Sample tuples in the message stream) company price IBM 160 Ford 44

The first tuple indicates that IBM stock is currently worth 160 US dollars per share. The second tuple indicates that the Ford stock is currently worth 44 US dollars per share.

Each message tuple in the stream may have the same set of fields (eg, company and price fields). Alternatively, some message tuples in the stream may have a different set of fields than fields not specified for a particular message tuple to which a null value is assigned. In addition, the tuples shown in Table 2 have simple data (eg numbers or strings), but the fields may also include any additional structure, eg an array or nested tuples. .

As will be evident from the more detailed block diagram of the relational message broker 13 shown in FIG. 2 and the discussion below, with the following plurality of examples, both the issue messages and the database data are arranged in tuples, so the issue message And desired collations of database data can be specified using standard relational representations.

In FIG. 2, the publisher application P1 11 sends a stream of published messages arranged as a tuple to the queue manager 12 which delivers the stream to the relational message broker 13 for processing and assigning messages to particular subscribers. The stream of messages is then sent back to queue manager 12 for transmission to three subscriber applications S1 15a, S2 15b, S3 15c. The relational message broker 13 is arranged as a set of interconnected processing nodes 21, 22, 23 to form a network. These processing nodes may all be located on the same data processing machine and distributed across a plurality of interconnected data processing machines. The processing function of each node is defined by a relational representation in a standard relational language (eg SQL query), as described in more detail below.

Once within the broker 13, processing is done by the filter node 21 which first allows only certain messages to pass through the filter and filters out (discards) some of the issued messages for the stream of published messages. For example, the stream of stock quotes issued from P1 will generally be related to the stock quotes of a very large number of companies. Perhaps subscribers S1, S2, S3 are only interested in IBM and Ford stocks. Thus, filter node 21 can only pass the filter if the message relates to the stock price of IBM or Ford. Since the function of the filter node 21 is a very general relational database operation (commonly referred to as a select), the function of the filter node 21 is very well known in the relational database art. The processing function of the filter node 21 is defined by a relational representation using, for example, an SQL SELECT statement to express exactly what messages can pass through the filter.

The output of the filter 21 is connected to the input of the combining operator 22 which receives the filtered message stream (only relevant for IBM and Ford stock quotes) as the first input. Joining node 22 receives a second input from database 14. When the join node 22 receives a publish message from the output of the filter node 21, the appropriate database tuples are accessed and read from the database 14 to join the publish messages. The function of the combine node 22 is Because of the very common relational database operation, the function of the joining node 22 is very well known in the relational database art. The processing function of the joining node 22 is defined by a relational representation using, for example, an SQL INNER JOIN statement to express exactly how the message stream is combined with the database data.

For example, using the database data in Table 1, when a first issued message tuple (in line 1 of Table 2) is received by broker 13 indicating that the IBM stock price is currently 160 US dollars per share, Since the relational representation that defines this node is intended to pass through message tuples related to IBM or Ford stock prices, the first issued message tuple passes through filter node 21. When this message tuple arrives at the joining node 22, the joining node combines this message tuple and the tuple shown in the first line of Table 1 to form a longer tuple as shown in the first line of Table 3. (This tuple represents customer C3 currently holding 77 IBM stocks worth 160 US dollars per share).

(Sample tuples in the message stream at the output of the joining node) company price customer Volume IBM 160 C3 77 IBM 160 C2 44 Ford 44 33 120

The output of join node 22 is then sent to queue manager 12 for inclusion in the queue at S3. Subscriber S3 15c then retrieves messages from the queue each time subscriber S3 is ready to retrieve information. According to the node structure of FIG. 2, S3 will receive messages regarding all customers who own IBM or Ford shares. S3 is, for example, an auditor who wants to obtain stock ownership data of all customers.

This same message tuple (shown in the first line of Table 2) is also combined at the joining node 22 with the database tuple shown in the second line of Table 1, and consequently, as shown in the second line of Table 3. The same longer tuple, which indicates that customer C2 owns 44 shares of IBM, currently worth 160 US dollars per share. The output of this joining node 22 is then sent to queue manager 12 for inclusion in the queue at S3. Subscriber S3 15c then retrieves messages from the queue each time subscriber S3 is ready to retrieve information.

The output of join node 22 is also sent to queue manager 12 for inclusion in the queue at S2. In particular, the output of the joining node 22 is sent to the filter node 23 which is programmed to pass only message tuples related to the customer C2. The processing function of the filter node 23 is defined by a relational representation using, for example, an SQL SELECT statement to express exactly which messages are allowed to pass through the filter. The message tuple shown in the second line of Table 3 is related to C2 and therefore will be sent to queue manager 12 for inclusion in the queue of S2 through filter node 23. Subscriber S2 15b then retrieves messages from the queue each time subscriber S2 is ready to retrieve information.

When the second issued message tuple (as shown in line 2 of Table 2) reaches the filter node 21, the message tuple is the Ford stock price (in particular, this message tuple is currently at 44 Ford stock price per share). Will be passed through filter node 21. Once through the filter node 21, this message tuple goes to the joining node 22 and is combined with the database tuple shown in the third line of Table 1 (since this message tuple is a database tuple related to Ford). Longer tuples as shown in line 3 (this tuple indicates customer C3 currently has 120 Ford shares worth 44 US dollars per share). This message tuple output from joining node 22 is then sent to queue manager 12 for inclusion in the queue at S3. Subscriber S3 15c then retrieves messages from the queue each time subscriber S3 is ready to retrieve information. This message tuple output from the joining node 22 (relative to the customer C3) cannot pass through the filter node 23 because it allows the filter node 23 to pass only message tuples related to the customer C2.

Suppose subscriber S1 is very interested in IBM and Ford stocks but has not bought and plans to buy shares of either. For example, suppose S1 is a financial agent that makes business decisions based on the current stock prices of IBM and Ford stocks. In this case, the database 14 does not contain any information that S1 may wish to and thus does not need to be involved in the joining node 22. Thus, the second output is provided to the filter node 21 and all issued messages (stock prices relating to IBM and Ford stock prices) passed by the filter node 21 are output from the second output. These messages are then delivered to queue manager 12 for inclusion in the queue at S1. Subscriber S1 15a then retrieves the message from the queue whenever subscriber S1 is ready to retrieve information.

Thus, the function of each node of the broker 13 is defined entirely in database-specific terms. Each node has a relational representation expressed in a standard relational language such as SQL. The output of the relational representation of a node is a stream of message tuples provided as input to the relational representation of an adjacent node. The filter nodes 21, 23 use the general SELECT function of the database relational algebra. The join node 22 uses the generic INNER JOIN function of database relational algebra. Although the combination that occurs between the database 14 and the publish messages has been described in detail as a 'join' operation, many other relational algebra are also 'intersection' or 'compute' or 'integration'. It can be implemented to combine database data with publication messages, such as 'union'.

Some examples of relational representations that can be used to define the functionality of the nodes are described herein.

Example 1: Filtering

In this example, the first filter node 21 is defined in SQL as follows.

SELECT *

FROM Stock

WHERE Company = 'IBM' or Company = 'Ford'

Example 2: join

Let the output stream from node 21 be Q21 and the database relationship of the customer that contains the information is called holding. At this time, the joining node 22 is defined as follows.

SELECT Q21. *, Customer, Quantity

FROM Q21 INNER JOIN Holding

ON Q21.Company = Holding.Company

Example 3: join dependent filtering

If the output stream of the join node is Q22, the filter node 23 depending on the customer field output from the join is expressed as follows.

SELECT *

FROM Q22

WHERE Customer = 'C2'

Example 4: computation

The total price for each transaction can be calculated as follows.

SELECT *, Price * Quantity AS TotalValue

FROM Q22

Example 5: negative filtering (difference)

Subscribers do not want to see stock information about companies whose stock trading is prohibited by local policy. The list of such companies is maintained within the Proscribed relation of the database. A subscription is made up of the following SQL rules:

SELECT *

FROM Stock

WHERE Company NOT IN

(SELECT Company FROM Proscribed)

Example 6: Archive

An administrator sets up a dated archive by inserting message tuples of input stream stock into a relationship.

INSERT INTO StockArchive

SELECT *, Time () as TimeAudit

FROM Stock

Example 7: Update

The manager wants to keep track of the latest prices for each company in the database table StockStock.

UPDATE StockLatest INNER JOIN Stock

ON StockLatest.Company = Stock.Company

SET StockLatest.Price = Stock.price, StockLatest.LogTime = Now ();

Example 8: Compound expression

SQL can combine several calculations into a single expression. The following expression is a combination of joins, filters, and computations.

SELECT Q21 *, Customer, Quantity, Price * Quantity as TotalValue

FROM Q21 INNER JOIN Holding

ON Q21.Company = Holding.Company

WHERE Customer = 'C2'

Once the broker system is invented, it is very easy to make changes to add additional functionality. For example, the calculation node 24 (as shown in FIG. 3) may be a joining node such that the final message may include another field that is the total present value of the stock ownership of each customer in the relevant company. May be added to the output of 22. In other words, the calculation node 24 multiplies the stock price by the number of shares the customer has and provides the product as a separate field (called 'total value'). Thus, Table 3 will be as follows.

company price customer Volume Total value IBM 160 C3 77 12320 IBM 160 C2 44 7040 Ford 44 C3 120 5280

In addition, changes to existing nodes (e.g., 22) can be readily made by modifying the relational representation that defines the node's function. Since the joining node 22 and the filter nodes 21, 23 can be seamlessly integrated into a network of interconnected nodes with a stream of message tuples passed between the nodes, the relational representation of any node is easily It can be modified. There is no need to switch to different types of programming for any nodes (as is the case in the prior art discussed above).

Since the broker's functionality is implemented in database specific terms, it is very easy to change the functional units of the broker 13 using standard visual tools available for programming relational database management systems. Microsoft's access products, for example, provide such visual tools. Relational database programmers are already familiar with these tools. Thus, database programmers will find it easy to set up the structure of the nodes of the broker 13 (eg, 21, 22, 23). For example, if a change to the joining node has to be made at the customer's request, it can be easily performed by the database programmer without having to learn new programming techniques, thereby significantly reducing system development costs.

In the preferred embodiment each of the nodes is defined in relational representations, but some of the nodes may be implemented in other ways, and in that case the benefit of the invention is of course not reduced.

In a preferred embodiment of the present invention, the relational message broker of a value-added publish / subscribe application has been described as it is a very useful environment for the present invention. However, the present invention will also be useful in many other environments, including workflow streams, where the transmitted message is delivered to any of a plurality of recipients depending on who is not busy at the time. In the workflow environment, the broker will access the database 14 to determine the data for each recipient in order to make a decision as to which recipient a work request message should be assigned to.

One embodiment of the present invention provides a relational message broker function on a server computer connected to the Internet such that publisher and subscriber applications can access the Internet server as clients through world wide web browser applications. In this way, the broker 13 sends the publication messages via the Internet to the subscriber's 15 web browser application when the publication message meets the criteria already established by the subscriber (by using the web browser application again to contact the Internet server). Will push.

Claims (17)

A message broker data processing apparatus for receiving messages from a sender application and processing the received messages to determine to which recipient application the processed messages are delivered. Means for receiving an incoming message stream from the sender application, wherein each message is arranged as a tuple having at least one field; Means for combining the incoming message stream with database data stored in a database, wherein the database data is also arranged as tuples having at least one field; Means for processing the message stream such that a final message stream is delivered to at least one receiver application. Containing Message broker data processing device. The method of claim 1, The means for receiving, means for combining, means for processing use a plurality of interconnected processing nodes to form a network of processing nodes, the processing function of each node being in relational representation in a standard relational language. Stipulated by Message broker data processing device.
The method of claim 2, A stream of message tuples is passed between a plurality of nodes Message broker data processing device.
The method of claim 3, For two adjacent nodes of the network, Node 1 and Node 2, the output of the relational expression that defines the function of Node 1 is interpreted as a stream of message tuples by the input of the relational expression that defines the function of Node 2. Message broker data processing device.
The method of claim 1, The means for receiving communicates with the queue manager. Message broker data processing device.
The method of claim 1, The sending application is the publisher and the receiving application is the subscriber Message broker data processing device.
The method of claim 2, The standard relational language is a structured query language. Message broker data processing device.
The method of claim 2, Visual database tools are used to create relational representations that define the functionality of a node. Message broker data processing device.
The method of claim 3, Each message tuple in the stream of message tuples existing between two nodes has the same set of fields Message broker data processing device.
The method of claim 3, In a stream of message tuples existing between two nodes, each message tuple in the stream does not necessarily have the same set of fields. Message broker data processing device.
The method of claim 10, Fields used in the relational representation that specify the functionality of the node that are not specified in the special message tuple of the stream input to the node are assigned invalid values. Message broker data processing device.
The method of claim 1, The apparatus is included in a single data processing unit Message broker data processing device.
The method of claim 1, The apparatus is included in a plurality of interconnected data processing units Message broker data processing device.
A message broker data processing method for receiving messages from a sender application and processing the received messages to determine to which recipient application the processed messages are delivered. Receiving an incoming message stream from the sender application, wherein each message is arranged as a tuple having at least one field; Combining the incoming message stream with database data stored in a database, wherein the database data is also arranged as tuples having at least one field; Processing the message stream such that a final message stream is delivered to at least one receiver application. Containing Message broker data processing method. When executed on a data processing apparatus, stored in a computer readable storage medium for performing a message broker data processing method that receives messages from a sender application and processes the received messages to determine to which recipient application the processed messages are delivered. In a computer program product, the method is Receiving an incoming message stream from the sender application, wherein each message is arranged as a tuple having at least one field; Combining the incoming message stream with database data stored in a database, wherein the database data is also arranged as tuples having at least one field; Processing the message stream such that a final message stream is delivered to at least one receiver application. Containing A computer program product stored on a computer readable storage medium. The method of claim 1, The message broker data processing device is located on an internet server and at least one of the transmitting application and the receiving application uses a world wide web browser application. Message broker data processing device.
A method of providing an information service to a customer using the apparatus of claim 1, (a) receiving criteria from a customer as to which message the customer wants to receive; (b) receiving issuing messages from the issuer; (c) comparing the criteria and the issued messages received from the customer; (d) delivering to said customer issuance messages meeting said criteria received from said customer; Containing How to Provide Information Services.