If the approach is pub/sub, this would make sense for the use cases where
services want to subscribe to a 'ServiceControl' publisher - this is where
services can be sent control/system/notification messages e.g
- Shutdown your service
- Restart your service
If a control/system/notification message is received indirectly to other services where it does not apply, it could be discarded, but the receiving service would still need to inspect it to see if its irrelevant or not. Where there are alot of services, this could lead to cpu cycle wastage.
With pub/sub, network traffic would be increased unless you start to partition the arrangement of publishers. It would be interesting to compare this high level model with JGroups and its general abstraction.
If there is to be a reconfiguration of a particular service via a control/system/notification message, then p2p makes more sense. But you could further abstract that into pub/sub for a particular domain/group to narrow down the subscribers.
I think I see what you are describing.
Yes. In the case of p2p, think of it like as the service subscribing to some transient bus: that's the mode. But the underlying implementation is still p2p, so there's no additional message flow and no need to change implementations. We should be able to use SOAP/HTTP as well as XML/JMS with the same application deployments if necessary.