Messaging Models
The Teradata Access Module for JMS supports both point‑to‑point and publisher‑subscribe
messaging models, both of which use the concepts of sender and receiver. The following information defines the two messaging models, then describes the roles
of sender/receiver in relation to imports and exports with the Teradata Access Module
for JMS.
Point‑to‑Point Messaging
A point‑to‑point messaging model is built on the concept of sender, receiver, and
message queue. Data messages are sent to a specific queue, then fetched and processed
by a single receiver. This model provides a one‑to‑one relationship between the sender
and receiver. There are no timing dependencies for sending or receiving messages.
The sender and the receiver operate independently.
Figure 10: Point‑to‑Point Messaging Model
Publish‑Subscribe Messaging
A publish‑subscribe messaging model is built around the concepts of topics, publishers,
and subscribers. Data messages are sent to a topic by a publisher (sender), then received
by one or more subscribers (receivers) of that topic. This model has a one‑to‑many
relationship. Publishers and subscribers operate independently of each other, and
they do not need to know anything about each other.
A subscriber can either be durable or nondurable:
A nondurable subscriber only gets messages that are published while it is connected.
A durable subscriber gets all the messages that are published, including the ones
published while it is disconnected.
Figure 11: Publish‑Subscribe Messaging Model
Component Roles During Data Loads
For load jobs, the sender is a customer‑supplied component responsible for the following:
Format a data message that is defined by the Teradata load utility. The data message
type can either be a simple text message (Type TextMessage) or a stream of bytes (Type
ByteMessage).
Place a data message on a specified queue or at certain destination, called a topic.
Send a control message (zero‑length message) to indicate the end of the message stream.
For load jobs, the receiver is the Teradata Access Module for JMS, which is responsible for the following:
Perform a JNDI lookup to retrieve JMS‑administered objects from the naming space.
Establish communication with the JMS provider.
Retrieve the data message from the queue or topic.
Copy the data message to a fallback file for checkpoint and restart operations.
Pass the data message to the Teradata load utility, which then processes and loads
the data into a Teradata Database.
Continue retrieving data messages from the queue or topic until a control message
(zero‑length message) is received, or until a time out is received that signals the
end of the message stream.
Component Roles During Data Exports
For export jobs, the sender is the Teradata Access Module for JMS, which is responsible for the following:
Format a data message that is defined by the Teradata export utility. The data message
type can either be a simple text message (Type TextMessage) or a stream of bytes (Type
ByteMessage).
Perform a JNDI lookup to retrieve JMS‑administered objects from the naming space.
Establish communication with the JMS provider.
Place a data message on a specified queue/topic.
Send a control message (zero‑length message) to indicate the end of the message stream.
For export jobs, the receiver can be the Teradata Access Module for JMS or any other JMS‑enabled application. The
receiver is responsible for the following tasks:
Perform a JNDI lookup to retrieve JMS‑administered objects from the naming space.
Establish communication with the JMS provider.
Retrieve the data message from the queue/topic.
Copy the data message to a fallback file for checkpoint and restart.
Pass the data message to the Teradata load utility, which then processes and loads
the data into a JMS‑enabled application.
Continue fetching data messages from the queue or topic until a control message (zero‑length
message) is received or a time out that signals the end of the message stream is received.
