locked
Architecture for Notification based application RRS feed

  • Question

  • I need to develop a notification based system in .Net. Basically as and when certain data gets updated, the client machine is informed about it. There would be a windows based application running across all these clients. One way I was thinking of was to have the clients poll the server for any updates at frequent intervals. Whenever the Server does an update it would post the update into a queue. Every client would poll the queue for any updates.

    Would like to know if this approach is alrite or suggest an alternative architecture.

    Thanks
    Sai
    Monday, August 21, 2006 5:17 AM

All replies

  • You can use Remoting for Remote callbacks from Server to clients

    Thanks & regards,
    Bineesh AV
    Monday, August 21, 2006 9:16 AM
  • Hi Bineesh,

    I also hae to design the application quitre similiar to SAI.

    Is the way proposed by you same as that of SAI.

    please explain somewhat in detail about what you are proposing.wat i undestood from your suhhestion is that client will implement a callback from server side .

    Some sample code of few lines of client and server side would be highly beneficial over here.

    kindly oblige

    regards

    Monday, August 21, 2006 11:27 AM
  • I guess the message queue system is good as it is a one direction comunication, but having the queue at the server can decrease the load balance, because you cannot control the time at which the clients poll the queue.
    Having the queue at the clients allows the server to control the time at which messages are sent to the clients and so controls the load balance. if the load balance is not an issue for your application then you can do what you have already suggested.

    Note that queues means that you don't require immediate response or processing for the message. If you need an immediate response or processing for your messages then I think using events would be better.
    Monday, August 21, 2006 11:28 AM
  • Hello Sai,

    You will need to consider the network aspects and frequency (and urgency) of updates you are making on the server to come with a most optimal solution.

    The connectivity from Server to client  may not work if the clients are behind proxy / firewall or are natted. The mode of communication will depend on the same. Similarly how much control do you have on the client machines ? Are you able to install MSMQ windows components on all ? What would be the client machines etc.

    So lets say if you have an application which runs only on the intranet - without a firewall/proxy in between, and lets say you have frequent 2 way communication, and assuming the clients may not have MSMQ installed - one of the most optimal solutions would be that the client application establishes a socket with the server on login, and then the server can push information on the same socket. On the server side, you could implement a publish subscribe model to say which information goes to which set of clients.

    If the data interchange is much more sophesticated, then probably using Queues to communicate will be the best - assuming you can control client environment.

    But if you were looking at clients possibly behind firewalls, you might need to implement HTTP based pull.

    If you give more details of the scenario, we could suggest something. Notification is a part of the system - does the rest of the system communicate with the server ? If so how ? Possibly using the same means of communication will be most optimal.

     

    Regards

    Pranshu

    Monday, August 21, 2006 12:21 PM
  • I dont think I would be able to install queues on client machines. And there are some users who would be based behind the firewall and there are some who are not based within the intranet and would be logging in from internet. As far as I know .Net doesnot have that level of support for using publish/subscribe semantics in MSMQ.

    Actually the entire system is just notification based. Customer has terrabytes of data in a data warehouse and when particular set of updates happen to that data via various online applications, the changes need to be notified to a defined set of users. These users could be within the firewall, or across the firewall.

    -Sai

    Monday, August 21, 2006 12:44 PM
  • Hi Sai,

    For users on internet - likely to be behind proxies and firewalls - you would need to use HTTP or HTTPs. I have heard that HTTPs connection lets establish a socket (HTTP Tunneling) which could enable a two way communication, but to me it sounds more like a hackers thing - not something you are likely to find pre-built APIs for. If you leave this aside, the only mechanism left is to poll and pull the data .

    In case you just need the notifications and not the data, ignore rest of this message and just implement polling. You will be able to implement some sort of caching on the server side to make frequent polling very light on the server side.

     

    If you want data as well , you could either use commercial products like

    - you could use MS SQL Server Anywhere (or any other local database - like Sybase SQL anywhere)on the clients that supports the data replication with SQL Servers.

    - SonicMQ or any other HTTP based message queue

    Or you could go in for custom implementation of polling and then a custom code for synchronization. Knowing what has changed and who has got it/who hasnt - requires some kind of implementation of publish-subscribe ( could be a simple distribution table), or an implementation of versioning - so that based on the version with the client and version on the server, you are able to know what needs to be sent.

    Publish-subscribe will work better for a small defined set of users who will use the application frequently (corporate MIS). Versioning may work better in cases where there is a large number of users using the application infrequently.

    Pranshu Jain

    Monday, August 21, 2006 1:26 PM
  • Have you looked at Notification Services with SQL Server 2005?
    Tuesday, August 22, 2006 1:34 PM
  • Pranchu,

    Can you please point me to some "publish subscribe model" articles, samples, etc.

     

    Wednesday, August 23, 2006 7:43 PM
  • Hi,

    Do search for Distribution lists and Multicasts in MSMQ. I think its availabe only from 3.0 which is XP / Win2K3 +

    See

     http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msmq/html/c866d0f3-88b2-4614-8438-bc21dc8a3ffb.asp

     

    Do also look at "Whats new" in MSMQ 3.0 at microsoft site. There are few other interesting stuff as well.

    Thursday, August 24, 2006 2:13 PM
  • I think you are in the right direction.

    Here is how i view the architecture could be!

     IMO it should be asynchoronous, notifications should be published to a central repository based on events that happen.

     This event notification log should be created in an external database using MSMQ. The logging component should be configurable to record for certain type of events.You could use attribute decorations to specify the event type on method by method basis. This will create the datasource for the notifications sent.

     There could be subscribers registered for the type of event. Different subscribers might want the same notification to be sent via different channels,(email,pager,database update, Online Messengers etc..), also at different intervals.

    At this stage you can send email, pager notifications by polling the data at the server. These will be somewhat on-time push notifications.

     You can also provide offline-databased notifications.Notification clients will talk to the Notification Service (Webservice exposing some methods to register for notification,get notifications for the registered user etc..). Once you read/download the notifications you can show them offline and delete them at the server.

     

     

    Thursday, August 24, 2006 4:54 PM
  • I agree with the "ToadKillerDog" person. Consider Notification service in both version of SQL Server and consider UDP instead of TCP/IP protocol to reduce network verification.

     

    Thanks

    Friday, August 25, 2006 4:34 AM
  • MSMQ supports IP mulitcasting - meaning you can broadcast the same message to all clients. Because it's using IP multicasting it won't work accross subnets (unless you enable the routers). Use private queues to avoid having to register with AD (MSMQ 3.0)

    If you want an approach that will work accross the internet then you need to look at the WS-Notification spec (IBM). This works by allowing interested clients to subscribe to events that get raised. Notifications are raised to the client from the server using a pre-agreed back channel (usually HTTP) There are a couple of WS-Notification .NET implementations around. Off the top of my head have a look at the WSRF (resource framework) implemented as part of the OGSA project.

     

    Hope this helps

     

    Friday, August 25, 2006 3:04 PM