Release 5.0
Part Number A90251-01
 Contents |
 Index |
| Oracle9i Lite Developer’s Guide for AQ Lite Release 5.0 Part Number A90251-01 |
|
This document introduces AQ Lite by considering the requirements for message queuing in mobile enterprise applications. Topics include:
Oracle AQ Lite is a powerful message queuing service that provides reliable message communication between mobile devices and Oracle servers. AQ Lite is based on Oracle8i's Advanced Queuing (AQ) feature. AQ Lite provides a seamless extension of Oracle8i AQ functionality to mobile devices.
Developers should become familiar with the functionality of Oracle8i AQ before developing applications in AQ Lite. See the Oracle8i Application Developer's Guide - Advanced Queuing for more information.
To use AQ Lite with Oracle8i AQ, you need:
This section illustrates some of the benefits of using AQ Lite in the development and deployment of mobile enterprise applications.
The AQ Lite Sample Application included with Oracle Lite provides a sample implementation of the application described in the following scenario. See Appendix B, "AQ Lite Sample Application" for more information.
LDB Sales is a third-party sales firm for a number of major software companies. The 1,200 members of its nationwide sales force spend most of their work day visiting software development firms and corporate clients in their designated regions. During these visits the salespeople take product orders, and provide their customers with information on new software products. Each salesperson uses a laptop running LDB Sales' field sales application. The LDB Sales data server is located at corporate headquarters in San Francisco, California. The company's processing center is located in Houston, Texas. The sales application software enables sales personnel to:
Robert is a sales associate for LDB Sales. His sales region encompasses software development firms in Boston, Massachusetts. During a typical day, Robert receives 30 or more product orders from his customers. As he receives each order, he enters it into the sales application on his laptop (Oracle Lite Database 1). Once he enters and saves an order, the sales application places the order in an "outbox" along with the other orders taken that day. When Robert returns to his home office at the end of the day, he dials into the LDB Sales data server (Oracle8i server). Once connected to the server, Robert clicks the "Send Orders" button in his sales application.
The sales application forwards all new orders for that day from the outbox on Robert's laptop to a corresponding central order queue on the data server. At the same time, the sales data server forwards acknowledgements of the previous day's orders. The server also forwards updated contact or product information specifically addressed to Robert to the "inbox" on Robert's laptop. The sales application automatically updates the local database on Robert's laptop with the new data.
At the order processing center (Oracle Lite Database 2). The order processing application retrieves Robert's orders from the data server. After submitting the new orders to the appropriate vendors, the order processing application generates an acknowledgement for each order. The order processing application then forwards the acknowledgements back to the sales data server where Robert can retrieve them the next time he connects.
This simple scenario describes an application in which messages are exchanged between a server and multiple mobile client devices. One critical issue in such an environment is the very limited amount of time that the mobile clients are actually connected to the server.
Applications on the mobile clients and the server generate messages offline and address them to their intended recipients. The applications on the mobile clients and the server must be able to exchange the messages they generate and address offline quickly and reliably within a small window of connectivity. They must be able to do this regardless of whether the receiving application is available to process the messages at the time they are sent.
In traditional client/server architectures the exchange of messages is based on the request-reply paradigm, often termed synchronous, online, or connected. In this model a program sends a request to another program and waits (blocks) until the reply arrives. This close coupling of the sender and receiver of the message is suitable for programs that need to get a reply before they can proceed.
The major drawback to this model is that all the component programs must be available and running for the application to work. This makes synchronous communication especially unsuitable for mobile application environments like the one described in the Sample Scenario. Mobile client devices can only send and receive messages when they are connected to the server. If the server application is unavailable during this brief interval the mobile client applications can not proceed with their work.
In the asynchronous, disconnected, or deferred model programs in the role of producers place messages in a queue and then proceed with their work. Programs in the role of consumers retrieve messages from the queue and act on them. This model is ideally suited to the type of mobile application described in the Sample Scenario. The client applications can generate and store messages in a queue while offline. When the mobile devices are connected to the network all stored messages are forwarded to their corresponding queues on the server. At the same time, messages destined for the mobile clients are forwarded from queues on the server to the designated queues on the client devices.
Networks, computing hardware, and software applications fail occasionally. For asynchronous messaging to work correctly in the presence of failures, messages must be stored persistently, and processed exactly once. In other words, messaging must be persistent.
Applications may have to handle multiple unprocessed messages arriving simultaneously from external clients or from internal programs. These conditions may exceed an application's processing capacity. Similarly, the communication links between databases may not be available all the time or may be reserved for some other purpose. Also, external clients or internal programs may not be ready to receive the processed messages. If the system is unable to process these messages immediately, the application must have a mechanism for storing the messages until they can be processed.
AQ Lite provides developers the tools to implement asynchronous and persistent messaging systems for mobile applications. Using AQ and AQ Lite, applications running on mobile devices can exchange messages with applications running on servers or other mobile devices, and store them in AQ Lite message queues. When the user connects the mobile device to an Oracle8i server, the stored messages are propagated to a corresponding AQ message queue on the server. At the same time, designated messages on the server are propagated to the message queue on the mobile device.
The following table lists some general benefits of using Oracle AQ Lite:
This section describes the basic components in an AQ Lite system.
A message is the smallest unit of information inserted into and retrieved from a queue. A message consists of:
The control information represents message properties used by AQ Lite to manage messages. The payload data is the information stored in the queue and is transparent to AQ Lite. A message can reside in only one queue. A message is created by the enqueue call and consumed by the dequeue call.
A queue is a repository for messages. Queues are created, deployed, and dropped using AQ Lite. There are three types of queues:
A master queue is the central queue that is associated with one or more client queues. Master queues reside on the Oracle8i server.
Client queues reside on an Oracle Lite client device and share the same queue name as their master queue on the server. A client queue can only exchange messages directly with its master queue.
From the user's perspective, client and master queues function as a single queue. Messages placed in the master queue are propagated to the client queue where they can be dequeued by the user. Likewise, messages that the user enqueues in the client queue are propagated to the master queue where they can be accessed by other users.
A stand-alone queue resides on an Oracle Lite client device and is used to exchange messages between local applications. A stand-alone queue does not have a corresponding master queue, and cannot propagate messages to or from a server.
Queues are stored in queue tables. Each queue table is a database table that contains one or more queues.
An agent is an end user or an application that accesses messages in a queue. There are two types of agents:
Any number of producers and consumers may be accessing a queue at a given time. Agents insert messages into a queue and retrieve messages from the queue by using the AQ Lite Operational Interface.
An agent is identified by its name, address, and protocol. The name of the agent may be the name of the application or a user name assigned by the application.
A single message can be designated for consumption by multiple consumers. There are two ways to accomplish this.
This section provides an overview of features that developers can implement using AQ Lite.
Deployment is the process of setting up and initializing the Oracle Lite client queues and establishing the propagation relationship between the client queues and the master queue on the Oracle8i server.
Queue objects are first created in the Oracle8i server database. Deployment establishes identical queues on the Oracle Lite client database. Included in this deployment are the definitions required for propagation between queues.
AQ Lite requires no administration on the Oracle Lite client site. Once the queue relationships are set up on the Oracle8i server, each AQ Lite client executes deployment to establish the queue objects in the local Oracle Lite database. No further maintenance is required.
AQ Lite Propagator is a utility that transports messages between client queues in Oracle Lite databases and master queues in Oracle8i databases. A sales application running on a laptop can, for example, place product order messages in a queue named "Orders" in the local Oracle Lite database. AQ Lite Propagator dequeues the order messages from the local "Orders" queue and propagates them to the "Orders" master queue on the Oracle8i server. During the same propagation, AQ Lite Propagator dequeues order acknowledgment messages addressed to the client device from the "Orders" master queue on the server and enqueues them in the queue on the client device.
The following AQ Lite features support the process of producing messages by enqueuing them into a queue.
AQ Lite uses the enqueue() and propEnqueue() methods to differentiate between messages enqueued by local applications and those enqueued by AQ Lite Propagator. AQ Lite Propagator uses propEnqueue() to enqueue messages from the server into the Oracle Lite client queue. This ensures that messages enqueued to the client device are not propagated back to the server. Applications running on the Oracle Lite client use enqueue() to place messages bound for the server into the local queue. This ensures that the messages are not dequeued and consumed by other local applications. Local applications use propEnqueue() to enqueue messages for consumption by other local applications.
Users can assign identifiers to messages to establish correlations between them. This enables users to retrieve groups of related messages.
Users can specify the order in which messages are dequeued using priority or sort ordering. If priority ordering is used, each message is assigned a priority at enqueue. At dequeue time messages are removed from the queue in the order of their priority. If priority ordering is not used, messages are dequeued based on their position. Users can specify sorting properties to order messages in a queue.
If several consumers act on the same queue, each consumer gets the first message that is available for immediate consumption. Messages that are being dequeued by other consumers are skipped.
The following AQ Lite features support the process of retrieving messages by deqeuing them from a queue.
AQ Lite uses the dequeue() and propDequeue() methods to differentiate between messages dequeued by local applications and those dequeued by AQ Lite Propagator. AQ Lite Propagator uses propDequeue() to dequeue messages bound for the master queue on the server from the Oracle Lite client. Applications running on the Oracle Lite client use dequeue() to dequeue messages from the local queue.
A message in a queue can be retrieved by multiple recipients without the need for multiple copies of the same message in the queue.
Messages belonging to one queue can be grouped to form a set related to a single transaction. The queue must be created in a queue table that is enabled for message grouping. All messages belonging to a group must be created in the same transaction, and all messages created in one transaction must belong to the same group. This feature allows users to segment complex messages into simple messages. Messages directed to a queue containing invoices, for example, could be constructed as a group of messages starting with a header message, followed by messages representing details of the invoices, followed by a trailer message.
Users can consume messages from a queue in several ways. Users can select the first message in the queue, and then navigate backwards and select any message in the queue sequence. Users can filter messages in a queue by specifying a correlation identifier. Users can also retrieve a specific message using its unique message identifier.
A dequeue request can either browse or remove a message from a queue. If a message is dequeued in browse mode, it remains available for dequeue by other consumers. If a message is dequeued in remove mode, it is deleted from the queue and cannot be accessed by other consumers.
The AQ Lite Java API supports both the administrative and operational features of AQ Lite. The AQ Lite Java API is fully compatible with Oracle8i AQ. See Appendix A, "AQ Lite Java API" for more information.
AQ Lite enables you to implement two basic queuing configurations:
These two configurations represent the most basic queuing systems that can be implemented in AQ Lite. They may be considered the fundamental building blocks of more complex AQ Lite queuing systems. By reproducing these configurations, combining them in various ways, and extending their functionality into Oracle8i AQ, you can develop complex queueing systems to meet your unique messaging requirements.
In the master-client queue configuration, messages are exchanged between one master queue on an Oracle8i server and corresponding client queues residing on one or more Oracle Lite devices. Messages are exchanged between client and server queues through propagation. Client queues receive the same queue name as their master queue. Client queues can only exchange messages directly with their master queue.
The following scenarios illustrate some possible variations on the master-client queue configuration.
In this scenario messages are exchanged between a server and a client device. The master and client queues have identical queue names. Messages generated on the client device are enqueued into the client queue. They are then propagated to the master queue on the server. Producer and consumer applications may reside on both the client device and the server.
In this scenario the master queue on the Oracle8i server broadcasts messages to client queues on multiple devices. By using a common subscriber name on every device in your queuing system, you can facilitate global publication of messages. For example, you could create a consumer on each client device named "globalsubscriber". Messages published to this subscriber can be dequeued by any AQ Lite client in your system. Each consumer dequeues the message using browse mode so that the message is retained in the publishing queue after being consumed by each user.
In the client-client scenario, messages are exchanged between two or more client devices through the master server. The master queue and all client queues must have the same queue name. Messages produced on a client device are propagated to the master queue. The messages are then propagated to the client queues specified in the message recipient list or in the queue subscriber list.
This scenario illustrates the use of both AQ Lite and AQ functionality. Messages are exchanged between client devices and a server other than the server where the master queue resides. Messages produced on a client device are propagated from the client queue to the master queue using AQ Lite propagation. Once the message is in the master queue, AQ functionality is invoked to propagate the message to the secondary server.
In the stand-alone queue configuration, producer and consumer applications reside on the same client device and exchange messages through a single common queue. This configuration requires only one client queue. There is no master queue. Propagation is not necessary in this configuration. Producers enqueue messages into the queue. Consumers can dequeue the messages based on a queue subscriber list or message recipient lists.
|
 Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|