views:

739

answers:

2

I will try and explain exactly what I want to achieve first.

Imagine two users are using a windows forms application, when User A opens a particular form a lock is applied to the data record underlying the form so that only that user can make changes at that time.

User B has a list of all records (in a grid) which among others contains a reference to the record already opened by User A. What we want to do is when User A opens the records User B's list of records is updated to show a lock icon next to the row to indicate the record is in use.

This is a trivial example of what we do with messaging but you get the idea, User A does something User B needs to knows about it.

I have implemented a system using Jabber-net for C# and an OpenFire Jabber Server. Basically when a message is to be sent, a new row gets inserted on a messages table in the database. The messages table is watched by a service client using the SqlDependancy object, so that when a new message is ready the service builds the relevant message and sends it to the desired client via Jabber and the OpenFire server.

This works OK, however OpenFire's out of the box functionality is for supporting Instant Messaging which obviously isn't what I'm trying to achieve . The problem I have is that if a user is logged in to two Application Contexts (i.e. Test and Live) OpenFire does not know which one to send a message to because the JID structure of user@server/resource takes no notice of the resource.

Basically the way I'm currently using OpenFire and Jabber-net isn't quite right.

Is there a pattern I can use for achieving what I want to achieve i.e. send a message to a client telling it do something, whilst being able to specify which client you are sending the message too. XMPP seemed like the answer because I can construct my own messages types to be parsed.

My application is a Windows Forms, .NET 3.5 C# application.

A: 

How about using the Observer Pattern. This sounds as though it is essentially what you are trying to achieve.

James
A: 

I'd just add some more data to indicate which Application Context is affected and have the other clients decide whether they need to handle the message or not.

Thorsten Dittmar
Yeah, I've thought about doing that already, it just felt like a bit of a cheat. I might well end up doing that, I was just interested to see what other options there are.
MrEdmundo