This is the final installment of the articles about the data queue APIs and CL commands. Today, I demonstrate how to use data queues to establish a communication layer between two programs, and I discuss some of the problems and considerations involved.
This example uses local data queues, but the information about data queue setup, the programming of the transaction dialog, and the data queue API calls applies irrespective of where the physical data queues are located. From the communicating programs’ view, it’s merely a question of addressing the interface that the data queue APIs provide.
Using DDM data queues, the programs communicating through data queues can reside on different servers if required. They can even be on different platforms. For example, both Visual Basic and Java offer programmable interfaces to data queues. If that topic is of interest to you, follow the links at the end of this article for more information about DDM data queues as well as VB and Java data queue support.
As I mentioned in part one of this article series, data queues offer a solution to different types of design and architecture objectives. For example, it could be a need to process a workload from a web application located on a separate server accessible from the Internet, while the production data and business logic are on a back-end server behind the company firewall. Or the situation could involve a CPU-intensive application that should have its system workload moved from expensive interactive CPU cycles to less expensive batch cycles. The latter issue is potentially not only a question of cost, but also of sufficient system CPU capacity and thereby application scalability.
Articles on Apis 