O'Reilly - Java Message Service

Java Message Service
only really viable for DUPS_OK_ACKNOWLEDGE. No matter what, a messaging vendor has to
implement the reliability necessary to ensure guaranteed ordering, since UDP doesn't
ensure that packets are received in the same order that they are sent.
A messaging vendor should support some sort of error detection to know when a UDP
datagram is lost. Ideally it should know that a client can't be reached due to a network
boundary across an unsupported network router (see Section 7.2.4.3 later in this chapter).
The JMS specification allows for a nondurable JMS subscriber to miss messages, but is
intentionally vague about this since it is not a goal of the specification to impose an
architecture on a JMS provider. However, for all practical purposes, nonguaranteed
messaging means that messages may be lost, and that should mean they may only be lost
once in a while. For both cases, some sort of acknowledgment semantics are required.
7.2.4.2 Centralized and decentralized architectures
A TCP-based messaging system generally uses a hub-and-spoke architecture whereby a
centralized message server, or cluster of message servers, communicates with JMS clients
using TCP/IP, SSL, or HTTP connections. The centralized server is responsible for
knowing who is publishing and who is subscribing at any given time. Message servers may
operate in a cluster spread across multiple machines, but to the clients there only appears
to be a single logical server. Message servers operating in a cluster can intelligently route
messages to other servers. Clustering may provide load balancing, and may help to
optimize network traffic by selectively filtering and routing only the messages that need to
get to a particular node. The servers are also responsible for persistence of guaranteed
messages, and for Access Control Lists (ACLs) that grant permissions to subscribers on a
per-topic basis. The messages are only delivered to the subscribers that are interested in a
particular topic, and only to those that have the permissions to get them. A centralized
server also makes it easier to add subscribers: when a new subscriber comes online; only
the message server needs to know about it.
At the same time, a centralized architecture may introduce a single point of failure: if the
main server in a cluster (the server to which clients initially connect) goes down, the entire
cluster may become unavailable. A JMS provider may solve this problem by distributing
the connections across multiple servers in the cluster. If one server goes down, the other
servers can continue to operate, thus minimizing the impact of the failure. Reconnect logic
may also be built into the client, enabling it to find another server if its initial server goes
down.
Multicasting implies a drastically different architecture, in which there usually is no
centralized server. Because there is no central server, there is no single point of failure;
each JMS client broadcasts directly to all other JMS clients. One consequence of this
architecture is that every publisher and every subscriber may have local configuration
information about every other JMS client on the system. This can be an extremely
important consideration for deployment administration. In the absence of a higher-level
administrative framework, local configurations have to be updated on every client
whenever a new client or a new topic is added.
114