WCF service and a plug-in architecture

Question

0.00/5 (No votes)

See more:

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?

Posted 18-Jan-13 9:41am

iCanDivideByZero

Add a Solution

Comments

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.
—SA

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?

—SA

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? :-)
—SA

iCanDivideByZero 18-Jan-13 17:24pm

Sounds good! Now I got some reading to do lol. I will have to process this first before I can say I'll be able to make use of it. But at least I know for sure it's plausible now. Thanks!

Sergey Alexandrovich Kryukov 18-Jan-13 17:44pm

Well, if you see that it makes sense, please don't forget to accept my answer formally (green button).
In all cases, you follow-up questions on the topic will be quite welcome.

Good luck,
—SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-01-18T11:04:00

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.

—SA