Click here to Skip to main content
15,664,823 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Is it possible to use a plug-in architecture with a WCF service? I've read up a little on plug-in architecture and I am not completely sure if I am understanding its benefit that much. I have a simple WCF web service, that essentially streams in data and streams some data back; the data is xml. Someone has told me that me the behavior or functionality of the service could be modified or added on to by taking advantage of a plug-in architecture. Is that true? Is there any documentation/examples available online to point me in the right direction?
Sergey Alexandrovich Kryukov 18-Jan-13 15:57pm    
Generally, it's quite possible. I never knew any documentation, but I can just build such architecture, because this is one of the many things I do. It's hard to help you in a more concrete way, based on your very limited information.
iCanDivideByZero 18-Jan-13 16:06pm    
What information could I provide to help. I mean, it sounds you are confirming what I heard. So by implementing a plugin architecture the behavior of the service can be changed/added on to then? That would be great!
Sergey Alexandrovich Kryukov 18-Jan-13 16:31pm    
I have no idea what can you do. Isn't that obvious that you should know better?

Unfortunately, it can easily grow well out of the scope of this forum, which is called Quick Questions & Answers. And what you are asking about is rather pretty much a whole work at the technological architecture. I don't even have enough reason for a formal answer.

You see, even when you ask "added on to", I cannot see, add to — what, exactly? You might need to explain some ultimate goals of the whole product, the scope of expected changes in behavior of the service or communication, even the social and business model (like who is supposed to define changed behavior, implement plug-in, deploy it — where, what party should do it; and, importantly, why). I have a good number of past answers on plug-in architecture, but they are more general, not touching WCF aspects at all. And even they are pretty complex for understanding.

If you want, I could give you the links, so you would see what's involved from purely technological side. And then you could see what's involved and might see more clearly what about your product you might need to share... how about that?

iCanDivideByZero 18-Jan-13 16:45pm    
Yes the links will be good enough, thanks. My apologies turning this into more than a quick Q&A session :)
Sergey Alexandrovich Kryukov 18-Jan-13 17:07pm    
OK, done. What do you think? :-)

1 solution

OK, as I promised, some links to my past answers:

Create WPF Application that uses Reloadable Plugins...[^],
AppDomain refuses to load an assembly[^],
code generating using CodeDom[^],
C# Reflection InvokeMember on existing instance[^],
Projects and DLL's: How to keep them managable?[^],
Gathering types from assemblies by it's string representation[^].

Sorry that the application fields mentioned above did not imply WCF (but might include it). I answered in so great detail to some of the questions referenced above mostly because the applications were much more certain than in your case.

Right now, I can add just a couple of considerations.

The most difficult technical issue with the plug-in architectures appears when you need to unload a plug-in. In some applications, it is never needed, so it makes things way simpler. Most likely, you will need it in your field, but I cannot be sure.

This is because unloading of an assembly is not allowed in .NET, by pretty obvious safety reasons. If you need to actually change some plug-ins during run time, you can only load a plug-in assembly in a separate Application Domain and later unload the whole domain. As the address spaces of different domains are perfectly isolated, it involved no danger of invocation of anything already unloaded. This is resolution is at the same time a difficulty, because the Application Domain can only communication via IPC (is that clear?). Fortunately, the AppDomain class provides highly simplified IPC facilities convenient and pretty easy for Application Domain communications.

And here is some good news related to WCF: WCF is already the IPC. It means that in proper architecture, you can introduce plug-in assembly and develop the mechanism of its use without adding additional complexity related to domain communications: they will communicate via WCF channels anyway. The same states for "classical" .NET remoting. (Some claim that "classical" .NET remoting should be considered obsolete, but I cannot agree with that, because it can provide better flexibility in more difficult scenarios than the typical ones.)

Does it make any sense for your? If you are getting to some ideas, your further questions are quite welcome.

Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900