Revision history [back]

While both use topics to communicate, conceptually (basic) pub/sub and Action client/servers are definitely not equivalent.

Pub/sub is used to enable dataflow between producers and any number of consumers with the middleware in between to broker the connections. There is a clear unidirectional flow of data, and no synchronisation coupling between sender and receiver(s). This way of communication is sometimes called fire-and-forget (as senders do not care about what happens to their messages).

Action client-server communication is essentially a client-server service interaction pattern, but with the option of making that interaction asynchronous (ie: no forced control flow synchronisation between client and server) and implemented on-top of the pub/sub pattern. Asynchronicity is an option, as the Action infrastructure allows servers to periodically update clients of the status of the operation(s) they are performing by sending them feedback. A final piece of feedback is used to communicate the result of an operation to the client. By blocking until reception of the completion notification, Actions become synchronous (ie: flow of control between client and server is coupled for the duration of the operation). By ignoring the feedback, Actions are completely asynchronous. In all cases clients may request the server to abort processing its request. Likening this to pub/sub described above, Actions would be something like fire-and-get-notified-on-completion-if-you-want.

The wiki/actionlib has a good write-up on this as well.

Actions are like the std::promise and std::future facilities in C++11 or the Python 3 asynchronous coroutines.

For quite some systems I believe it would be beneficial to always implement services as Actions (unless the services are really trivial), as client-server synchronisation is a choice when using Actions, but inherent for services.

While both use topics to communicate, conceptually (basic) pub/sub and Action client/servers are definitely not equivalent.

Pub/sub is used to enable dataflow between producers and any number of consumers with the middleware in between to broker the connections. There is a clear unidirectional flow of data, and no synchronisation coupling between sender and receiver(s). This way of communication is sometimes called fire-and-forget (as senders do not care about what happens to their messages).

Action client-server communication is essentially a client-server service interaction pattern, but with the option of making that interaction asynchronous (ie: no forced control flow synchronisation between client and server) and implemented on-top of the pub/sub pattern. Asynchronicity is an option, as the Action infrastructure allows servers to periodically update clients of the status of the operation(s) they are performing by sending them feedback. A final piece of feedback is used to communicate the result of an operation to the client. By blocking until reception of the completion notification, Actions become synchronous (ie: flow of control between client and server is coupled for the duration of the operation). By ignoring the feedback, Actions are completely asynchronous. In all cases clients may request the server to abort processing its request. Likening this to pub/sub described above, Actions would be something like fire-and-get-notified-on-completion-if-you-want.

The wiki/actionlib has a good write-up on this as well.

Actions are like the std::promise and std::future facilities in C++11 or the Python 3 asynchronous coroutines.

For quite some systems I believe it would be beneficial to always implement services as Actions (unless the services are really trivial), as client-server synchronisation is a choice when using Actions, but inherent for services.