Best and worst scenarios for Notification Services

Hi,

I am just looking for the best and worst scenarios to implement Notification services...This is more to come up with a design guildelines

I Would be more interested in the worst sceanrios :) Please share your inputs based on your experiences...

Regards,

Anjana

I'm not really sure that I understand what you mean by worst case scenario. Do you mean situations where SQLNS is not the best tool for the job? Or do you mean specific configurations that would cause SQLNS to perform poorly.

In either case, I guess, that's going to largely depend on the situation.

|||

I meant where SQLNS should not be used...

For example let's take three cases

News Alerts (changes with reasonable freqeuncy, and alerts must reach the subscriber in reasonable time)

Weather changes alerts(changes very frequently,and alerts can reach the subscriber in reasonable time)

Stock market alerts (changes very frequently and alert needs to be sent immedaitely to the subscriber with no delay).

In the above scenarios are there any scenarios where NS might perform a bit poorly?

Regards,

Anjana

|||

SQLNS is very good at matching lots of event data with lots of subscriber/subscription data and generating lots of events. It is designed to be "internet scalable" where you may not know just how many subscribers, subscriptions, or even events that you maybe processing over a given time period. It's equally as good for smaller applications, too.

For smaller, purely in-house notification applications, sometimes Query Notifications are a better choice. It just depends on what you're trying to accomplish.

For cases where sub-second notifications are required, SLQNS is *not* the best tool. The generator fires on a regular basis to evaluate whether there has been any activities that it needs to process. Same for the distributor. If you must be notified immediately, that is without a possible 2 second delay, SLQNS is not for you.

HTH...