Publish-and-subscribe is not EDA

There seems to be some ambiguity when discussing the patterns publish-and-subscribe and request-and-reply with regard to the architectural approaches EDA and SOA. This ambiguity origins from a "flat" view on architecture. To fully understand the relationship between these patterns and approaches it is necessary to distinguish between two viewpoints: logical and implementation.

When designing your architecture, are you driven by business events that trigger processes? Or are you oriented on a composition of hierarchically encapsulated layers of callable business services that form processes? Probably the overall architecture will hold both approaches simultaneously. When in a particular context (see How EDA extends SOA and why it is important) your approach is driven by events you will fall into a logical publish-and-subscribe pattern. When your approach is oriented on a layered composition of interacting services, you will end up in logical request-and-reply patterns. This has nothing to do with the patterns at the implementation level.

At the implementation level there are other forces, like available infrastructure, that make you choice for a pattern.
You may choose to implement a logical publish-and-subscribe pattern in a synchronous way. E.g. an RSS feedreader implements the subscription by periodically starting a synchronous interaction by requesting newly published events and wait for a reply. These events may be published by synchronously requesting a service to add a message to the feed store and wait for a "storage fulfilled" acknowledgement.

On the other hand you may choose to implement a logical request-and-reply pattern in an asynchronous way. Simply separate the issuer of the request and the consumer of the reply and separate the receiver of the request and the publisher of the reply. Publishing a request and subscribing to the reply doesn't make the architectural style an EDA. Neither does subscribing to a request and publishing the reply, nor does any combination of these types of interaction make an EDA. It is a loosely-coupled - e.g. asynchronous - request-and-reply implementation.