15.10 - Messaging Models - Access Module

Teradata Tools and Utilities Access Module Reference

prodname
Access Module
vrm_release
15.10
category
Programming Reference
featnum
B035-2425-035K

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.