2

Simplified... We are using NServiceBus for updating our storage.

In our sagas we first read data from our storage and updates the data and puts it back again to storage.The NServicebus instance is selfhosted in a windows service. Calls to storage are separated in its own assembly ('assembly1').

Now we will also need synchronous read from our storage through WCF. In some cases there will be the same reads that were needed when updating in sagas.

I have my opinion quite clear but maybe I am wrong and therefore I am asking this question...

Should we set up a separate WCF service that is using a copy of 'assembly1'? Or, should the WCF instance host nservicebus? Or, is there even a better way to do it?

It is in a way two endpoints, WCF for the synchronous calls and the windows service that hosts nservicebus (which already exists) right now.

Per
  • 1,393
  • 16
  • 28
  • *In some cases there will be the same reads that were needed when updating in sagas* - do you mean that the sagas will call the WCF services? – tom redfern Sep 18 '15 at 07:28
  • That is a way to do it but there is no WCF service today (yet...TBD). The sagas are calling the storage directly through 'assembly1'. Things are done in kind of reverse order. Without a complete architecture in mind and now we need to make it right. – Per Sep 18 '15 at 07:47
  • So is your quesiton about whether to have your WCF services independent of your NSB endpoints for architectural reasons, or for functional reasons (ie you need to expose your endpoints as WCF services)? Sorry but I don't understand what you are trying to achieve ultimately. Are the WCF services going to be used by the NSBs or are you just providing another route into your DB via WCF and are worried about contention etc? – tom redfern Sep 18 '15 at 08:06
  • Ok. Should I keep our WCF Services independent of the existing NSB endpoint? The WCF services is not going to be used by NSB. Though, maybe that's exactly what we should do... I want to use WCF only for reads. But we also have the scenario that we need to do updates, ie send (command) messages to NSB from our end user application. – Per Sep 18 '15 at 08:38

2 Answers2

2

I see no reason to separate into two distinct endpoints in your question or comments. It sounds like you are describing a single logical service, and my default position would be to host each logical service in a single process. This is usually the simplest approach, as it makes deployment and troubleshooting easier.

Edit

Not sure if this is helpful, but my current client runs NSB in an IIS-hosted WCF endpoint. So commands are handled via NSB messages, while queries are still exposed via WCF. To date we have had no problems hosting the two together in a single process.

Phil Sandler
  • 27,544
  • 21
  • 86
  • 147
  • This was good help in my doubts. It is never easy to get in to a project after the initial design has been set... – Per Sep 30 '15 at 21:21
2

Generally speaking, a saga should only update its own state (the Data property) and send messages to other endpoints. It should not update other state or make RPC calls (like to WCF).

Before giving more specific recommendations, it would be best to understand more about the specific responsibilities of your saga and the data being updated by 'assembly1'.

Udi Dahan
  • 11,932
  • 1
  • 27
  • 35