Remoting Best Practices

#1

Good read especially for those building distributed applications on a LAN.

http://www.ingorammer.com/RemotingFA...gUseCases.html

ice

#2

I think your sample is perfectly ok.

I think the issue is when you pass a MBR object as a parmater into a remote
object.

//remote class
public class MyObject: MarshalByRefObject
{
public MyObject() {}

//couple of getters/setters (excuse old lingo)
}

//remote server registered with remoting
public class RemoteServer: MarshalByRefObject
{
public RemoteServer() {}
public Save(MyObject dataToSave)
{}
}

//client
public class MyClient
{
MyObject myobject = new MyObject();
RemotingConfiguration("file.config");
RemoteServer.Save(myobject);
}

in this scenario, the file wouldn't be saved on the server, it would be save
on the client, where it was instantiated, ultimately, the client requires a
open port for "callback".

make sense?
ice

"TEK" <trondeirikkolloen (AT) hotmail (DOT) com> wrote

Quote:

Hay

Thanks for the link...

Any good ideas about why you should not be using MarshalByRef objects?

For example, if you are having a object that has a save method, like this:

public class MyObject : MarshalByRef{
public MyObject();
public void SaveSomething(MyObjectInfo objtoSave){
SaveToFile("c:\temp\myobjdata.txt", objtoSave.Data);
}
}

What if you executed this metod using Serializable instead of
MarshalByRef?
Would not the file be actually saved on the client, while the goal was to
save the object on the server?

Isn't one of the objectives of using use MarshalByRef to actually get the
prosessing of the data done on the server, and not on the client?

I'm I misunderstanding something here???
Does "don't pass any MarshalByRefObject over a remoting boundary" means
something else than "do not use MarshalByRefObject"?

...help...

regards, TEK

"Ice" <ice (AT) nospam (DOT) com> skrev i melding
news:OkOa5FxODHA.304 (AT) tk2msftngp13 (DOT) phx.gbl...
Good read especially for those building distributed applications on a LA
N.

http://www.ingorammer.com/RemotingFA...gUseCases.html

ice

#3

Hei Ice

"Ice" <ice (AT) nospam (DOT) com> skrev i melding
news:%23LjUh5yODHA.2228 (AT) tk2msftngp13 (DOT) phx.gbl...

Quote:

I think your sample is perfectly ok.

I think the issue is when you pass a MBR object as a parmater into a
remote
object.

That's making more sence...

Quote:

//remote class
public class MyObject: MarshalByRefObject
{
public MyObject() {}

//couple of getters/setters (excuse old lingo)
}

//remote server registered with remoting
public class RemoteServer: MarshalByRefObject
{
public RemoteServer() {}
public Save(MyObject dataToSave)
{}
}

//client
public class MyClient
{
MyObject myobject = new MyObject();
RemotingConfiguration("file.config");
RemoteServer.Save(myobject);
}

in this scenario, the file wouldn't be saved on the server, it would be
save
on the client, where it was instantiated, ultimately, the client requires
a
open port for "callback".

make sense?

Yes, I would not have used MarshalByRef objects as parameters to
remotemethods, that for sure. So in this case I completly agrees with Ingo,
just had to understand what he ment first.
(In my eyes input/output arguments and passing data between boundaries is
the exact reason for serializable objects).

Thank for the clerification Ice
--- still think Ingo should have added some more info about what he actually
ment...

Regards TEK

Quote:

ice

"TEK" <trondeirikkolloen (AT) hotmail (DOT) com> wrote in message
news:OD3%23XeyODHA.2244 (AT) TK2MSFTNGP11 (DOT) phx.gbl...
Hay

Thanks for the link...

Any good ideas about why you should not be using MarshalByRef objects?

For example, if you are having a object that has a save method, like
this:

public class MyObject : MarshalByRef{
public MyObject();
public void SaveSomething(MyObjectInfo objtoSave){
SaveToFile("c:\temp\myobjdata.txt", objtoSave.Data);
}
}

What if you executed this metod using Serializable instead of
MarshalByRef?
Would not the file be actually saved on the client, while the goal was
to
save the object on the server?

Isn't one of the objectives of using use MarshalByRef to actually get
the
prosessing of the data done on the server, and not on the client?

I'm I misunderstanding something here???
Does "don't pass any MarshalByRefObject over a remoting boundary" means
something else than "do not use MarshalByRefObject"?

...help...

regards, TEK

"Ice" <ice (AT) nospam (DOT) com> skrev i melding
news:OkOa5FxODHA.304 (AT) tk2msftngp13 (DOT) phx.gbl...
Good read especially for those building distributed applications on a
LA
N.

http://www.ingorammer.com/RemotingFA...gUseCases.html

ice

#4

Understood. I will say, this really makes me wonder about the future of
remoting (long term). I suppose for distributed objects, its a great
concept, but most enterprise applications I have worked with are more
service-based than anything.

ice

"TEK" <trondeirikkolloen (AT) hotmail (DOT) com> wrote

Quote:

Hei Ice

"Ice" <ice (AT) nospam (DOT) com> skrev i melding
news:%23LjUh5yODHA.2228 (AT) tk2msftngp13 (DOT) phx.gbl...
I think your sample is perfectly ok.

I think the issue is when you pass a MBR object as a parmater into a
remote
object.

That's making more sence...

//remote class
public class MyObject: MarshalByRefObject
{
public MyObject() {}

//couple of getters/setters (excuse old lingo)
}

//remote server registered with remoting
public class RemoteServer: MarshalByRefObject
{
public RemoteServer() {}
public Save(MyObject dataToSave)
{}
}

//client
public class MyClient
{
MyObject myobject = new MyObject();
RemotingConfiguration("file.config");
RemoteServer.Save(myobject);
}

in this scenario, the file wouldn't be saved on the server, it would be
save
on the client, where it was instantiated, ultimately, the client
requires
a
open port for "callback".

make sense?

Yes, I would not have used MarshalByRef objects as parameters to
remotemethods, that for sure. So in this case I completly agrees with
Ingo,
just had to understand what he ment first.
(In my eyes input/output arguments and passing data between boundaries is
the exact reason for serializable objects).

Thank for the clerification Ice
--- still think Ingo should have added some more info about what he
actually
ment...

Regards TEK

ice

"TEK" <trondeirikkolloen (AT) hotmail (DOT) com> wrote in message
news:OD3%23XeyODHA.2244 (AT) TK2MSFTNGP11 (DOT) phx.gbl...
Hay

Thanks for the link...

Any good ideas about why you should not be using MarshalByRef objects?

For example, if you are having a object that has a save method, like
this:

public class MyObject : MarshalByRef{
public MyObject();
public void SaveSomething(MyObjectInfo objtoSave){
SaveToFile("c:\temp\myobjdata.txt", objtoSave.Data);
}
}

What if you executed this metod using Serializable instead of
MarshalByRef?
Would not the file be actually saved on the client, while the goal was
to
save the object on the server?

Isn't one of the objectives of using use MarshalByRef to actually get
the
prosessing of the data done on the server, and not on the client?

I'm I misunderstanding something here???
Does "don't pass any MarshalByRefObject over a remoting boundary"
means
something else than "do not use MarshalByRefObject"?

...help...

regards, TEK

"Ice" <ice (AT) nospam (DOT) com> skrev i melding
news:OkOa5FxODHA.304 (AT) tk2msftngp13 (DOT) phx.gbl...
Good read especially for those building distributed applications on
a
LA
N.

http://www.ingorammer.com/RemotingFA...gUseCases.html

ice

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Remoting Best Practices

Dotnet Distributed Applications microsoft.public.dotnet.distributed_apps

Remoting Best Practices - 06-25-2003 , 08:01 AM

Re: Remoting Best Practices - 06-25-2003 , 11:28 AM

Re: Remoting Best Practices - 06-26-2003 , 02:22 AM

Re: Remoting Best Practices - 06-26-2003 , 07:42 AM