http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html

Imagine case where Sales let client order varies items. Upon order request confirmation is order data passes to Billing which creates invoice and returns it back to Sales. Billing also passes request to Shipping for packaging items. Sales collect all documents from Billing and Shipping and passes them on client -> either all was confirmed or order was reject for some reason (i.e. out of stock items, user broke credit line, etc.).

Main question is: Would you still use pub/sub in all those communications? If not why and when you would use it then.

If I would get assignment as described above I would probably think first about replacing synchronous calls with async. once. MSQM/REST or similar helps nicely here.

Additionally I would think Merchandising and Sales need to “know each other”. What you will do if subscriber (i.e. Sales) misses some price update sent from publisher due its own downtime (this under assumption that price is published only when changed and not periodically even if not changed)? For this reason I would say there has to be some way Sales will ask Merchandising to ask for “snapshot” on possibly missed data or get up-to-date price data. And here we have basically request/response pattern. MSMQ/Rest would help again.

Yes I need explicit configuration for both services to talk to each other. If I’m on enterprise system I would not see any problem with it.

From article there is nothing which indicates you are planning to use published prices in another service.

Planning for use same data on multiple services seems to be a good reason for pub/sub. But if I originally use MSMQ for solution (i.e. async mode delivery) to connect “M” & “S” services and now I have additional services which needs price notification I can just simply use “Distribution list” feature here (http://msdn.microsoft.com/en-us/library/ms704262(VS.85).aspx). And again I have to admit that explicit destination setup is needed. But is it really problem especially in case of enterprise solution if basically know all subscribers? BTW need for request/response pattern on snapshot remains still here.

On the other hand, how would Merchandising know that Sales needs its price information? This logical coupling is what pub/sub avoids, on top of the physical coupling that one-way messaging avoids.

Should an additional service want pricing and/or product information, it could just subscribe to those events, without requiring any changes to Merchandising.

Does that make things clearer?

What is major benefit of pub/sub here compare for example with plain message queuing (e.g. MSMQ with persistence which addresses disconnected states quite well)?

Additionally I don’t think asynchronous call automatically means RPC (i.e. I assume RPC is defined as blocking operation on caller side). I can send (as Merchandising via async. call) given price notification as easily as you do with pub/sub and don’t need to block itself on response.

That still has the unfortunate effect that the end-to-end time it takes to process a call is dependent on the speed of who you’re talking to. Pub/sub eliminates that as well.

But thanks for helping me focus on the actual benefit pub/sub brings over RPC and asynchronous calls.

For example in first paragraph under section “Pub/Sub Considered Helpful” I might replace “pub/sub” with “asynchronous call”, “published” with “send” and “publisher/subscriber” with “provider/consumer”. Sentence with change remains still true.

Are you referring to how Sales gets pricing information from Merchandising?

Regards,
Libor