Network broadcasting of data changes

CaymanIslandsCarpediem posted on Monday, November 13, 2006

Some time back (actually when we were still on the old forums), this topic came up but I don't think really went anywhere. 

Basically my issues is this:  There are many users on the network using our system.  Currently if one user changes some data all other users would have to manually refresh thier data to see the change.  I'm considering implementing something similar to the Observer Pattern, but across the network so each client could be updated of data that has changed as it happens. 

Rocky wrote an interesting article related to this type of system some time back (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet06082004.asp) and basically I'm wondering if anyone here every tried to implement this in CSLA and if so if they could share thier experiences (good or bad).

Cheers!

 

pirithoos replied on Wednesday, November 22, 2006

Hi I've just gone through Rocky's article (MSDN), downloaded the required controls and recompiled under VS2005. So far it works. In fact if would also find I useful to have something like that in Csla.
If I find the time one weekend I will try to build this in Csla 2.1.1. I shall give another post if I succeede.
(No promises as yet, as this is not my highest priority). The only think I just remember from Rocky's VB2003 Csla book is that there are certain thinks/problems to be aware of with IDisposible (which is used in the PersonBO of the bvBroadcast TestClient), or am I wrong. Also Rocky explained in his MSDN article that vbBroadcast is sensitive in respect to NAT and Firewalls, consequently this gives limitations to the approach if you consider to use it over the boundaries of  your LAN.

Rocky, if you read this I would appreciate your brief comment if your vbBroadcast solution works with Csla.

Best Regards
Frank

Bayu replied on Thursday, November 23, 2006

Technically, it is feasible to have such a broadcasting service that basically functions as a network-wide observer.

I wonder ... would you want such a thing?

To me it sounds like a lot of work and overhead for a piece functionality that is relatively of minor importance..... (arguably, this depends on your requirements, true).

Just a thought: isn't it easier to implement something in the client app that checks a particular web-service for every 60 seconds or so? This webservice would then tell you if a particular set of data has been updated since some timestamp. My thought is that it would be rather easy to maintain a 'last updated' field for all pieces of data that you would otherwise like to broadcast updates about.

Basically, you could see my suggestion as a 'pull model' where every clients 'pulls' updates whenever necessary, as opposed to a 'push model' where the observer pattern 'pushes' updates to all fellow clients.

In a way, the pull model where you put the responsibility for staying up-to-date with latest changes in every individual client has a more robust appeal (at least to me). I also always very much like the concept of decentralizing responsibilities.

It's a near philosophical point I'm making here I guess .... ;-)

Nevertheless, what do you think about it?
Would you agree that the proposed pull model is easier to implement, would still do the job and on top of that: would avoid single-points-of failure and thus be more robust? Perhaps even perform better? (Imagine 100 clients updating stuff ..... 100 pushes per client resulting in 100*99 updates versus just 100 pulls per client ....!?!)

Looking forward to your replies. ;-)

Bayu

Lakusha replied on Thursday, November 23, 2006

If you are using SQL 2005, you can simply subscribe to changes in a dataset and get notified by the server when you need to refresh. Look in the ADO documentation.

jgilkey replied on Saturday, November 25, 2006

Hello everyone, I am fairly new to CLSA.NET, but broadcasting network changes is something I definatly need in my app.  Prior to CLSA.NET, I have been using PeerChannel in WCF to broadcast changes.  I initially started using updates from SQL Server 2005, but it is not designed to handle a high volume load.  After a while, the load on the SQL Server becomes too high for my environment.  If you are looking to broadcast a limited number of changes to a limited number of clients (i.e. refreshes of the cache in a web based application), the change notification is great.  Otherwise, use PeerChannel.  My question is how to work the change notification into CLSA.NET?  Is there any standard interface that can be implemented to notify the clients of the changes?

Joe

DesNolan replied on Saturday, November 25, 2006

Thanks for posting the reference to Rocky's article, I definitely want to implement a broadcasting system before end of year for a CSLA application I'm working on. I'd been looking at Xin Chen's solution in his book Developing Application Frameworks .NET, which is C# based, as is my application. Now I have two solutions to compare. And having ported one of Rocky's reporting solutions from VB to C# without much problem, either one will likely work for  me.

Thanks,

Des Nolan

tiago replied on Saturday, November 25, 2006

Ricky's code is VB for VS2003. VS2005 converted it and Sharp Develop convert it C#. But I'm getting a compile error.

On csBroadcast (aka vbBroadcast),  there is a:
public class Notification
that includes a
public event NotificationEventHandler Notification;

And the error
'Notification': member names cannot be the same as their enclosing type

William replied on Saturday, November 25, 2006

In my thoughts, I will go towards loosely coupled messaging mechanism, for example, MSMQ (or similar technology in WS/WCF). As soon as BO successfully updated the data source, BO will push a message to MSMQ. The benefits are that the listening applications neither need to be .NET based applications nor aware/reference any CSLA assemblies.

Regards,
William

William replied on Saturday, November 25, 2006

Another benefit might be that your application is free from being taxed by the subscribing applications due to message broadcasting through network.

Regards,
William