views:

29

answers:

1

I'm building an application with a Silverlight frontend that communicates with a backend service via WCF. My service has an interface that handles all of the core communication with the frontend.

The backend can be extended with various plugins and I plan on loading custom silverlight modules for configuring these plugins with prism. The problem is, these plugins will add additional functions that aren't part of the base WCF interface. I'd like to maintain a single endpoint for all my communication (i.e. not requiring additional router configuration).

I'm looking for some ideas on how to approach this implementation. My "best" thought at the moment is to have a function in my core interface that accepts a function name and a list of parameters, and using reflection to find the function to call in the specific plugin, I'm not a fan of this for many reasons.

What are your recommendations for building an extensible WCF interface on a single endpoint?

Thanks

+3  A: 

I can think of two ways this is typically handled:

  1. XML contracts - basically, your service becomes nothing more than an XML parameter, with an XML return value. Then, you can either parse or serialize/deserialize the command going between the client and the server. Because your contract only exposes the single XML, what you do "inside" is up to you. You can do things like transmit schemas for the new methods to validate calls constructed on the client, etc.

  2. RESTful service - this is another easy way to do it. Because the REST contract is the URL, adding a new extension is as simple as providing a new URL format. You could communicate via a formatter to the client how to invoke new calls for the extension methods and manage these as you build out the application.

Realistically, however, I doubt your font-end is going to be able to handle all edge cases and dynamically build new screens and validations as you extend the server side. In this case, a better approach in my opinion would be to construct the Silverlight application as a module application using MEF. When you have an extension on the server, you can simply provide an extension XAP for the client. You can have the server enumerate XAP files in a directory for plugins and send these to the Silverlight application, so when a new one becomes available it can dynamically load these. The XAP would contain the code to wire to the new WCF contracts for the extended functionality.

Jeremy Likness
Thanks, thats exactly the advice I was looking for. I was planning on using MEF for the frontend and XML or REST both look like good choices
Aaron