Release 2 (9.2)
Part Number A96587-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Application Developer's Guide - Advanced Queuing Release 2 (9.2) Part Number A96587-01 |
|
This chapter covers the fundamentals of AQ modeling and design in the following sections:
Figure 7-1 shows a queue table that contains the following queues and messages:
At its most basic, one producer may enqueue different messages into one queue. Each message will be dequeued and processed once by one of the consumers. A message will stay in the queue until a consumer dequeues it or the message expires. A producer may stipulate a delay before the message is available to be consumed, and a time after which the message expires. Likewise, a consumer may wait when trying to dequeue a message if no message is available. Note that an agent program, or application, can act as both a producer and a consumer.
At a slightly higher level of complexity, many producers may enqueue messages into a queue, all of which are processed by one consumer.
In this next stage, many producers may enqueue messages, each message being processed by a different consumer depending on type and correlation identifier. See Figure 7-2.
Figure 7-2 portrays a queue table that contains one queue into which messages are being enqueued and from which messages are being dequeued.
The figure indicates that there are 6 producers of messages, although only four are shown. This assumes that two other producers (P4 and P5) have the right to enqueue messages even though there are no messages enqueued by them at the moment portrayed by the figure. The figure shows that:
According to the figure, there are 3 consumers of messages, representing the total population of consumers. The figure shows that:
The figure portrays the enqueuing of multiple messages by a set of producers, and the dequeuing of messages by a set of consumers. What may not be readily evident in that sketch is the notion of time and the advantages offered by Oracle AQ.
Client-Server applications normally execute in a synchronous manner, with all the disadvantages of that tight coupling described earlier. Figure 7-3 demonstrates the asynchronous alternative using AQ. In this example Application B (a server) provides service to Application A (a client) using a request/response queue.
In this way the client does not have to wait to establish a connection with the server, and the server dequeues the message at its own pace. When the server is finished processing the message, there is no need for the client to be waiting to receive the result. In this way a process of double-deferral frees both client and server.
A message can only be enqueued into one queue at a time. If a producer had to insert the same message into several queues in order to reach different consumers, this would require management of a very large number of queues. Oracle AQ provides two mechanisms to allow for multiple consumers to dequeue the same message: queue subscribers and message recipients. The queue must reside in a queue table that is created with multiple consumer option to allow for subscriber and recipient lists. Each message remains in the queue until it is consumed by all its intended consumers.
Using this approach, multiple consumer-subscribers are associated with a queue. This will cause all messages enqueued in the queue to be made available to be consumed by each of the queue subscribers. The subscribers to the queue can be changed dynamically without any change to the messages or message producers. Subscribers to the queue are added and removed by using the Oracle AQ administrative package. Figure 7-4 shows multiple producers enqueuing messages into queue, each of which is consumed by multiple consumer-subscribers.
A message producer can submit a list of recipients at the time a message is enqueued. This allows for a unique set of recipients for each message in the queue. The recipient list associated with the message overrides the subscriber list associated with the queue, if there is one. The recipients need not be in the subscriber list. However, recipients may be selected from among the subscribers.
Figure 7-4 describes the case in which three consumers are all listed as subscribers of a queue. This is the same as saying that they all subscribe to all the messages that might ever be enqueued into that queue.
The figure illustrates a number of important points:
Figure 7-5 illustrates the same technology from a dynamic perspective. This examples concerns a scenario in which more than one application needs the result produced by an application. Every message enqueued by Application A is dequeued by Application B and Application C. To make this possible, the multiconsumer queue is specially configured with Application B and Application C as queue subscribers. Consequently, they are implicit recipients of every message placed in the queue.
Figure 7-6 shows how a message can be specified for one or more recipients. In this case, Message 5 is specified to be dequeued by Recipient-1 and Recipient-2. Neither of the recipients is one of the 3 subscribers to the queue.
We earlier referred to subscribers as implicit recipients in that they are able to dequeue all the messages placed into a specific queue. This is like subscribing to a magazine and thereby implicitly gaining access to all its articles. The category of consumers that we have referred to as recipients may also be viewed as explicit recipients in that they are designated targets of particular messages.
Figure 7-7 shows how Oracle AQ can adjust dynamically to accommodate both kinds of consumers. In this scenario Application B and Application C are implicit recipients (subscribers). But messages can also be explicitly directed toward specific consumers (recipients) who may or may not be subscribers to the queue. The list of such recipients is specified in the enqueue call for that message and overrides the list of subscribers for that queue. In the figure, Application D is specified as the sole recipient of a message enqueued by Application A.
|
Note: Multiple producers may simultaneously enqueue messages aimed at different targeted recipients. |
Figure 7-8 illustrates the use of AQ for implementing workflows, also knows as chained application transactions. It shows the steps in the workflow performed by Applications A, B, C and D. The queues are used to buffer the flow of information between different processing stages of the business process. By specifying delay interval and expiration time for a message, a window of execution can be provided for each of the applications.
From a workflow perspective, the passing of messages is a business asset above and beyond the value of the payload data. Hence, AQ supports the optional retention of messages for analysis of historical patterns and prediction of future trends.
|
Note: The contents of the messages 1, 2 and 3 can be the same or different. Even when they are different, messages may contain parts of the of the contents of previous messages. |
Figure 7-9 illustrates the use of AQ for implementing a publish/subscribe messaging scheme between applications. Application A is a publisher application which is publishing messages to a queue. Applications B, C, D are subscriber applications. Application A publishes messages anonymously to a queue. These messages are then delivered to subscriber applications based on the rules specified by each application. Subscriber applications can specify interest in messages by defining a rule on message properties and message data content.
In the example shown, application B has subscribed with rule "priority=1", application C has subscribed with rule "priority > 1", and application D has subscribed with rule "priority = 3". Application A enqueues 3 messages (priority 3, 1, 2). Application B receives a single message (priority 1), application C receives two messages (priority 2, 3) and application D receives a single message (priority 3). Thus, message recipients are computed dynamically based on message properties and content. The figure also illustrates how application C uses asynchronous notification for message delivery. Application C registers for messages on the queue. When messages arrive, application C is notified and can dequeue the messages.
In AQ, message recipients can be either consumers or other queues. If the message recipient is a queue, the actual recipients are determined by the subscribers to the queue (which may in turn be other queues). Thus it is possible to fan-out messages to a large number of recipients without requiring them all to dequeue messages from a single queue.
For example, a queue, Source, may have as its subscribers queues dispatch1@dest1 and dispatch2@dest2. Queue dispatch1@dest1 may in turn have as its subscribers the queues outerreach1@dest3 and outerreach2@dest4, while queue dispatch2@dest2 has as subscribers the queue outerreach3@dest21 and outerreach4@dest4. In this way, messages enqueued in Source will be propagated to all the subscribers of four different queues.
You can also combine messages from different queues into a single queue, sometimes described as compositing. For example, if queue composite@endpoint is a subscriber to both funnel1@source1 and funnel2@source2, then the subscribers to composite@endpoint can get all messages enqueued in those queues as well as messages enqueued directly to itself.
Figure 7-10 illustrates applications on different databases communicating using AQ. Each application has an inbox and an outbox for handling incoming and outgoing messages. An application enqueues a message into its outbox irrespective of whether the message is sent locally (on the same node) or remotely (on a different node ). An application dequeues messages from its inbox irrespective of whether the message originates locally or remotely. AQ facilitates all interchanges, treating messages on the same basis.
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|
