Question

In our scenario I’m thinking of using the pub sub technique. However I don’t know which is the better option.

1 ########

A web service of ours will publish a message that something has happened when it is called externally, ExternalPersonCreatedMessage!

This message will contain a field that represents the destinations to process the message into (multiple allowed).

Various subscribers will subscribe. These subscribers will filter the message to see if any action is required by checking the destination field.

2 ########

A web service of ours will parse the incoming call and publish specific types of messages depending on the destinations supplied in the field. i.e. many Destination[n]PersonCreatedMessage messages would be created.

Subscribers will subscribe to only the specific message they care for. i.e. not having to filter any messages

QUESTIONS

Which of the above is the better option and why? And how do I stop myself from making RequestMessages. From what I’ve read/seen I should be trying to structure this in a way of PersonCreated, PersonDeleted i.e. SOMETHING HAS HAPPENED and NOT in the REQUEST SOMETHING TO HAPPEN form such as CreatePerson or DeletePerson

Are my thoughts correct? I’ve been looking for guidance on how to structure messages and making sure I don’t go down a wrong path but have found no guidance out there on do’s and dont’s. Can any one help and guide? I want to try and get this correct from the off 🙂

Answer 1

Based on the integration scenario in the referenced article, it appears to me that you may need a Saga to complete the workflow of accept message -> operate on message -> send confirmation. In the case that the confirmation is sent immediately after the operation, you could use NSBs message handler pipeline feature which allows you to chain handlers in a specified sequence such as…

First<FilterHandler>.Then<DoWorkHandler>().AndThen<SendConfirmationHandler>();

In terms of the content filtering, you can do this although you incur some transport overhead, meaning the queue will have to accept the message and the process will always call the first handler on every message(you can short-circuit the above pipeline at any point). It may be the case that what you really want is a Distributor/Worker setup where all Workers are the same and you can handle some load.

If you truly have different endpoints with completely different logic, then I would have the Publisher process(only accepts and Publishes message) do the work of translating the inbound message to something else a Subscriber can then be interested in. If then you find that a given Published message only ever has 1 Subscriber, then you don’t need to Publish at all, you need to just Bus.Send() to the correct endpoint.