Application Architecture using WCF and System.AddIn

Question

A little background -- we're designing an application that uses a client/server architecture consisting of:

• A server which loads server-side modules, potentially developed by other teams.
• A client which loads corresponding client-side modules (also potentially developed by those other teams; each client module corresponds with a server module).
• The client side communicates with the server side for general coordination, and as well as module specific tasks. (At this point, I think that means client talks to server, client modules talk to server modules.)
• Environment is .NET 3.5, and client side is WPF.

The deployment scenario introduces the potential to upgrade the server, any server-side module, the client, and any client-side module independently. However, being able to "work" using mismatched versions is required. I'm therefore concerned about versioning issues.

My thinking so far:

• A Windows Service for the server.
• Using System.AddIn for the server to load and communicate with the server modules will give us the greatest flexibility in terms of version compatability between server and server modules.
• The server and each server module vend WCF services for communication to the client side; communication between the server and a server module, or between two server modules use the AddIn contracts. (One advantage of this is that a module can expose a different interface within the server and outside it.)
• Similarly, the client uses System.AddIn to find, load, and communicate with the client modules.
• Client communications with client modules is via the AddIn interface; communications from the client and from client modules to the server side are via WCF.
• For maximum resilience, each module will run in a separate app-domain.
• In general, the system has modest performance requirements, so marshalling and crossing process boundaries is not expected to be a performance concern. (Performance requirement is basically summed up by: don't get in the way of the other parts of the system not described here.)

My questions are around the idea of having two different communication and versioning models to work with which will be an added burden on our developers. System.AddIn seems quite powerful, but also a little unwieldly. (I'm also unsure of Microsoft's commitment to it in the future.) On the other hand, I'm not thrilled with WCF's versioning capabilities. I have a feeling that it would be possible to implement the System.AddIn view/adapter/contract system within WCF, but being fairly new to both technologies, I would have no idea of where to start.

So... Am I on the right track here? Am I doing this the hard way? Are there gotchas I need to be aware of on this road?

Thanks.

Answer 1

This sounds too complicated. Consider an architecture where each added module includes both the client side code (use System.AddIn if you like), but where the server side module is a new service.svc file. The client would know the URL to the corresponding service.

Alternatively, you should look into Microsoft Extensibility Framework (MEF) for the add-in feature. That's what they'll be starting to use for Visual Studio extensibility in the coming release.