1

Hopefully, this is the right forum for this type of question..

We have a set of common entities which are 'shared' throughout the company - much like Master Data Services (MDS) data. Everyone has differing ways of maintaining said data...most of which are painful and/or lacking.

So...I created a working 'demo' using the SQL Service Broker (SSB) to show how we can easily & seamlessly propagate the 'shared' data. Of course, this data is centrally managed & spoke-applications (themselves) do not change said data.

Another person wants to use SignalR to propagate the 'shared' data to application databases. And, I love SignalR. However, to me, SignalR is "real-time" front-end "componentry"...not a data transfer service solution for MDS-styled data.

I see the broker as the right tool for this job. And frankly, to me...just because you CAN do something...doesn't mean you SHOULD. But I am open to being wrong.

(1) Am I wrong or right. (2) If so, why or why not?

Thanks for the help.

1

Enumerate your requirements. Measure the available products against those requirements. Choose correct behaviour over perceived market niche. Other things being equal choose the one which is "cheapest".

Eventually something will fail in your pipeline. What do you want to happen in this circumstance? Can messages be lost without harm being done? Do applications have cold start logic to ensure they're up-to-date before accepting user actions? Will a failure of the source, message-ware or application result in an inconsistent state? What delivery guarantees do each offer and can your applications work with those?

The "cost" of a solution includes the team's existing experience, infrastructure & support required, and run-time performance, as well as licence cost.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.