none
Process with multiple AppDomains: Internal WCF vs Portsharing

    Question

  • Hi all,

    For a new project i'm in doubt on what route to follow: 
    I want to write a server that hosts mulitple appdomains (models). Then clients can connect to these models through WCF. 

    Now i see two alternatives (if you know of a better one please let me know)

    1) The Server exposes tcp endpoints for the clients and then routes messages between the cleint and the correct model. Use named pipes to communicate between the server and the models (each in their own appdomain hosted by the server process)

    2) The server process only hosts the appdomains, and the models in the appdomains have their own WCF stack to expose endpoints on TCP. Then use port sharing to have all the models on the same port to save on configuration. The server itself could have it's own endpoint that lists all the available models with their baseadresses. 

    Does anyone here have good/bad experience with these possibilities?

    How is the performance for instance, would Portsharing be any faster/ slower than having 1 TCP endpoint and then passing the messages internally through a second WCF stack with named pipes?

    Any ideas would be very welcome.

    TIA,

    John



    Have faith in people who seek the truth, be cautious with people who claim to have found it
    Tuesday, July 07, 2009 3:09 PM

Answers

  • The serialization overhead in having the TCP endpoint route the messages to Named Pipe endpoints would perform slower.  If your objective is to loosly couple the WCF services so that your multiple AppDomain Process can host different WCF Services in different AppDomains, if thats what you talking about, then having each AppDomain host its respective WCF service(s) with its own TCP endpoint(s) would be better.  That way you don't have to have plumbing to handle routing TCP calls through to AppDomains in your Process using Named Pipes.  With this you could also split the single Process with multiple AppDomains into multiple process without any change to your code.

    The clients connecting to your "appdomains (models)" should only care about the WCF service contract they need to do their work.  They wouldn't know that the WCF service is in a Processes Child AppDomain.  The EndPoint is all they need.

    Coming in the future there will be better ways to abstract the EndPoing Addressing, you may like this Artical.

    Working With The .NET Service Bus

    http://msdn.microsoft.com/en-us/magazine/dd569756.aspx



     
    Justin
    Tuesday, July 07, 2009 10:09 PM

All replies

  • The serialization overhead in having the TCP endpoint route the messages to Named Pipe endpoints would perform slower.  If your objective is to loosly couple the WCF services so that your multiple AppDomain Process can host different WCF Services in different AppDomains, if thats what you talking about, then having each AppDomain host its respective WCF service(s) with its own TCP endpoint(s) would be better.  That way you don't have to have plumbing to handle routing TCP calls through to AppDomains in your Process using Named Pipes.  With this you could also split the single Process with multiple AppDomains into multiple process without any change to your code.

    The clients connecting to your "appdomains (models)" should only care about the WCF service contract they need to do their work.  They wouldn't know that the WCF service is in a Processes Child AppDomain.  The EndPoint is all they need.

    Coming in the future there will be better ways to abstract the EndPoing Addressing, you may like this Artical.

    Working With The .NET Service Bus

    http://msdn.microsoft.com/en-us/magazine/dd569756.aspx



     
    Justin
    Tuesday, July 07, 2009 10:09 PM
  • Hi Justin,

    Thanks a lot. The argument of each Appdomain expsoing it's own endpoints is actually important, that would decouple the server and the models, allowing multiple versions of the contract to run simultaneously. Thanks!

    GJ

    Have faith in people who seek the truth, be cautious with people who claim to have found it
    Wednesday, July 08, 2009 12:08 PM
  • Hi GJ,

    I'm wondering further info on why you think "each Appdomain expsoing it's own endpoints is actually important, that would decouple the server and the models, allowing multiple versions of the contract to run simultaneously".

    What I understand that you want your hosting application support running multiple WCF service via separate appdomains(so that they're plugable). If so, the service contract used in each Appdomain should be unique. and your main hosting application(main appdomain) should only contains the operations which can help the client find all the available modules(endpoints hosted in separate appdomains).

    Anyway, I prefer the 2) to 1) as it avoids the additional named pipe service communication.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Monday, July 13, 2009 9:20 AM
    Moderator
  • I prefer the first option, since you could apply your own routing strategy and filtering logic when routing messages to the services hosted in another AppDomains, this solution is also more manageable from the architectural perspective. The infamous performance issue of cross AppDomain communication in current version of CLR is regarded as a performance bug, and I hope that CLR team could address them in future release.

    Hope this helps
    Another Paradigm Shift! http://shevaspace.blogspot.com
    Monday, July 13, 2009 4:59 PM
  • Hi Steven,

    Apologies for the late reply, the notification got into my junkmail. 

    Actually the AppDomains are meant to isolate problems in 1 Model to bring down the whole server (StackOverflows due to recursion), the code is generated from a DSL and during the developement stages these exceptions can occur. 

    Also i want to be able to upgrade parts of the server (for instance change endpoints) without having to upgrade every model on the server. So backward compatibily would be easy. We're still in early stages for this technology so the ability to quickly deploy updates that can be used but are not mandatory would be nice. 

    Could you elaborate on "If so, the service contract used in each Appdomain should be unique". Are you saying i cannot host the same contract on different ports this way? 
    What happens if i have a seriveprocess that holds 2 appdomains, each with their own WCF stack that share a contract? Would that create trouble? 

    Regards Gert-Jan

    Have faith in people who seek the truth, be cautious with people who claim to have found it
    Wednesday, July 15, 2009 4:56 PM
  • Hi Zhou,

    I've thought about that but to me the upgrade flexibilty (if possible) would be more important than having a central mechanism to track/ manage all request/ replies. I would add little compared to the extra work involved in writing that. Pealing off layers of WCF to get to messages etc. Seems like quite a bit of work. 

    Thanks,

    GJ



    Have faith in people who seek the truth, be cautious with people who claim to have found it
    Wednesday, July 15, 2009 5:11 PM
  • Hi John,

    Currently I am looking for extensible framework similar to what you are building. Instead of multiple WCF servers in each App domain, I am planning to host TCP Listeners accecpting/processing different types of requests.

    I am trying to figure out how to initiate these App domains for the first time. Will they be in separate threads? If you have already started on this project, it will be helpful if you can share the relevent code snippets

    Thanks/Shakir

     

     

    Tuesday, February 15, 2011 12:46 PM