As with standard JMS, the Patch Bay API includes Java interfaces that messaging components must implement in order to send and receive messages. However, these interfaces differ from the standard JMS interfaces, and the terminology is somewhat different:

All message sources, sinks, and filters must have global scope.

Note: Unlike standard JMS, Patch Bay does not have separate interfaces for objects that communicate with topics and those that communicate with queues. A message source can send messages to both topics and queues, and a message sink can receive messages from topics and queues.

In addition to your sources and sinks, you must also define standard JMS destinations; for example, if your JMS provider is SQL JMS, you create destinations as described in Creating and Accessing SQL JMS Destinations. Patch Bay cannot connect a message source directly to a message sink. Instead, the two must be connected through a JMS destination.

Configuration

One of the key DMS design principles is to separate the design of the messaging components from the plumbing. Message sources should be written without regard for where their messages are going. The same code should be used if the messages are to be delivered to multiple subscribers, no subscribers, or subscribers in different processes. Directing where messages go is part of the Patch Bay’s configuration, not the message source’s code. In the same way, message sinks should be written regardless of where messages are coming from. The same code should be used if messages are coming in from multiple publishers simultaneously, or if messages are arriving from remote processes, or if no messages are arriving at all. Determining how messages are delivered to message sinks is determined by the Patch Bay’s configuration, not the code in the message sinks.

For more information about configuring Patch Bay, see the Configuring Patch Bay section.