Image Processing Reference
In-Depth Information
Confirmation Request
4
Indication Response
Indication
Indication
1
2
3
4
4
Publishing
manager
Publisher
Subscriber
Subscriber
FIGURE .
Pull-type publisher-subscriber model.
producer-consumer model uses very similar mechanisms, the only difference is that broadcast
services are being employed instead of multicast communication as in the case of the publisher-
subscriber model. However, this distinction is rather subtle and not very relevant in practice.
Depending on how the information exchange is initiated, two different subtypes of the publisher-
subscriber paradigm can be distinguished []. In the pull model, the publishing action is triggered
by a centralized publishing manager (Figure .). Upon receiving the request from the manager, the
publisher broadcasts the respective response to the network. Filtering of the message, which deter-
minesiftheserviceisabroadcastormulticast,isdonelocallybythesubscriberswholistenintothe
network for message identifiers they subscribe to. It should be noted that the subscriber group may as
well consist of just one node, such that the communication relation is effectively a -to- relationship.
In terms of communication services, the pull publisher-subscriber model uses a confirmed
request/response service for the interaction between manager and publisher. he peculiarity of this
service, however, is that while the request is unicast (i.e., has only one recipient), the response from the
publisher is multicast to the publishing manager and the subscribers and already contains the infor-
mation to be published. It is the task of the underlying protocol layers to ensure that the appropriate
addressing scheme is used to transform the unicast into a multicast message. For the subscribers, the
communication then may look like an unconfirmed service (i.e., they receive only an indication that
a subscribed object has been transmitted) although it is actually a confirmed one from the viewpoint
of the manager.
Still, there might be subtle differences in the way the request itself is handled. On the one hand,
the manager might know the identifier of a variable and requests publication of this specific vari-
able without caring about its producer. This method is being used, e.g., in WorldFIP. On the other
hand, the manager might know the device address of the publisher and send the request directly to
this node. This is typically done in fieldbus systems that normally rely on node addressing for data
exchange and thus a client-server model. In such fieldbus systems, a publisher-subscriber transac-
tion is the exception rather than the rule, as in PROFIBUS-DP V. In master-slave systems, this
type of communication—although not strictly publisher-subscriber—may also be used to imple-
ment a direct communication possibility between slaves under the direct control of the master. his
shows that an application-layer service for reading data based on the pull model comes very close to
a read service implemented according to the client-server model. he essential difference is that the
response is directed to a group of receivers instead of only one—the manager.
The second subtype of the publisher-subscriber paradigm is the push model (Figure .) in
which the publishers become active by themselves without prior request from a centralized station
and distribute their information to the subscribers when they consider it necessary, e.g., trig-
gered by the expiration of a timer (as in TDMA systems) or by an external event. In terms of
communication services, the publishing of information is implemented by means of unconfirmed
(or locally confirmed) services on the publisher's side. Like in the pull variant, the subscribers receive
an indication that new data have arrived, and do not answer or acknowledge receipt of the message.
A necessary step in either of the two variants is the subscription of the subscribers with the pub-
lisher. his is a typical configuration action within the network management that can be accomplished
