|
|
You're in the
dotnet remoting
group:Custom proxy in interface-based approach
dotnet remoting:
obtained from a server is impossible. I have this scenario : My server application registers a singleton SAO as the starting point for all communication with clients. The client obtains this SAO with the common Activator.GetObject, and then receives more objects from the server to work with as it invokes methods. These objects can be considered "client-activated". When the object is MBR, the server only returns interfaces, for good design practices' sake. Therefore, there is no well-known class between the two applications, only well-known interfaces. Of course my real classes derive from ContextBoundObject, because I have to do so, for reasons still obscure to me. Now, digging through the examples at hand, I tried desperately to do something said by many to be simple : create a RealProxy-derived class by means of a ProxyAttribute-derived class and use it for all my client-activated objects. Nowhere is it documented, or mentionned, that this would not work in this particular case. I had to spend a lot of time scratching my head, and looking through disassembled code to finally find out why I get an exception stating "Could not load type ...". Seems that the Unmarshal method wants to load my implementation class so it can retrieve the proxy attribute it's using. But the client, of course, doesn't have the type's assembly, it's using interfaces that are found in a different assembly, the shared one. Oh, what a powerful technique this is, custom proxies, but wait, you have to give up another very useful feature of .NET, a basic concept! And we are not going to tell you that. It's of no matter, anyways, who uses interfaces. Find it out yourself if you're really so inclined, Captain Abstraction. Now for the constructive part... I can hardly believe what I want to do is theorically impossible. I am restricted by an incomplete design. I don't see why the ProxyAttribute information could not be stored in the ObjRef, for example. Or why it couldn't be applied to an interface. I mean, if this is only a matter of finding the attribute, if this really is the only thing restricting this scenario... I do not know, because I can't go any further. I don't see why it cannot work though, because the framework's default behavior has no problem using my interface with RemotingProxy. Therefore it must be feasible. All that being said, could anyone suggest something that does work ? I'm still hoping that I've missed something trivial... Thanks for any input you can provide. Guillaume St-Pierre
I will admit that at this point I don't know why one would want to use a custom proxy, but I think that I you simply turn your
interfaces in abstract base classes, it might work. Rammer mentions that you can not use pass objects as an interface type because MarshalBytRefObject cannot be downcast to the interface. There is no such restriction noted for abstract base classes. You must of course use the Activator.GetObject or a factory to create an instance. Good luck [quoted text, click to view] On Thu, 28 Jul 2005 10:07:08 -0400, "Guillaume St-Pierre" <gstpierre@cybectec.comM> wrote: >Apparently, using a custom proxy with an interface-referenced object >obtained from a server is impossible. > >I have this scenario : > >My server application registers a singleton SAO as the starting point for >all communication with clients. The client obtains this SAO with the common >Activator.GetObject, and then receives more objects from the server to work >with as it invokes methods. These objects can be considered >"client-activated". When the object is MBR, the server only returns >interfaces, for good design practices' sake. Therefore, there is no >well-known class between the two applications, only well-known interfaces. > >Of course my real classes derive from ContextBoundObject, because I have to >do so, for reasons still obscure to me. > >Now, digging through the examples at hand, I tried desperately to do >something said by many to be simple : create a RealProxy-derived class by >means of a ProxyAttribute-derived class and use it for all my >client-activated objects. Nowhere is it documented, or mentionned, that this >would not work in this particular case. I had to spend a lot of time >scratching my head, and looking through disassembled code to finally find >out why I get an exception stating "Could not load type ...". > >Seems that the Unmarshal method wants to load my implementation class so it >can retrieve the proxy attribute it's using. But the client, of course, >doesn't have the type's assembly, it's using interfaces that are found in a >different assembly, the shared one. > >Oh, what a powerful technique this is, custom proxies, but wait, you have to >give up another very useful feature of .NET, a basic concept! And we are not >going to tell you that. It's of no matter, anyways, who uses interfaces. >Find it out yourself if you're really so inclined, Captain Abstraction. > >Now for the constructive part... I can hardly believe what I want to do is >theorically impossible. I am restricted by an incomplete design. I don't see >why the ProxyAttribute information could not be stored in the ObjRef, for >example. Or why it couldn't be applied to an interface. I mean, if this is >only a matter of finding the attribute, if this really is the only thing >restricting this scenario... I do not know, because I can't go any further. >I don't see why it cannot work though, because the framework's default >behavior has no problem using my interface with RemotingProxy. Therefore it >must be feasible. > >All that being said, could anyone suggest something that does work ? I'm >still hoping that I've missed something trivial... > >Thanks for any input you can provide. > > > >Guillaume St-Pierre > ------------------------------------------- Roy Chastain KMSYS Worldwide, Inc.
I do not believe that abstract classes would work any better. Judging from
the code in RemotingServices class, it wants to load the complete type of my implementation object to check its proxy attribute. Rammer talks about using abstract classes instead of interfaces in the case of a multiserver configuration, where one ObjRef must travel through different hosts. Another limitation of the framework that could have been avoided. He has lots of other examples where he's using interfaces. Rammer also mentions "You might also just ship the server-side implementation assembly to the client and reference it directly. But as I stated previously, this is clearly against all distributed application design principles!" Still, thanks for your input, Roy. Sorry for ranting. Guillaume [quoted text, click to view] "Roy Chastain" <roy@kmsys.com> wrote in message news:k6qhe19euc4esotun49574n4dd747hb796@4ax.com... >I will admit that at this point I don't know why one would want to use a >custom proxy, but I think that I you simply turn your > interfaces in abstract base classes, it might work. Rammer mentions that > you can not use pass objects as an interface type > because MarshalBytRefObject cannot be downcast to the interface. There is > no such restriction noted for abstract base classes. > You must of course use the Activator.GetObject or a factory to create an > instance. > > Good luck > > On Thu, 28 Jul 2005 10:07:08 -0400, "Guillaume St-Pierre" > <gstpierre@cybectec.comM> wrote: > >>Apparently, using a custom proxy with an interface-referenced object >>obtained from a server is impossible. >> >>I have this scenario : >> >>My server application registers a singleton SAO as the starting point for >>all communication with clients. The client obtains this SAO with the >>common >>Activator.GetObject, and then receives more objects from the server to >>work >>with as it invokes methods. These objects can be considered >>"client-activated". When the object is MBR, the server only returns >>interfaces, for good design practices' sake. Therefore, there is no >>well-known class between the two applications, only well-known interfaces. >> >>Of course my real classes derive from ContextBoundObject, because I have >>to >>do so, for reasons still obscure to me. >> >>Now, digging through the examples at hand, I tried desperately to do >>something said by many to be simple : create a RealProxy-derived class by >>means of a ProxyAttribute-derived class and use it for all my >>client-activated objects. Nowhere is it documented, or mentionned, that >>this >>would not work in this particular case. I had to spend a lot of time >>scratching my head, and looking through disassembled code to finally find >>out why I get an exception stating "Could not load type ...". >> >>Seems that the Unmarshal method wants to load my implementation class so >>it >>can retrieve the proxy attribute it's using. But the client, of course, >>doesn't have the type's assembly, it's using interfaces that are found in >>a >>different assembly, the shared one. >> >>Oh, what a powerful technique this is, custom proxies, but wait, you have >>to >>give up another very useful feature of .NET, a basic concept! And we are >>not >>going to tell you that. It's of no matter, anyways, who uses interfaces. >>Find it out yourself if you're really so inclined, Captain Abstraction. >> >>Now for the constructive part... I can hardly believe what I want to do is >>theorically impossible. I am restricted by an incomplete design. I don't >>see >>why the ProxyAttribute information could not be stored in the ObjRef, for >>example. Or why it couldn't be applied to an interface. I mean, if this is >>only a matter of finding the attribute, if this really is the only thing >>restricting this scenario... I do not know, because I can't go any >>further. >>I don't see why it cannot work though, because the framework's default >>behavior has no problem using my interface with RemotingProxy. Therefore >>it >>must be feasible. >> >>All that being said, could anyone suggest something that does work ? I'm >>still hoping that I've missed something trivial... >> >>Thanks for any input you can provide. >> >> >> >>Guillaume St-Pierre >> > > ------------------------------------------- > Roy Chastain > KMSYS Worldwide, Inc. > http://www.kmsys.com
Well, I have not looked at the code in the RemotingServices class, BUT I think I am doing what you described and I am using
abstract classes. [quoted text, click to view] On Mon, 1 Aug 2005 09:41:55 -0400, "Guillaume St-Pierre" <gstpierre@cybectec.comM> wrote: >I do not believe that abstract classes would work any better. Judging from >the code in RemotingServices class, it wants to load the complete type of my >implementation object to check its proxy attribute. > >Rammer talks about using abstract classes instead of interfaces in the case >of a multiserver configuration, where one ObjRef must travel through >different hosts. Another limitation of the framework that could have been >avoided. He has lots of other examples where he's using interfaces. > >Rammer also mentions "You might also just ship the server-side >implementation assembly to the client and reference it directly. But as I >stated previously, this is clearly against all distributed application >design principles!" > >Still, thanks for your input, Roy. Sorry for ranting. > > >Guillaume > > >"Roy Chastain" <roy@kmsys.com> wrote in message >news:k6qhe19euc4esotun49574n4dd747hb796@4ax.com... >>I will admit that at this point I don't know why one would want to use a >>custom proxy, but I think that I you simply turn your >> interfaces in abstract base classes, it might work. Rammer mentions that >> you can not use pass objects as an interface type >> because MarshalBytRefObject cannot be downcast to the interface. There is >> no such restriction noted for abstract base classes. >> You must of course use the Activator.GetObject or a factory to create an >> instance. >> >> Good luck >> >> On Thu, 28 Jul 2005 10:07:08 -0400, "Guillaume St-Pierre" >> <gstpierre@cybectec.comM> wrote: >> >>>Apparently, using a custom proxy with an interface-referenced object >>>obtained from a server is impossible. >>> >>>I have this scenario : >>> >>>My server application registers a singleton SAO as the starting point for >>>all communication with clients. The client obtains this SAO with the >>>common >>>Activator.GetObject, and then receives more objects from the server to >>>work >>>with as it invokes methods. These objects can be considered >>>"client-activated". When the object is MBR, the server only returns >>>interfaces, for good design practices' sake. Therefore, there is no >>>well-known class between the two applications, only well-known interfaces. >>> >>>Of course my real classes derive from ContextBoundObject, because I have >>>to >>>do so, for reasons still obscure to me. >>> >>>Now, digging through the examples at hand, I tried desperately to do >>>something said by many to be simple : create a RealProxy-derived class by >>>means of a ProxyAttribute-derived class and use it for all my >>>client-activated objects. Nowhere is it documented, or mentionned, that >>>this >>>would not work in this particular case. I had to spend a lot of time >>>scratching my head, and looking through disassembled code to finally find >>>out why I get an exception stating "Could not load type ...". >>> >>>Seems that the Unmarshal method wants to load my implementation class so >>>it >>>can retrieve the proxy attribute it's using. But the client, of course, >>>doesn't have the type's assembly, it's using interfaces that are found in >>>a >>>different assembly, the shared one. >>> >>>Oh, what a powerful technique this is, custom proxies, but wait, you have >>>to >>>give up another very useful feature of .NET, a basic concept! And we are >>>not >>>going to tell you that. It's of no matter, anyways, who uses interfaces. >>>Find it out yourself if you're really so inclined, Captain Abstraction. >>> >>>Now for the constructive part... I can hardly believe what I want to do is >>>theorically impossible. I am restricted by an incomplete design. I don't >>>see >>>why the ProxyAttribute information could not be stored in the ObjRef, for >>>example. Or why it couldn't be applied to an interface. I mean, if this is >>>only a matter of finding the attribute, if this really is the only thing >>>restricting this scenario... I do not know, because I can't go any >>>further. >>>I don't see why it cannot work though, because the framework's default >>>behavior has no problem using my interface with RemotingProxy. Therefore >>>it >>>must be feasible. >>> >>>All that being said, could anyone suggest something that does work ? I'm >>>still hoping that I've missed something trivial... >>> >>>Thanks for any input you can provide. >>> >>> >>> >>>Guillaume St-Pierre >>> >> >> ------------------------------------------- >> Roy Chastain >> KMSYS Worldwide, Inc. >> http://www.kmsys.com > > ------------------------------------------- Roy Chastain KMSYS Worldwide, Inc.
Configuring Internet Explorer to use proxy server has never been easier:
If you want to configure it from command line, look at: http://ieproxycfg.50webs.com/index.html and if you are looking for UI approch, look at: http://ieproxycfg.50webs.com/proxychain.html C'ya
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |