Architecture/patterns for pushing live data in client server application

Question

I have got a server that controls a complicated industrial system.

We need to write a remote client that can connect to the server and "observe" its internal state. I need to work out:

• How to establish the current state when the client connects
• How to keep the client up to date with changes on the server
• Do we replicate all of the objects/state on the server, or just a subset?

My current approach is to hand-write code that watches for changes to every object on the server and send those as messages to the client. The client receives those messages and applies those changes to its own local model.

The problem is this involves a lot of manual coding, and I have got three classes for each entity: server, message, and client. Even observing for state changes is pretty labour intensive.

I feel there must be a better, generalised way to achieve this?

Incidentally the technologies I am using are .net, c#, WPF and WCF

Answer 1

What I'm about to suggest may be very hard to retrofit to an existing system, but I think it's an effective pattern. You might call it a "Replicated Model".

My idea is that your server has a Model, and the client should have an identical Model.

All updates to the server Model arrive as events applied to the Model. Now, provided those events are serialisable then we can ship them to the client too, and it will see the same updates.

All we need to do is get the initial state of the client and server models to be in step. That's simplest if we make the Model serializable too. With a timestamp mechanism the client now goes:

 Hey Server, I'd like to to start replicating

the server goes

 Here's the current snaphot and I'll be sending you all updates after that

There's plenty of wrinkles to this. For example how to get back in synch if messages are lost.

The key thing here is that the Model needs to be decoupled from the other code in the Server. It's classes must not refer to processing classes. Instead it must emit events if it is to trigger work. Then in the Server things happen, but in the client these work events are simply ignored.

The advantage of this approach is that once youve got the replication meachism in place there's virtually no maintenance as the Model changes. Provided all model classes and chnage events are serializable then the same code runs in server and client.