Intense Distributed C# (WCF) Architecture Design.

Question

I want to design a new distributed application, but I have a few queries that I need some genius advice on, hopefully from you people:

Scenario

I currently support a legacy application that is starting to fall between the cracks. It is a distributed Client-Server app implemented using .Net Remoting. I can't explain exactly what it does, because I'm not allowed to.......But let's just say that it does LOTS of MATHS. I want to re-design and re-write the application using WCF.

Pre-requisites

The server side of the implementation will be hosted in a Windows Service. The client side will be a windows forms application. The server side will perform lots of memory-intensive processing. The server will spit this data out to multiple thin clients (20-ish). The majority of the time the server will be passing data to the clients, but occasionally the clients will be persisting data back to the server. The speed at which the data is transmitted is highly-important, however I'm well aware that WCF can handle fast distribution of data. Encryption/Security is not that important as the app will run on a highly protected local network.

Queries

Given the information above:

1)What sort of design pattern am I best going with? - Baring in mind I want the server to continually PUSH the newly calculated information immediately to the clients, as opposed to the current implementation that involves the client pulling from the server continuously. 2)What type of WCF binding should I use to ensure maximum speed of data transfer? (as close to real-time as possible is what I'm after) 3)Should I use a class library to share the common objects between the client and the server applications? 4)What is the best way in which to databind my objects on the client side in order to see live updates continually as data changes?

If I've forgotten anything then feel free to point this out

Help greatly appreciated.

Answer 1

This to me looks like you need to implement the Observer pattern, but distributed. Whereby new calculations are made to the service, and WCF just happens to be the mechanism by which you push your notification back to the client.

Generally speaking, you have your business logic housed in a windows service, whereby a type is a Subject (Observable). You could publish an endpoint for clients to register for notifications. This would be a WCF service, with potentially two operations:

1. RegisterClient(...)
2. UnregisterClient(...)

When a client is registered with service, it can receive updates, broadly speaking, the when the service has finished calculating a result, it could iterate through all registered clients and initiate a push. The push being a communication through an endpoint on the client.

A client endpoint might typically by

1. Notify(Result...);

And your server simply calls that when it has new data...

Typically you'd use TCP to maximise throughput.

This is by no means exactly what you should do, but perhaps its a direction to start in?