>> > why is each service in its own AppDomain ?
>>
[quoted text clipped - 3 lines]
> support
>> hot-code swapping... I have seen such feature only in Erlang.
Yes, code unload/reload is a good reason to use AppDomain.
>> The directory structure will be that:
>>
[quoted text clipped - 8 lines]
> different extension (.exe or .dll) to identify service assemblies and
> dependent assemblies, since .NET can load .exe just like dll :)
Yes - you can just put them all in one place. No need for extra
complication.
> Now the only problem is the remoting channel... I hope to make it
> centrailized so that individual services don't need to worry about
> which channels to use.
> Each hosted service will be running in its own AppDomain, and provide
> an remoting object/interface for others (local or remote) to
> communicate with it. And all of their remoting objects are managed by
> the container but run inside their own AppDomains.
Does the remoting interface change with each service? or only the service
interface? If the remoting interface does not change, you could host all of
them in the main app domain, and only change the implementations in the
service plugins. This means each appdomain does not expose or utilize its
own external remoting interface. (though you may use remoting between
appdomains). Would this work for you?
Aquila Deus - 21 Dec 2004 23:56 GMT
> "Aquila Deus" <aquila_deus@yahoo.co.uk> wrote in message
> > Each hosted service will be running in its own AppDomain, and provide
[quoted text clipped - 8 lines]
> own external remoting interface. (though you may use remoting between
> appdomains). Would this work for you?
The remoting interface will change with each service. Ummmm... maybe I
should not let the container manage the remoting at all, because it's
too hard to determine what kind of method those services will use for
remoting now. However, a channel that can be shared between all
AppDomains in a process would still be great. Will .NET 2.0 have it?