Intense Distributed C# (WCF) Architecture Design

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开发者_如何学Python 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.

1) What sort of design pattern am I best going with?

Based on your comments, you're wanting to transform the current polling mechanism to an event-based mechanism. That is, instead of the client constantly checking the server for results, have the server notify the client when a new calculation result is available.

I would recommend using Juval Lowy's Publish-Subscribe Framework for this.

This framework is described in detail in this MSDN article. And you can download the framework's source code for free at Lowy's website, IDesign.net.

Basically, the server logic that performs the calculations inside the Windows service is the Publishing Client in the graphic, and the various WinForm applications are the Subscribing Clients. The Pub/Sub Service lives in your Windows service. It manages the list of subscribing clients and provides a single endpoint for your server to publish calculation results to. In this way, your server performs a calculation and publishes the result once to the Pub/Sub Service endpoint. The Pub/Sub Service is then responsible for publishing the result to the subscribed clients.

2) What type of WCF binding should I use to ensure maximum speed of data transfer?

If all of your WCF communication were on a single machine, you'd want to use the NetNamedPipeBinding. However, since you will be distributed, you want to use the NetTcpBinding.

For WCF binding decisions, I have found this chart useful.

3) Should I use a class library to share the common objects between the client and the server applications?

Since you are in control of both the client and server side, I would highly recommend sharing a class library instead of using Visual Studio's "Add Service Reference" feature. For a detailed discussion of this, refer to this SO question-and-answer.

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?

I suspect this will depend on what controls you use to display the data. One way that immediately comes to mind would be to have your client fill an in-memory data table as each calculation result is received. This data table could then be bound to a ListBox control, for example, that shows the results in calculation order.

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?