Re: 1st hosting of objects, new(), etc.
From: Mike (vimakefile_at_yahoo.com)
Date: 08/17/04
- Next message: Mike: "Re: 1st hosting of objects, new(), etc."
- Previous message: Mike: "Re: 1st hosting of objects, new(), etc."
- In reply to: Sam Santiago: "Re: 1st hosting of objects, new(), etc."
- Next in thread: Mike: "Re: 1st hosting of objects, new(), etc."
- Reply: Mike: "Re: 1st hosting of objects, new(), etc."
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 17 Aug 2004 13:54:25 -0700
> On the client application once you have registered a wellknown type in
that app domain it
> makes sense that New would attempt to create a remote object.
Unless you wanted to mix local and remote versions of the same class, which
doesn't seem too unreasonalble.
How is this done?
(Or execute remote versions on several different machines.)
The client-server model seems too restrictive and is no more easily
understood than something like an agent model -- here you'd simply tell the
object where you want its state to be held (which you could .Move) and where
you wanted to execute a method, which could be in different places, although
you'd have to stub back for any objects that weren't migrated with the
object. There exist such beasts for Java, but I can't seem to find any for
.Net.
mike
"Sam Santiago" <ssantiago@n0spam-SoftiTechture.com> wrote in message
news:eLuZDbJhEHA.2764@TK2MSFTNGP11.phx.gbl...
> The New statement will create a local object on the server application
> even if you have published a wellknown object of that type. On the client
> application once you have registered a wellknown type in that app domain
it
> makes sense that New would attempt to create a remote object.
> Your issue is that either one of your applications can act as a
server.
> You might want to reconsider that. I think it is a bit risky to have an
> ASP.Net application dependent on a remote object in a Windows Forms
> application that can be shut down at will. With that said you might want
to
> try something like the pseudo code below in each application, I am not
sure
> if it would work:
>
> obj1 = New Myojbect - Create a local instance of the object
> bUseLocalObj = true
> Register MyObject as a wellknown type
> try
> obj2 = attempt to create another instance of your object (obj2 -
should
> be remote instance)
> bUseLocalObj = false
> catch
> if error, remote object is not available, probably not been published
> Marshal obj1 to a URI
> end try
>
> if not bUseLocalObj then obj1 = obj2 (obj1 and obj2 are both Myobject
> types, but obj2 is a proxy, so not sure what would happen)
>
> Use obj1 throughout your application (may or may not be a proxy based
on
> what happened above)
>
>
> Good luck.
>
> Thanks,
>
> Sam
>
>
> --
> _______________________________
> Sam Santiago
> ssantiago@n0spam-SoftiTechture.com
> http://www.SoftiTechture.com
> _______________________________
> "Mike" <vimakefile@yahoo.com> wrote in message
> news:eRSlNz$gEHA.3272@TK2MSFTNGP11.phx.gbl...
> > I'd like to have the first-running application that references my object
> > host a singleton server for the app's lifetime, and I'd like the hosting
> > application to use a local (non-remoted, same process) version of the
> > object.
> > For instance, if my winforms app is the first app to need the object, it
> > will do a registerWellKnownServerType on a singleton that is also used
> > locally, and if an IIS application on the same machine runs first, I'll
> > create a the local object and cache it in the ASP.Net Application object
> and
> > then register it. Otherwise, if one or the other is running, it will use
a
> > remoted version. Is it possible to have this
> > local-and-remoted-access-to-the-same-singleton scenario work? (With
> > appropriate lock()'s in case the local and remote context threads muck
> with
> > state at the same time.)
> >
> > The impetus is that I'd like a management console to be able to run w/o
> IIS
> > active, but most of the time I want the IIS application to host the
object
> > and have fast, local access to it. In the case that I run one or more
> > managment consoles from local or remote machines with IIS already
hosting
> > the object, they will connect to the already running object.
> >
> > One problem is .Net's choice of implicit remote creating via new() which
I
> > don't really like. It seems like before a registerWellKnownClientType
"new
> > foo(...)" means one thing, and after the registration it means something
> > else - an explict Remote.Create( typeof(foo), ...) seems cleaner. Once
> > rWKCT is called, how do I create local, non-remote, non-singlton
versions
> of
> > the object if I wanted to?
> >
> > I guess in the case where the hosting app exits, it would cause an
> exception
> > on the client, or I could have the process stick around while there are
> > still non-timed-out clients (unless IIS gets aggressive with an
ostensibly
> > zombified process.)
> >
> > thanks,
> > mike
> >
> >
>
>
- Next message: Mike: "Re: 1st hosting of objects, new(), etc."
- Previous message: Mike: "Re: 1st hosting of objects, new(), etc."
- In reply to: Sam Santiago: "Re: 1st hosting of objects, new(), etc."
- Next in thread: Mike: "Re: 1st hosting of objects, new(), etc."
- Reply: Mike: "Re: 1st hosting of objects, new(), etc."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|