Is .NET Remoting for me?

  • Thread starter Thread starter Aquila Deus
  • Start date Start date
A

Aquila Deus

Hi all!

I'm going to build a service container that hosts persistent services.
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.

The problem is that: If I use .NET Remoting, those services must share
the same channel (Tcp or IPC). But I found that there seems to be no
way for different AppDomains to share a remoting channel. Do I miss
anything? Should I use different remoting methods such as CORBA?
 
Dino said:
why is each service in its own AppDomain ?
Click to expand...

Because services need to be unloaded when updating (either the services
themselves or its dependent libraries). I don't think .NET can support
hot-code swapping... I have seen such feature only in Erlang.

However, I don't want a sandbox, the use of AppDomain is just to help
services.

The directory structure will be that:

\bin -- put all services' main assemblies, they could be .dll or .exe,
and they may depend on other services. Each assembly here is
automatically launched, in its own AppDomain.

\lib -- put services' dependent assemblies.

\tmp -- put removed assemblies (in NTFS you can move but not delete an
in-use DLL)

There is only one command for the container - UPDATE:

First of all, the container create a snapshot of the \bin directory
(recording file names and last-update dates) and shut down services
that launched in previous UPDATE command but not exist in current
snapshot. Then, it finds out all of services' dependent assemblies
recursively (in \bin or \lib), and remove unused assemblies under \lib,
and restart services whose assemblies or dependent assemblies have been
updated. Now the container launch newly-added services under \bin..
Done!

Simple isn't it? :)
 
Aquila said:
Because services need to be unloaded when updating (either the services
themselves or its dependent libraries). I don't think .NET can support
hot-code swapping... I have seen such feature only in Erlang.

However, I don't want a sandbox, the use of AppDomain is just to help
services.
Click to expand...

actually it's to help service developers - include me
The directory structure will be that:

\bin -- put all services' main assemblies, they could be .dll or ..exe,
and they may depend on other services. Each assembly here is
automatically launched, in its own AppDomain.

\lib -- put services' dependent assemblies.
Click to expand...

Heh, I just thought of that I could put all of them under \bin, with
different extension (.exe or .dll) to identify service assemblies and
dependent assemblies, since .NET can load .exe just like dll :)

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.
 
Yes, code unload/reload is a good reason to use AppDomain.
Heh, I just thought of that I could put all of them under \bin, with
different extension (.exe or .dll) to identify service assemblies and
dependent assemblies, since .NET can load .exe just like dll :)
Click to expand...

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.
Click to expand...
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.
Click to expand...

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?
 
Dino said:
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?
Click to expand...

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?
 
Back
Top