Open topic with navigation

TIBCO Rendezvous® 8.7.0

# Decentralization

Rendezvous certified message delivery has a decentralized, stream-oriented, peer-to-peer architecture. Centralized versus Decentralized Architecture outlines the differences between centralized, server-based architectures (such as message queuing products), and decentralized architectures (such as Rendezvous certified message delivery).

Centralized versus Decentralized Architecture

Aspect | Centralized | Decentralized
Example | JMS Message queuing products. | Rendezvous Certified Message Delivery
Components | Message producers. Message consumers. Centralized server as intermediary. | Message producers. Message consumers.
Basic Operating Principle | A producer sends a message to the central server. The server stores the message until it has delivered it to each consumer. | A producer sends a message to consumers. The producer stores the message until each consumer has acknowledged receipt.
Communication Pattern | Producer to server; server to consumers. | Peer-to-peer.
Protocol | Store and forward queue protocol. | Stream-oriented protocol.
Administration | An intermediary server is required between producers and consumers. | No intermediary is required. Producers communicate directly with consumers.
## Resources
Network Bandwidth | Each message traverses the network at least twice—once from the producer to the server, and again from the server to the consumers. Some servers multicast to all consumers simultaneously; others send to each consumer individually. Control and protocol messages use additional bandwidth. | Each message traverses the network once from producer to all consumers. Control and protocol messages use additional bandwidth.
Storage Resources | The central server stores all messages and delivery state for all its clients; it requires disk resources in proportion to total throughput volume. | Each producer stores its outbound messages and some delivery state; it requires disk resources in proportion to its outbound volume. Each consumer stores its inbound delivery state; it requires minimal disk resources.
Storage Integrity | Disk failure on a server host computer can be catastrophic, affecting all messages from every client. Many installations protect against disk failure using safeguards such as disk mirroring. | Disk failure on a peer host computer affects only the messages that its programs produce or consume. However, disk mirroring for each individual peer is often impractical.
## State
State Information | All information about message delivery state resides with the central server. | Information about message delivery state is distributed, residing in part with each individual producer, and in part with each individual consumer.
State Master | The central server is the master of overall delivery state. | Since delivery state information is distributed, no entity can be the single master of the overall state. Rather, individual peers are masters of their own parts of the state.
Monitoring Delivery State | Programs can query the state master (server) about delivery state. | Delivery state monitoring requires application-level code in each producer and consumer.
Changing Delivery State | In some centralized architectures, the state master (server) can make administrative changes to delivery state—for example, it might delete, reorder, or replay messages. | No central component can make administrative changes to overall delivery state.

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO Rendezvous®

Copyright © 1997-2023. Cloud Software Group, Inc. All Rights Reserved.