p2p and pub/sub

[marklittle]

I've been thinking about this for a long time (way before joining JBoss), and it's influenced the JBossESB architecture so far. But it seems to me that from the perspective of SOA, there's no difference between p2p and pub/sub: they are just different implementations of getting a message from A to B. OK, in the pub/sub world my message may be seen by multiple recipients, but I can abstract that away and say it's equivalent to multiple p2p's.

From the perspective of the SOA infrastructure, we are concerned with getting messages from clients to services. As the JBossESB architecture document shows, you could conceptualise the interaction as though services subscribe to a bus and clients publish to that bus, even if the implementation is p2p: the p2p approach is essentially a transient bus that exists solely for the purposes of that message delivery event.

What this means is that at the level of the ESB clients and services, the unifying approach we should take is pub/sub (take another look in the document to see what I mean. Ultimately how this is actually implemented is implementation detail: it's the model that we have to make sure is right.

[arvinder]

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.

[marklittle]

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.