The Queue Management System provider for JNDI allows the creation, submission, and servicing of queue jobs. The QMS service provides contexts that implement the behavior of NetWare queues and queue jobs through a central storage and queueing mechanism that enables users to create jobs that are added to the queue. The QMSQueue interface represents the central storage and queuing mechanism that is responsible for managing jobs placed in it. The jobs can be serviced remotely by an application at another node on the network. A queue job is an individual entry in the QMS queue. You can list, create, delete, and modify jobs in NetWare queues using JNDI methods.
Queues are the simplest and most direct of all the methods that developers can use to distribute processes on the network. Although not a suitable solution for all situations, QMS offers several advantages over other methods.
The QMSQueue interface contains QMSJobs, which are created through the QMSQueue.createJob() method. Once the job is created, there are several job controls that can be set. When these controls have been set, a job is submitted to the queue through the QMSJob.submit() method, which returns an output stream used for storing job data. When the output stream is closed using the close() method, the job is ready for servicing.
A QMSJob can represent almost any application task, depending on how the developer has defined the job service protocol. One defined job service protocol is the Printing protocol, in which print jobs are submitted to a queue that is then serviced by a print server. The data to be printed is placed in the output stream provided when the print job is submitted to the queue.
Other job service protocols can be defined for handling any number of job types, including compile servers, archive servers, and so forth. The queue type and job type are useful in making sense of all the possible protocols. When a job is submitted to a queue, it can be targeted for a specific server, targeted to run after a specific time, given a useful description, and so forth.
Applications that service queue jobs are called job servers, which are required to register with (attach to) the queue before they can begin servicing jobs from the queue. Depending on the security requirements established for the queue, the job server will also be required to authenticate to the network before it can actually begin servicing jobs. This registry process helps guarantee that only authorized job servers are allowed to handle queue jobs.
The client that submits a job to a queue grants certain rights to the job server. For this reason, a queue maintains a list of authorized queue servers, users, and operators. In order for a job server to service jobs from a given queue, it must be in the queue server list, or have security equivalence to an object in the queue server list. The same applies for queue users and operators (managers).
The important components (interfaces and classes) of QMS are the following:
In order to access the QMS interfaces and classes you must construct an initial context factory implementation for starting up the queue. Following is an example of how the QMS initial context factory implementation might be constructed.
Hashtable properties = new Hashtable();
property.put(Context.INITIAL_CONTEXT_FACTORY,
"com.novell.service.qms.naming.qmsInitialContextFactory");
property.put(Context.PROVIDER_URL, <server name>);
DirContext initCtx = new InitialDirContext(properties);
After the initial context has been implemented, you can then get the session environment object using similar code to the following:
InitialContext initCtx = new InitialContext (hash);
hash = initCtx.getEnvironment ();
Session sess = (Session) hash.get (Environment.SESSION.OBJECT);
For a detailed discussion of initial context implementation, see Initial Context Implementations in the Novell Services Introduction.
Listed below are some important QMS methods of which to be aware. For a complete list of available methods, go to the Reference Guide documentation.
The relationship between the QMS interfaces and classes is illustrated in the following diagram.
Figure 2-12 Queue Management Service Class Diagram

In this diagram of interfaces and classes a solid blue line ending with a hollow arrow represents an implementation of an interface. A solid red line ending with a solid arrow represent an extension of a class. The dotted black lines ending with a small solid arrow imply some relationships between the different interfaces and classes. Links are provided to the Reference Guide documentation for each of these important Server interfaces and classes.