Using Program-to-Program Queues › Design Guidelines

Design Guidelines

The following section contains general design principles that you should read carefully before attempting to use PPQs:

• Deciding where to create queues

  You should create a queue on the machine on which you plan to perform the majority of your processing. This will improve the performance of an application when it is reading and writing queue data by minimizing the amount of work that is executed over network connections.

  You should also remember that PPQs do not back up queue data to a disk. When the PPQ server is terminated, all queues that were created locally on that machine are lost. If you need to save your data, you should extract it and save it to a disk.

• Using the product in a client-server architecture

  One of the most common uses of PPQs is in a client-server architecture. For example, a client could request a service or function from a server by writing a message to a specific queue. (You should create the queue on the system on which the server runs.) The server would then read the message from the queue and process the request. In this scenario, the server does not have to send any data back to the client.

  At times, a client may need to receive data from a server in response to a message that it placed on a queue. In this scenario, you would create a response queue on the system on which the client runs and include the queue name in the message. Including the name of the queue tells the server where it should send the message. The server would then process the request and write a response message to the client's queue. (If you want, you can distinguish the response by designating a client token.) If you want this queue to be temporary, you can delete it after the client processes the message.

• Using the product as a data transfer mechanism

  Because PPQs are a data transfer mechanism, you should design your applications so that they allow only minimal quantities of data to accumulate within the queues. Data should be placed into a queue by one process and pulled out of the queue by another process as soon as possible. You should never use a queue as a data repository.

• Using the LIST command

  For security reasons, the LIST command does not display every queue that exists in the PPQ complex. Users are only able to see the queues that they have read from, written to, or listed. To use a queue, you either need to be the creator of the queue or know the name of the queue.

• Verifying return codes

  You should always check the return codes from PPQ calls because a code that may indicate an error in one situation can be acceptable in another situation. For more information, see information on PPQ return information in the Command and Keyword Reference Guide.

• Determining the size and number of items in a queue

  You should try to keep the length of queue items at 100 to 200 bytes each. Because very long items use large amounts of memory, performance will be optimized if a queue contains a small number of very large items.

  You should also try to keep the number of items within a single queue relatively small. (The default number of items is 100.) Generally, your applications run better if you have a few small queues rather than one large queue.