Design question about real time polling.

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We are in the initial stages of design analysis and I'm trying to come up
with some ideas on how to handle the feature our users are requiring from the
new application. We are using VB.NET/window forms

Feature Requested:
A user will be entering some data that will trigger an a notification event.
For example I am a research analyst entering a sell recommendation for a
stock. Once that action is preformed a notification should be sent the
portfolio manager and the traders. The portfolio managers and traders will
have a main screen and in the right hand corner they will have a grid that
will show the notification coming in real time from the research analysts,
traders and other portfolio managers. These real time notifications will
trigger the user to perform other tasks. Also these notifications need to be
stored in a sql db because if they shutdown the system they need to be able
to bring those notifications back up.

My question is how do I poll for new notifications on a real time basis and
have it not impact the users performance or have any other major downside
impacts on the environment. I was thinking of using a timer control and
making asynch calls to the queue table that will hold the notifications, but
I don't know if that is the best approach.

Thank You for any suggestions
 
Hi,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need to trigger an event when a
user enter some data. If there is any misunderstanding, please feel free to
let me know.

In this scenario, I think you can try to use events in a C# class. When a
user is trying to change a field in a class, you can trigger an event. In
the event handler, we check the value. If it meets certain conditions, we
can send emails or do something else as you want.

Here is more information on events:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/
vborieventhandlers.asp

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Another solution to consider is socket based (TCP or UDP). In this scenario
the notification should be sent to a central server whhere it will be
entered into the database and then broadcast to all interested parties.
Don't be put off by network programming if you haven't done it before its
great experience.
 
Yes I think there is a bit of a misunderstanding. I know how to trigger the
event when a user enters data. My issue is once that event is triggered and
the data gets saved to the db. How do other clients get the notification
real time that there is messages they need to pick up and populate into a
datagrid.
 
If I go socket based (TCP) I'm just trying to figure out how this would work.
A user enters data into the sql server db and that data needs to be
propogated to users who require those messages. So if I have a socket
listening for new messages and once I get a call saying new messages are in
then I could fire off a ado.net call to grab the new data. But the piece I'm
missing is what is the socket listening to figure out when new data has been
entered into a certain sql table?

Thanks for the help.
 
Hi,

I think there are several approaches here.

1. We can use the combination of my solution and Stelrad's solution to
achieve this.

Every user enters data to the database through a server. It can be a web
service or something else. We just make sure that no new entry is missing
with this. When data is inserted to the database, an event is fired. In the
event handler, we use socket based communication to tell the client app
that new data has been entered.

2. We can use SQL Server notification service. The notification service
will inform you when the data in a certain rowset is changed. Then we also
use TCP or UDP to do the communication.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
I have a few more questions.

1) I have heard chatter in other newsgroups that SQL Server notification was
not a good solution when dealing with more than a few users and this app
would be utilized by at least by 40 users at the beginning. Now they didn't
go in depth on why, so let me know what yours thoughts are.

Also on this same subject if I decided to go down this road. What I think I
hear you saying is this sql server notification service would communicate
with a socket on the clients correct?

2) I just want to make sure I have the first idea down. When a certain user
triggers an event that would cause a notification. I would have an
eventhandler communicate via that users socket to all the other client
sockets that would need notification (that means it could be 1 user or 40
users). Once all the users received that notification from the publisher
they would make an ado.net call to the db to get the most recent data
entered. Do I have this correct?

Thank you for all your help.
 
You are far from the first person to build this.
What you are building is called a "Message Bus" and it is a common pattern
in trading systems, portals, and other forms of EAI systems (Enterprise
Application Integration). There are many commercial applications (some of
them are expensive) that will provide message bus capabilities.

It is so common, in fact, that Microsoft is including a message bus
technology in Longhorn called "Indigo".
(There is training on how to use Indigo for messaging bus applications
already available... these guys are good:
http://www.wintellect.com/training/courseofferings.aspx?courses=2&id=37 )

Technically, the way that this is often done, for situations where folks
roll their own, is to create a message dispatcher object that runs under
Enterprise Services or an ASP.Net web service (either one. The architecture
is the same... the communication mechanism is different).

In a way, the Enterprise Services method is slightly more elegant. Using
Remoting, you can set up an Observer pattern that allows each of the clients
to subscribe to an event on the hosted Dispatcher component. When the
clients generate an event, they send it to the Dispatcher for distribution.

An excellent book to pick up would be "Advanced .Net Remoting" by Ingo
Rammer. His examples will make this design clear. This is probably the
best and simplest design for a roll-your-own situation, where you can easily
replace it with Indigo when that becomes available and if you would like
something more "iron-clad".

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
Thank you for the information. I will get Ingo's book on remoting and go down
that route.
 
Hi,

1. Notification Services makes it possible to build and deploy a
notification application quickly, and to scale the application to support
millions of users. I don't think 40 users is a big deal for notification
service if you have a good architecture for your software. You can also try
to ask in the following newsgroup.

microsoft.public.sqlserver.notificationsvcs

2. Yes, you have this correct.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Back
Top