Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / December 2004

Tip: Looking for answers? Try searching our database.

Is .NET Remoting for me?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Aquila Deus - 20 Dec 2004 05:46 GMT
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 Chiesa [Microsoft] - 20 Dec 2004 17:58 GMT
why is each service in its own AppDomain ?

> Hi all!
>
[quoted text clipped - 8 lines]
> way for different AppDomains to share a remoting channel. Do I miss
> anything? Should I use different remoting methods such as CORBA?
Aquila Deus - 21 Dec 2004 06:32 GMT
> why is each service in its own AppDomain ?

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

> > Hi all!
> >
[quoted text clipped - 8 lines]
> > way for different AppDomains to share a remoting channel. Do I miss
> > anything? Should I use different remoting methods such as CORBA?
Aquila Deus - 21 Dec 2004 07:04 GMT
> > why is each service in its own AppDomain ?
>
[quoted text clipped - 4 lines]
> However, I don't want a sandbox, the use of AppDomain is just to help
> services.

actually it's to help service developers - include me

> The directory structure will be that:
>
[quoted text clipped - 3 lines]
>
> \lib -- put services' dependent assemblies.

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.
Dino Chiesa [Microsoft] - 21 Dec 2004 15:25 GMT
>> > 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?

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.