|
|
|
|
|
|
Broadcasting Messages
BEA MessageQ Selective Broadcast Services (SBS) enable applications to send a message to many receiver programs using a single program call. Any BEA MessageQ application can send a broadcast message using the standard pams_put_msg function. The sending application can generate broadcast messages without knowing the location or number of receiver programs.
Any BEA MessageQ application can selectively receive a broadcast message by first subscribing to a broadcast stream. To subscribe to a broadcast stream, the receiving application first sends a registration message to the SBS Server. Broadcast messages are then enabled for the application and flow into the receiver's queue for processing using the standard pams_get_msg function.
.
A broadcast stream is a data message pipeline that can have multiple entry points and multiple exit points. A message enters the stream and flows immediately to the end. There is no queuing on a broadcast stream, nor is the stream subject to flow control. Also, the flow of messages on a broadcast stream will not be interrupted by any event. Messages are only present on the stream for a finite segment of time, while they are being delivered to the queues of the receiving targets.
The SBS server is responsible for maintaining lists of user processes that are interested in broadcast streams. In addition, the SBS server is responsible for maintaining the various user definable rules that can be used to selectively extract messages from the broadcast stream that are set by the application using the SBS_REGISTER_REQ -message.
Any BEA MessageQ application can send a broadcast message using the standard pams_put_msg function. The identical programming interface which is used to send point-to-point messages can also send a broadcast message by simply changing the -target address to a Multipoint Outbound Target (MOT). A MOT is a broadcast stream associated with a queue number in the range of 4000 to 6000.
BEA MessageQ SBS works in a fashion similar to radio broadcasting. A BEA MessageQ sender program directs a message to a selected broadcast stream or "channel." Then, the receiver program "tunes in" by sending a registration message to the SBS Server thus registering to receive messages broadcast over that channel. This feature is also called "publish and subscribe" in the messaging industry.
When a broadcast message is distributed, any receiver program registered for the broadcast channel will receive the message. Receiver programs that are not registered will not receive the message. Similar to radio broadcasting, where many radio stations are broadcasting at the same time, BEA MessageQ can distribute different types of messages over different broadcast channels.
SBS message broadcasting simplifies application development by eliminating the need for sender programs to know the number, state, or location of the target queues for each receiver program. SBS also simplifies application maintenance because receiver programs can be added and removed from the broadcast distribution without changing the sender program.
A common use for broadcast messaging is the display of real-time continuous data. For example, an application that provides up-to-date stock prices can obtain the latest values and display them simultaneously for any number of system users.
The following sections describe:
How Message Broadcasting Works
To send a message to multiple recipients simultaneously, the sender program uses the pams_put_msg function and specifies a Multipoint Outbound Target (MOT) as the target address for the message. A MOT, numbered between 4000 and 6000, is the identifier for a broadcast stream. A broadcast stream is the set of target queues registered to receive messages directed to a particular MOT.
Continuing our analogy with radio broadcasting, a MOT is equivalent to a radio station that people tune in to. When a message is sent to a MOT, any receiver program registered for the MOT will receive the message.
Each BEA MessageQ message queuing group can be configured to support message broadcasting by setting the ENABLE_SBS parameter in the Profile section of the group initialization file. The default value for this parameter is YES. Therefore, by default, an SBS Server is started for each message queuing group to support both message broadcasting and BEA MessageQ queue availability notification (AVAIL services). Receiver programs may register a queue address with any SBS Server. Any message directed to a MOT address is automatically redirected to the group's SBS Server.
The SBS Server uses its registration database to distribute the message to all applications that have registered to receive the selected message. Figure 3-1 illustrates the flow of messages in the broadcast stream.
Figure 3-1 BEA MessageQ Broadcast Stream
Once registered, applications can receive all messages directed to a broadcast stream, or only those messages that meet the selection criteria entered at the time of registration. Applications can register to receive messages from many broadcast streams. -Applications can stop receiving broadcast messages at any time by sending an SBS_DEREGISTER_REQ message to the SBS Server.
For example, a stock brokerage application might need to display updated stock prices on many user terminals simultaneously. The system designer could designate MOT 5110 as the broadcast stream for updated stock prices. The sender program receiving the updated information from the stock exchange would create outbound messages containing the updated pricing information and send it to the broadcast stream represented by MOT 5110. During their initialization, all receiver programs designed to update user displays would send a registration message to their group's SBS Server requesting to receive all messages sent to MOT 5110. The updated stock price messages would then flow to the queue of the receiver programs.
When designing your broadcast communication environment, you can choose the following configuration characteristics:
The following sections describe:
The range of distribution for a broadcast stream is determined by the MOT address -value. Table 3-1 lists the valid MOT address ranges:
|
Type |
Address Range |
Description |
|---|---|---|
|
Private MOT |
4000-4999 |
Message distribution is restricted to the local group only. |
|
Reserved |
4900-5100 |
Reserved for use by BEA MessageQ. Of these addresses, the first 100 are local or private, and the second 100 are global or universal. |
|
Universal MOT |
5000-6000 |
Message distribution is to all SBS Servers |
Any message sent to a queue address in the range of 4000-6000 is automatically redirected to the SBS Server. The broadcast queue address range (4000-6000) is divided into half, with the lower values designated as private MOT addresses and the higher as universal MOTs.
MOTs numbered below 5000 are associated with a private broadcast stream. MOTs numbered between 4900 and 5000 are reserved to for use by BEA MessageQ. BEA MessageQ redirects a message sent to a private broadcast stream to the local SBS Server, which restricts distribution to registered queues on that group. The SBS Server distributes the message by executing the rules for its local subscribers only. An application uses a private broadcast stream when the scope of interest for the information is local to one system.
An application program does not need to be local to an SBS Server group to register for a private broadcast stream. The registration message specifies a message group identifier allowing queues to register with remote SBS Servers.
MOTs numbered above 5000 are associated with universal broadcast streams. MOTs numbered between 5000 and 5100 are reserved for use by BEA MessageQ. In the universal MOT range, the broadcast stream is available to all SBS Servers. The sender SBS Server is responsible for the following:
Each SBS Server in the BEA MessageQ network is responsible for ensuring that the submitted message conforms to the rule set of registered users and for distributing the messages locally.
For example, the stock brokerage application we mentioned may need to supply updated stock prices to receiver programs on many systems in a distributed network. This application would be most likely to use a universal broadcast stream to expedite the flow of information throughout the network.
Named MOTs
You can configure a BEA MessageQ MOT with a name so that the sender program can direct messages to the MOT name instead of the MOT number. To enable an application to refer to a MOT by name, define the MOT in the Group Name Table (GNT) section of the group initialization file. A full MOT address contains the following:
The BEA MessageQ Naming Service supports the run-time lookup of MOT addresses by applications using the pams_locate_q function to translate a symbolic name to a MOT address. This name can have either a group-wide or bus-wide scope. The %GNT section of the group initialization file is used to load the name into the BEA MessageQ name space.
Listing 3-1 shows how to define the bus-wide "Alarm_events" name to use MOT 5110 and the group-wide "Operator_events" name to use MOT 4810.
Listing 3-1 Configuring a Named MOT
%GNT
!
! Name Group.Queue Scope
------------------- ----------- -----
Alarm_events 0.5110 G
Operator_events 0.4810 L
!
%EOS
Note that the group number is defined as 0 so that the application translating the name uses the local SBS Server rather than a specific SBS Server. See Chapter 4, "Using Naming" for a more detailed discussion on the use and features of BEA MessageQ Naming Services.
Broadcast Communication Modes
All BEA MessageQ Servers support message broadcasting using datagrams transmitted using the BEA MessageQ transport. Datagrams are then transferred over a BEA MessageQ cross-group link (TCP/IP) to another BEA MessageQ Server process and are queued to the receiving SBS Server. Since the broadcasting to each SBS Server is transmitted over point-to-point links, one copy of a message must be sent to each SBS Server. Datagram delivery mode can be used for both private and universal broadcast streams. Figure 3-2 illustrates SBS message broadcasting using the BEA MessageQ transport.
Figure 3-2 SBS Broadcasting Via BEA MessageQ Transport
On UNIX and Windows NT systems the default broadcast transport uses the standard BEA MessageQ cross-group messaging via TCP/IP as defined in the %XGROUP section of the group initialization file. On OpenVMS systems, the BEA MessageQ transport is specified in the SBS section of the DMQ$INIT.TXT file using the COMM_SERVICE keyword with DG/DMQ as the protocol and transport as shown in Listing 3-2:
Listing 3-2 Setting the COMM_SERVICE for SBS on OpenVMS
* ---- Service ----
* ID Prot/Xport
COMM_SERVICE 10 DG/DMQ ! default emulated broadcast path
GROUPS * ! all known server groups
REGISTER * ! all universal MOTs
END_COMM_SERVICE
*
In addition to using the BEA MessageQ transport, BEA MessageQ for OpenVMS applications have the option to use Ethernet multicasting which provides faster throughput for message delivery. There are two protocols available for direct Ethernet multicasting, the normal datagram protocol or the enhanced recovery protocol. The default setting for broadcast communication between SBS Servers is provided by the BEA MessageQ transport using standard cross-group messaging. The choice of enhanced broadcast communication using Ethernet multicasting is set by the protocol parameter in the SBS Server Initialization section of the group initialization file.
Ethernet multicasting can only be used for universal MOT traffic. When Ethernet multicasting is enabled, a message to a universal MOT causes a datagram transfer to the SBS Server that transmits the message via an Ethernet multicast. All receiving SBS Servers obtain the multicast message directly. Since broadcasting utilizes the hardware multicast feature of the Ethernet device, a single multicast message can be received by any number of SBS Servers that are configured to listen using the multicast address as provided in the CNTRL_CHAN and DATA_CHAN keywords in the example below. The Ethernet DG protocol also supports simultaneous multicast on two Ethernet devices per system (also called dual-rail support). When dual-rail support is employed, message segments are broadcast on both Ethernet devices and duplicates are discarded by the receiving SBS Server.
If the optimized Ethernet multicasting feature is enabled, then MOT assignments to Ethernet physical addresses and protocol numbers must be specified. Figure 3-3 illustrates how SBS transports messages using Ethernet multicasting.
Figure 3-3 SBS Broadcasting Via Ethernet Transport
Retransmission Protocol on BEA MessageQ for OpenVMS Systems
BEA MessageQ for OpenVMS Version 4.0A provides an important enhancement to SBS Ethernet multicasting called the retransmission protocol. Each universal MOT that supports Ethernet multicasting can be configured with an option to retry transmission of cross-group messages in the event of delivery problems. Messages sent to a MOT that is configured for retransmission are stored in the SBS retransmission list after they are broadcast. The size of the retransmission list is configured in the %SBS section of the group initialization file. This size parameter sets the maximum number of messages stored by the SBS Server to fulfill retransmission requests in the event of message delivery failures.
The BEA MessageQ retransmission protocol divides Ethernet broadcast messages into the largest transportable segments possible and then transmits them to other SBS Servers. If a missing segment is detected, the receiving SBS Server requests retransmission of the message from the point at which the first missing segment was detected. This request is sent using a high-priority message to the sending SBS Server. The reply is returned using a high-priority message. If the message has already been deleted from the retransmission list, the sending SBS Server responds with a NAK message, generating a sequence gap notification for that MOT.
Ethernet multicasting and the retry option are enabled using the SBS Server Initialization section of the group initialization file. It contains a template for making these assignments when the group configuration is first customized. Listing 3-3 illustrates the configuration information that must be entered to SBS Server Initialization section of the group initialization file to configure Ethernet multicasting.
Listing 3-3 Configuring Ethernet
%SBS ******* SBS Server Initialization Section ************
*
* NOTE: Heartbeat interval is in units of 1 millisecond
*
HEARTBEAT 1000
*
* ---- Service ----
* ID Prot/Xport
COMM_SERVICE 10 DG/DMQ ! default emulated broadcast path
GROUPS * ! all known server groups
REGISTER * ! all universal MOTs
END_COMM_SERVICE
*
* ---- Service ----
* ID Prot/Xport
COMM_SERVICE 0 DG/ETH ! datagram messaging over optimized Ethernet
DEVICE_1 ESA0: ! VMS device name of the Ethernet board (rail A)
DEVICE_2 EZA0: ! VMS device name of the Ethernet board (rail B)
DRIVER_BUFFERS 16 ! # of VMS Ethernet driver buffers to preallocate[10-255]
*
* < <<<<<<<<<<<<<<<<< Warning >>>>>>>>>>>>>>>>>>>
* The protocol and Ethernet addresses show below are not registered
* and are not guaranteed to be conflict free. Use them with discretion.
* |------ MCA ----| |Prot #|
CNTRL_CHAN AB-AA-34-56-78-90 81F0 ! used for VMS V2.x compatibility
DATA_CHAN AB-12-34-56-78-90 81F1 ! path for all data transmissions
*
* NOTE: MAB = Message Assembly Buffer. Each MAB requires area for
* a large message buffer, plus overhead of 150 bytes.
*
* Default Default Heartbeat
* Transmit SILO Receive SILO Maximum Poll Dead Poll
* MOT (in MABs) (in MABs) Heartbeat Interval Interval
REGISTER 5101 30 15 4 10 10
REGISTER 5102 35 12 4 10 10
REGISTER 5156 10 6 6 10 10
*
END_COMM_SERVICE
*
%EOS
When messages sent to a broadcast stream are distributed directly through Ethernet multicasting, it is important to monitor whether the application receives any sequence gap notifications. Because the queue storage area maintained by the hardware is small, messages can arrive faster than the I/O subsystem can deliver them. See the BEA MessageQ Configuration Guide for OpenVMS for a detailed description of how to configure Ethernet multicasting.
Sending Broadcast Messages
To broadcast a message, a sender program directs the message to the MOT that identifies the broadcast stream to use for message distribution. When the application issues the pams_put_msg function, BEA MessageQ recognizes the broadcast message because of the MOT address range and transparently redirects the message to the SBS Server of the target group for wider distribution.
Each message queuing group that is configured to distribute broadcast messages has an SBS Server associated with it. The SBS Server maintains a database of registered queues and message selection rules for each registered queue. The SBS Server compares each broadcast message against the rules stored for each registered queue and generates messages to all registered parties that meet the selection criteria.
When a broadcast message is distributed by an SBS Server, the source field of the message is the MOT address identifying the broadcast stream. The target field is the registered target queue. The source address of the message's originator is obtained in the receiver program's show buffer argument to pams_get_msg. The SBS Server delivers only one copy of each message on the broadcast stream to each target queue, regardless of how many selection matches are made by separate subscription rule entries.
Broadcast messages cannot be stored for automatic recovery. However, you can configure the primary queue of the receiver program as permanently active to receive broadcast messages when the receiver program is not available. In addition, broadcast messages distributed using Ethernet multicasting now have limited recoverability through the retransmission protocol.
Receiving Broadcast Messages
To receive broadcast messages, applications use a standard set of BEA MessageQ messages to register for receipt with the SBS Server in their local group or in a remote message queuing group. Figure 3-4 illustrates the flow of messages sent to the SBS Server.
Figure 3-4 SBS Server Message Flow
.
The following sections describe:
Registering to Receive Broadcast Messages
To receive broadcast messages, an application registers a queue address with the SBS Server managing a broadcast stream. The queue address for the SBS Server in a message queuing group is queue number 99. Any BEA MessageQ primary, secondary, or multireader queue can be registered to receive broadcast messages.
Receiver programs register for broadcast messages using the pams_put_msg function sending a standard BEA MessageQ registration message. Typically, registration messages are sent to the primary queue of the local SBS Server queue (SBS_SERVER), which is queue 99 in the local group. The registration message contains the MOT of the broadcast stream plus any selection criteria related to messages that the application wishes to receive. An application can also register with a remote server by sending the registration message to the primary queue of the SBS Server in the remote group. (For example, 10.SBS_SERVER).
BEA MessageQ provides the SBS_REGISTER_REQ and SBS_REGISTER_RESP messages. Use SBS_REGISTER_REQ to request to register to receive broadcast messages. Your application receives the SBS_REGISTER_RESP in response to the SBS_REGISTER_REQ request message.
The registration information for each broadcast stream is stored in memory by each SBS Server and is volatile. Users registered with a remote SBS Server will no longer receive broadcast messages after the link to the remote server goes down. To recover from cross-group link failures, the application must monitor the status of the link to the remote SBS Server and be prepared to reregister for broadcast messages after a downed link is restored.
The receiver application can request sequence gap notification using the SBS_REGISTER_REQ message. The SBS Server maintains sequence checking on each broadcast stream. Sequence gaps occur when resource exhaustion and overflow conditions interrupt the reception of a broadcast stream by an SBS Server. For example, sequence gaps occur when a sender program broadcasts at a higher rate than the SBS Server can receive and distribute messages. When this characteristic is enabled, the SBS Server sends a message of type SBS_SEQUENCE_GAP to the target queue whenever a sequence gap is detected.
Sequence checking operates on the BEA MessageQ network and on the Ethernet LAN. On Ethernet, the channel and MOT number are returned in the sequence gap notification message. Broadcast messages are not recoverable; therefore, the occurrence of repeated sequence gap messages signals the need to synchronize application processing in the distributed network.
Broadcast streams hold messages for a short period of time only; therefore, receiver queues must be configured with a sufficient message receive quota to store messages as they arrive. As with any BEA MessageQ system, you must test the send and receive rates of programs to ensure that messages are not sent faster than they can be received.
The following sections describe:
Sending a Registration Message
An application sends the registration message using the pams_put_msg function supplied with the following:
The message data structure of the registration message contains the address of the broadcast stream from which the application wants to receive messages and the address of the target queue address to receive broadcast messages.
Registering to Receive Selected Broadcast Messages
Use the SBS_REGISTER_REQ message to register for selective reception of broadcast messages. This message registers a target queue to receive a copy of all messages on a broadcast stream that meet a single selection rule.
The selection rule requests the SBS Server to compare an operand in the message header or message data structure with the operand supplied in the selection rule. The term operand refers to the data in the message header or message data structure that will be compared. For example, a selection rule may configured to receive only messages with a particular type code. In this case, the message type code is the operand. The SBS_REGISTER_REQ message can define up to 255 selection rules. Message distribution can be made if any or all of the selection rules are found to be true.
A selection rule is composed of the following components:
The data offset field indicates whether the selection criteria is part of the message header or the message area. If the data offset is a positive value or zero, then this message is used to begin the comparison. BEA MessageQ specifies constants for selection based on the type, class, or sending queue. Matching based on message priority is not supported. Table 3-2 lists the data offset symbols.
|
Offset |
Description |
|---|---|
|
PSEL_CLASS |
Use the class field of the message |
|
PSEL_TYPE |
Use the type field of the message |
|
PSEL_SOURCE |
Use the source field of the mesage. Note: The comparison is made to the original source field, not the MOT address. |
|
MATCH_PRIORITY |
Not supported |
|
zero based data offset |
Use the message offset to begin data comparison |
The operator field indicates the type of comparison to be performed on the operands. Table 3-3 lists the symbols for the operator field.
|
Operator |
Description |
|---|---|
|
PSEL_OPER_ANY |
Always match |
|
PSEL_OPER_EQ |
Equal |
|
PSEL_OPER_NEQ |
Not equal |
|
PSEL_OPER_GTR |
Greater than |
|
PSEL_OPER_LT |
Less than |
|
PSEL_OPER_GTRE |
Greater than or equal to |
|
PSEL_OPER_LTE |
Less than or equal to |
|
PSEL_OPER_AND |
Operand field AND data not equal to zero |
The operand length field specifies the number of bytes in the operand field to be used for comparison. The operand length can be 1, 2, or 4 bytes only.
Operand Field
The operand field is the value to be compared with the selected field in the message header or message data structure.
Registration Acknowledgment
The SBS_REGISTER_RESP message replies to the SBS_REGISTER_REQ request. This response message returns a status indicator, the registration ID, and the number of application queues registered to receive messages from the broadcast stream.
Reading Broadcast Messages
When a message is sent to a broadcast stream, the SBS Server uses its registration database to determine which applications have registered to receive that kind of message. The SBS Server automatically sends the messages to the distribution of all matching applications. The receiving application reads the broadcast message from its target queue using the pams_get_msg, pams_get_msgw, or pams_get_msga functions. The source of the message, as seen by the receiving application, is the broadcast stream. The address of the sender is also provided to the receiving application in the `original source' field of the PAMS show buffer.
Deregistering from Receiving Broadcast Messages
An application can withdraw from the broadcast stream by either sending the SBS_DEREGISTER_REQ deregistration message to the SBS Server, or by exiting the BEA MessageQ message queuing bus when the automatic deregistration was previously set in the subscription entry. Either of these actions removes the subscription entry from the internal SBS tables. Temporary queues are automatically deregistered when the application exits.
Applications that use the deregistration message can request subscription cancellation in one of the following ways:
Sending a message of type SBS_DEREGISTER_REQ causes the SBS Server to deregister all entries for the broadcast stream and target queue. If requested, an SBS_DEREGISTER_RESP message will acknowledge the SBS Server deregistration.
To cancel registration for a specific type of message while continuing to receive other broadcast messages, the application must send a message of type SBS_DEREGISTER_REQ using the subscription identification code assigned to the original SBS Server registration. Deregister by ID if there is more than one registration for the broadcast stream and target queue and you only want one entry to be removed.
Running Existing SBS Applications
Applications using SBS messages that were designed to run under BEA MessageQ for OpenVMS, Version 3.2 or earlier will continue to run under BEA MessageQ for OpenVMS, Version 4.0A. For BEA MessageQ V4.0, the SBS message interface was redesigned to support enhanced features and to make the message structures RISC aligned.
However, to run these applications in other BEA MessageQ environments such as UNIX or Windows NT, the applications must be changed to use the new Version 4.0 SBS messages. Table 3-4 is a list of the new SBS messages and their obsolete equivalent message. See the detailed description of each message in Table 3-4 to learn the changes needed to recode your application to use the new SBS messages.
|
Obsolete SBS Messages: |
New SBS Messages: |
|---|---|
|
SBS_BS_SEQGAP |
SBS_SEQUENCE_GAP |
|
SBS_DEREG |
SBS_DEREGISTER_REQ |
|
SBS_DEREG_ACK |
SBS_DEREGISTER_RESP |
|
SBS_DEREG_BY_ID |
SBS_DEREGISTER_REQ |
|
SBS_REG |
SBS_REGISTER_REQ |
|
SBS_REG_EZ |
SBS_REGISTER_REQ |
|
SBS_REG_REPLY |
SBS_REGISTER_RESP |
|
SBS_REG_EZ_REPLY |
SBS_REGISTER_RESP |
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|