[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Remoting large object efficiently

Joel

7/7/2004 2:00:00 PM

I have a fairly "heavy" data access assembly that was written without
remoting in mind (it's not interface based, etc.). Currently we access it
through a cumbersome method of writing a client class and a server class for
each business object based on an interface just so the server class can
access the data access assembly:

client class -> (remoting) -> server class -> data access assembly.

Simple enough until you have hundreds of objects.

I'd like to remote the data access assembly directly but I don't want to
install the entire code base on the client machines just to have the type
information available.

It struck me that I could get around the client installation by redirecting
the client using the <dependentAssembly> and <codeBase> app.config elements
to point the client at the server's assembly for runtime type information
but then also remote the client to instantiate the object at the server (I'm
not sure wether to do CAO or SAO yet, I'll explore that once I figure this
out).

My question is: When the client gets the type information (redirected to the
codeBase on the server) is it pulling the whole "heavy" class across or just
type information? If it's pulling the whole class it sort of defeats the
purpose -- at least from a performance standpoint. But if it just gets the
type information then it might work for me. TIA

</joel>
4 Answers

Allen Anderson

7/7/2004 2:50:00 PM

0

this depends on how you specify it. The server won''t "send" the class
over the wire to be remoted (thats a fairly common question). You
have to either put the implementation assembly on the client or use
abstract class/interface proxy classes in.

Whether to go with an SAO or CAO really depends on your business
object layout. If the business objects are stateless then you can use
SAO singlecall without any problem. If not and you need to mvoe a lot
of data in several smaller chunks then your better off with a CAO
object.

You can check this article out for a simple implementation of the
client proxy systems.

http://www.glacialcomp.../ArticleDetail.aspx?articleID=Re...

Cheers,
Allen Anderson
http://www.glacialcomp...
mailto: allen@put my website base here.com

On Wed, 7 Jul 2004 10:00:02 -0400, "Joel" <joelycat@hotmail.com>
wrote:

>I have a fairly "heavy" data access assembly that was written without
>remoting in mind (it''s not interface based, etc.). Currently we access it
>through a cumbersome method of writing a client class and a server class for
>each business object based on an interface just so the server class can
>access the data access assembly:
>
>client class -> (remoting) -> server class -> data access assembly.
>
>Simple enough until you have hundreds of objects.
>
>I''d like to remote the data access assembly directly but I don''t want to
>install the entire code base on the client machines just to have the type
>information available.
>
>It struck me that I could get around the client installation by redirecting
>the client using the <dependentAssembly> and <codeBase> app.config elements
>to point the client at the server''s assembly for runtime type information
>but then also remote the client to instantiate the object at the server (I''m
>not sure wether to do CAO or SAO yet, I''ll explore that once I figure this
>out).
>
>My question is: When the client gets the type information (redirected to the
>codeBase on the server) is it pulling the whole "heavy" class across or just
>type information? If it''s pulling the whole class it sort of defeats the
>purpose -- at least from a performance standpoint. But if it just gets the
>type information then it might work for me. TIA
>
></joel>
>

Joel

7/7/2004 3:19:00 PM

0

Thanks, but I understand that the object isn''t "sent" over to the client
upon instatiation. What I''m trying to accomplish is to elminate the need to
have to put either the implementation assembly or use interfaces, proxy,
etc.

Let me try to clarify my idea:

* Server has assembly A (our "heavy" assembly) whose codeBase is accessible
from url "http://Server/A.dll"

* Client app.config contains (in the runtime section):

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="A"
publicKeyToken="6d23536ba2ebd1d7"
/>
<codeBase version="1.0.0.0"
href="http://Server/A.dll"/>
</dependentAssembly>
</assemblyBinding>

so at runtime, when Client attempts to load assembly A it gets the codebase
from Server.

* Client app.config also has (in the remoting section):

<application name="MyApp">
<client>
<wellknown
type="MyApp,A"
url="tcp://Server:8989/A.rem"
displayName="A"
/>
</client>
</application>

* I beleive in this scenario Client will gets it''s type information from
Server''s codebase but the objects will be instatiated on the server.

My question is: When Client references type A does it pull over the entire
"heavy" object to get the type information (before it''s actually
instantiated on Server) or is retreiving the type information from an
assembly a light-weight operation?

TIA

"Allen Anderson" <allen@sparkysystems.com> wrote in message
news:833oe0dkill5q0e6bgiqjlop6bumhd8gm7@4ax.com...
> this depends on how you specify it. The server won''t "send" the class
> over the wire to be remoted (thats a fairly common question). You
> have to either put the implementation assembly on the client or use
> abstract class/interface proxy classes in.
>
> Whether to go with an SAO or CAO really depends on your business
> object layout. If the business objects are stateless then you can use
> SAO singlecall without any problem. If not and you need to mvoe a lot
> of data in several smaller chunks then your better off with a CAO
> object.
>
> You can check this article out for a simple implementation of the
> client proxy systems.
>
> http://www.glacialcomp.../ArticleDetail.aspx?articleID=Re...
>
> Cheers,
> Allen Anderson
> http://www.glacialcomp...
> mailto: allen@put my website base here.com
>
> On Wed, 7 Jul 2004 10:00:02 -0400, "Joel" <joelycat@hotmail.com>
> wrote:
>
> >I have a fairly "heavy" data access assembly that was written without
> >remoting in mind (it''s not interface based, etc.). Currently we access it
> >through a cumbersome method of writing a client class and a server class
for
> >each business object based on an interface just so the server class can
> >access the data access assembly:
> >
> >client class -> (remoting) -> server class -> data access assembly.
> >
> >Simple enough until you have hundreds of objects.
> >
> >I''d like to remote the data access assembly directly but I don''t want to
> >install the entire code base on the client machines just to have the type
> >information available.
> >
> >It struck me that I could get around the client installation by
redirecting
> >the client using the <dependentAssembly> and <codeBase> app.config
elements
> >to point the client at the server''s assembly for runtime type information
> >but then also remote the client to instantiate the object at the server
(I''m
> >not sure wether to do CAO or SAO yet, I''ll explore that once I figure
this
> >out).
> >
> >My question is: When the client gets the type information (redirected to
the
> >codeBase on the server) is it pulling the whole "heavy" class across or
just
> >type information? If it''s pulling the whole class it sort of defeats the
> >purpose -- at least from a performance standpoint. But if it just gets
the
> >type information then it might work for me. TIA
> >
> ></joel>
> >
>

Ken Kolda

7/7/2004 5:06:00 PM

0

You''ll get the whole assembly pulled from the server. In fact, I believe it
will pull it over at the point it JITs the class that references any type
from that assembly (i.e. before you actually instantiate your remote
object).

Ken


"Joel" <joelycat@hotmail.com> wrote in message
news:Oy3ZUUDZEHA.1448@TK2MSFTNGP12.phx.gbl...
> Thanks, but I understand that the object isn''t "sent" over to the client
> upon instatiation. What I''m trying to accomplish is to elminate the need
to
> have to put either the implementation assembly or use interfaces, proxy,
> etc.
>
> Let me try to clarify my idea:
>
> * Server has assembly A (our "heavy" assembly) whose codeBase is
accessible
> from url "http://Server/A.dll"
>
> * Client app.config contains (in the runtime section):
>
> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
> <dependentAssembly>
> <assemblyIdentity name="A"
> publicKeyToken="6d23536ba2ebd1d7"
> />
> <codeBase version="1.0.0.0"
> href="http://Server/A.dll"/>
> </dependentAssembly>
> </assemblyBinding>
>
> so at runtime, when Client attempts to load assembly A it gets the
codebase
> from Server.
>
> * Client app.config also has (in the remoting section):
>
> <application name="MyApp">
> <client>
> <wellknown
> type="MyApp,A"
> url="tcp://Server:8989/A.rem"
> displayName="A"
> />
> </client>
> </application>
>
> * I beleive in this scenario Client will gets it''s type information from
> Server''s codebase but the objects will be instatiated on the server.
>
> My question is: When Client references type A does it pull over the entire
> "heavy" object to get the type information (before it''s actually
> instantiated on Server) or is retreiving the type information from an
> assembly a light-weight operation?
>
> TIA
>
> "Allen Anderson" <allen@sparkysystems.com> wrote in message
> news:833oe0dkill5q0e6bgiqjlop6bumhd8gm7@4ax.com...
> > this depends on how you specify it. The server won''t "send" the class
> > over the wire to be remoted (thats a fairly common question). You
> > have to either put the implementation assembly on the client or use
> > abstract class/interface proxy classes in.
> >
> > Whether to go with an SAO or CAO really depends on your business
> > object layout. If the business objects are stateless then you can use
> > SAO singlecall without any problem. If not and you need to mvoe a lot
> > of data in several smaller chunks then your better off with a CAO
> > object.
> >
> > You can check this article out for a simple implementation of the
> > client proxy systems.
> >
> >
http://www.glacialcomp.../ArticleDetail.aspx?articleID=Re...
> >
> > Cheers,
> > Allen Anderson
> > http://www.glacialcomp...
> > mailto: allen@put my website base here.com
> >
> > On Wed, 7 Jul 2004 10:00:02 -0400, "Joel" <joelycat@hotmail.com>
> > wrote:
> >
> > >I have a fairly "heavy" data access assembly that was written without
> > >remoting in mind (it''s not interface based, etc.). Currently we access
it
> > >through a cumbersome method of writing a client class and a server
class
> for
> > >each business object based on an interface just so the server class can
> > >access the data access assembly:
> > >
> > >client class -> (remoting) -> server class -> data access assembly.
> > >
> > >Simple enough until you have hundreds of objects.
> > >
> > >I''d like to remote the data access assembly directly but I don''t want
to
> > >install the entire code base on the client machines just to have the
type
> > >information available.
> > >
> > >It struck me that I could get around the client installation by
> redirecting
> > >the client using the <dependentAssembly> and <codeBase> app.config
> elements
> > >to point the client at the server''s assembly for runtime type
information
> > >but then also remote the client to instantiate the object at the server
> (I''m
> > >not sure wether to do CAO or SAO yet, I''ll explore that once I figure
> this
> > >out).
> > >
> > >My question is: When the client gets the type information (redirected
to
> the
> > >codeBase on the server) is it pulling the whole "heavy" class across or
> just
> > >type information? If it''s pulling the whole class it sort of defeats
the
> > >purpose -- at least from a performance standpoint. But if it just gets
> the
> > >type information then it might work for me. TIA
> > >
> > ></joel>
> > >
> >
>
>

Allen Anderson

7/7/2004 6:37:00 PM

0

I know what your asking. Like I said, no, you can''t eliminate the
need to have interfaces, proxies, or implementation assemblies, or
something on the client side. There has to be either a proxy or
something to access the object through.

>Thanks, but I understand that the object isn''t "sent" over to the client
>upon instatiation. What I''m trying to accomplish is to elminate the need to
>have to put either the implementation assembly or use interfaces, proxy,
>etc.
>
>Let me try to clarify my idea:
>
>* Server has assembly A (our "heavy" assembly) whose codeBase is accessible
>from url "http://Server/A.dll"
>
>* Client app.config contains (in the runtime section):
>
> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
> <dependentAssembly>
> <assemblyIdentity name="A"
> publicKeyToken="6d23536ba2ebd1d7"
> />
> <codeBase version="1.0.0.0"
> href="http://Server/A.dll"/>
> </dependentAssembly>
> </assemblyBinding>
>
>so at runtime, when Client attempts to load assembly A it gets the codebase
>from Server.
>
>* Client app.config also has (in the remoting section):
>
> <application name="MyApp">
> <client>
> <wellknown
> type="MyApp,A"
> url="tcp://Server:8989/A.rem"
> displayName="A"
> />
> </client>
> </application>
>
>* I beleive in this scenario Client will gets it''s type information from
>Server''s codebase but the objects will be instatiated on the server.
>
>My question is: When Client references type A does it pull over the entire
>"heavy" object to get the type information (before it''s actually
>instantiated on Server) or is retreiving the type information from an
>assembly a light-weight operation?