| |
Home |
![[Table of Contents]](/dwicons/b_toc.gif)
|
Sybase dbQueue User's Guide |
![[-]](/dwicons/i_colpse.gif)
| Chapter 1: Introduction to dbQueue |
This chapter contains the following topics:
dbQueue is a distributed messaging system that uses queues to enable applications to share information across a network. Applications can send and retrieve data asynchronously using queues that are integrated into the application's database. Applications can run at different times and at different locations with the reliability of database transactions. Figure 1-1 illustrates the basic dbQueue system process.
Figure 1-1: Basic dbQueue system process
The dbQueue process consists of three basic events:
dbQueue allows application developers to divide tasks and distribute client applications to access user databases efficiently. Typically, to minimize network traffic, applications run on the same local network as the user databases they access. dbQueue further enhances this model by providing a messaging system that stores and delivers messages.
Message delivery is guaranteed, automatically and asynchronously, to and from SQL Server and SQL Anywhere databases on multiple platforms. The advantages of dbQueue include:
dbQueue is a highly flexible system that takes advantage of network-centric application deployment by offering the features described in this section.
dbQueue queues are tables that reside in application databases. Each enqueue and dequeue operation is a database transaction and can be committed or rolled back at the database level to provide transactional consistency. Furthermore, messages have the security of database recovery mechanisms such as backups and logs.
You can perform queries on messages and customize the message data models to accommodate the needs of each application. Because message queues reside in the same database as the data, programmers can combine database and queuing operations in the same application. An application can add data to a table and enqueue a message for another application as part of a single database transaction.
Each message transaction can be divided into three phases: enqueue, transfer, and dequeue. The enqueue and dequeue operations are assured of the same transactional integrity that the database management system itself ensures.
If system failure occurs in any phase of the process, the application or the QTM will roll back or resend the command. When the system is restored, the application or dbQueue can resume the transfer without data loss or duplication.
When application databases are distributed across a network, dbQueue queues are called distributed queues. Distributed queues support the client/server model by allowing the application to be located at the user database sites for efficient access.
Figure 1-2: Distributed queues
A distributed queue consists of a source and target queue, which are linked by the QTM. From an application's viewpoint, a dbQueue distributed queue located across the network appears as a local queue in its local application database.
dbQueue installs queues into application databases (SQL Server or SQL Anywhere) automatically. You define the parameters for dbQueue to generate the SQL and stored procedures necessary to install a queue. dbQueue includes the Sybase Central administration tool and API commands that enable you to implement queues easily and efficiently.
Queues are updated automatically using QTMs, which communicate with queues on any data server for any platform across the network.
You can use dbQueue to implement and complement workflow management systems. dbQueue features that support the workflow model include distributed queues, asynchronous messaging, and transactional integrity.
dbQueue queues, databases, and their associated applications can be deployed on different platforms and operating systems. The dbQueue QTM reads the locations of the queues and types of transfers required from the dbQueue domain catalog.
dbQueue also manages datatype conversion between applications. For example, numeric datatypes may be stored differently on different servers. As part of the transfer, dbQueue automatically converts the numeric datatype of the sending server to the format of the receiving server.
You can query messages stored in queues using the database's native mechanisms. A message has a header that contains control information and a body that contains the data. Because each message is uniquely identified in a domain, applications can locate and inquire about the status of each message, whether it is in the source queue or the target queue.
dbQueue APIs support programming in several languages, including:
dbQueue provides support for the these APIs:
dbQueue includes an easy-to-use administration tool called Sybase Central with a graphical user interface you can use to:
Sybase Central runs under Windows NT, and you can use it to access any queue or dbQueue entity in the system, including those on UNIX systems.
You can use dbQueue for many asynchronous distributed systems. This section includes examples of how you can use dbQueue to implement a reliable and efficient system.
A stock brokerage has offices in San Francisco (SF), New York (NY) and Los Angeles (LA). The SF office accepts orders, the NY office implements orders at the stock exchange, and the LA office writes checks for the transactions. Each office is connected by a network.
At the SF site, a broker enters a customer order into the Accept Order application. The Accept Order application sends a message with the order information to a dbQueue queue in its local user database. The SF QTM program monitors the queue and transfers any messages to the order queue at the NY site. Figure 1-3 illustrates this step.
Figure 1-3: Orders are accepted at SF and transferred to NY
At the NY site, a broker runs the Sales application to retrieve the message from SF via the order queue. The broker uses the order information in the message to execute the order. If it is a sell order, the broker directs the Sales application to send a message containing the sale amount to an amt queue. The NY QTM transfers the message in the amt queue to the queue at the LA site. Figure 1-4 illustrates this step.
Figure 1-4: Orders are processed in NY and then transferred to LA
At the LA site, a WriteCheck application retrieves the message containing the sales amount and writes a check to the customer. Figure 1-5 illustrates this step.
Figure 1-5: LA receives the check order and writes the check
All three client applications can run asynchronously at the different locations. WriteCheck might be run only when it has accumulated a large number of check requests, while Sales needs to run every day. Sales can fill the amt queue continuously as it executes sell orders, and WriteCheck will dequeue these messages when it is scheduled to write the checks.
When the exchange is closed and the Sales application is not running, customers can still place buy or limit orders to be executed when the exchange opens in the morning. The Accept Order application can run continuously to take orders and place them into the queue. The messages are then transferred to New York overnight, and when the exchange opens, the sales application can dequeue the orders.
dbQueue is a solution for many different system designs. You can use dbQueue both as a standard queuing system and in combination with other database and client/server techniques.
dbQueue messages can be "broadcast" to different queues in the system. Applications can then perform functions independent of each other without the restrictions of two-phase commit.
For example, a newly hired employee needs a personnel record added to the Human Resources database and a computer account added to the Engineering database. In a two-phase commit system, neither operation can be completed until both operations commit.
Using dbQueue, a message with the employee's personnel information and the computer account information can be enqueued to both the Human Resource queue and the Engineering queue. The Human Resource application can dequeue its copy of the message to perform personnel-related tasks while the Engineering account application can dequeue its copy of the same message to perform its task. Each application performs its task independently without two-phase commit restrictions.
Because queues are database tables, dbQueue operations complement the use of existing database functions. A trigger is a standard database operation that initiates the execution of a procedure automatically. You can use triggers to perform automatic enqueuing and dequeuing operations in response to database events.
For example, the Human Resources personnel table contains an employee's personal information including the login name. If the login name entry is updated, a trigger automatically enqueues a message with the new login name to the Engineering account application. The Engineering application retrieves the message to change the login. The entire operation is initiated automatically from one table update of the login name.
|
|