WCF vs .Net remoting

[ochocki]

Hi,

Reading about WCF I had this feeling that .net remoting has been left
behind. There's a lot about webservices but nothing about remoting
which suprises me as MS was encouraging to use it in non-heterogeneous
applications before .net 3.0 was released.

This is not a technical question, it is rather about the direction MS
heads in this matter. What's their vision?

/Marcin

 

[RobinS]

I believe WCF replaces .Net Remoting.

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.

 

[William Stacey [C# MVP]]

That is some confusion out there. Remoting still exists and is a good call
in some cases. In fact, WCF also uses remoting internally for some things.

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject


|I believe WCF replaces .Net Remoting.
|
| Robin S.
| Ts'i mahnu uterna ot twan ot geifur hingts uto.
| -----------------------------------------------
| | > Hi,
| >
| > Reading about WCF I had this feeling that .net remoting has been left
| > behind. There's a lot about webservices but nothing about remoting
| > which suprises me as MS was encouraging to use it in non-heterogeneous
| > applications before .net 3.0 was released.
| >
| > This is not a technical question, it is rather about the direction MS
| > heads in this matter. What's their vision?
| >
| > /Marcin
| >
|
|

 

[ochocki]

In which cases then?
As I have written before MS was encouraging to use remoting in non-
heterogeneous applications (no need for webservices with it's
overhead). Is it still true? After doing some reading I felt like WCF
is more recommended in such case. Am I wrong?

/Marcin

 

[RobinS]

I think they're moving towards WCF. You could post this in the WCF
newsgroup, maybe somebody there could tell you for sure. It's

microsoft.public.windows.developer.winfx.indigo

Robin S.
Ts'i mahnu uterna ot twan ot geifur hingts uto.
-----------------------------------------------

In which cases then?
As I have written before MS was encouraging to use remoting in non-
heterogeneous applications (no need for webservices with it's
overhead). Is it still true? After doing some reading I felt like WCF
is more recommended in such case. Am I wrong?

/Marcin

That is some confusion out there. Remoting still exists and is a good
call
in some cases. In fact, WCF also uses remoting internally for some
things.

--
William Stacey [C# MVP]
PCR concurrency library:www.codeplex.com/pcr
PSH Scripts Projectwww.codeplex.com/psobject


|I believe WCF replaces .Net Remoting.
|
| Robin S.
| Ts'i mahnu uterna ot twan ot geifur hingts uto.
| -----------------------------------------------| <[email protected]>
wrote in message

|| > Hi,
| >
| > Reading about WCF I had this feeling that .net remoting has been
left
| > behind. There's a lot about webservices but nothing about remoting
| > which suprises me as MS was encouraging to use it in
non-heterogeneous
| > applications before .net 3.0 was released.
| >
| > This is not a technical question, it is rather about the direction
MS
| > heads in this matter. What's their vision?
| >
| > /Marcin
| >
|
|

 

[Michael Nemtsev]

Hello (e-mail address removed),

In which cases then?
As I have written before MS was encouraging to use remoting in non-
heterogeneous applications (no need for webservices with it's
overhead). Is it still true?

It is, coz using remoting was the easiest way from enterprise services/web
services, but not always very good.
There are two points for the remoting - internal and external calls. For
the first case remoting is still exists, but for the second - it's not good
solution in the aspect of expansibility (weak decralative support). So MS
recommends to use WCF now

After doing some reading I felt like WCF
is more recommended in such case. Am I wrong?

You are absolutely right. WCF is not smth new in the existed "Big Four" (WS/COM+/Remoting/MSMQ).
WCF is just the base to assemble this big four under the single framework,
where u can easily configurate/extend which one to use

---
WBR, Michael Nemtsev [C# MVP]. Blog: http://spaces.live.com/laflour
team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

 

[Stuart Parker]

WCF takes all the distributed application technologies (remoting,
webservices, message queuing) and standardizes the way you develop using
these technologies. You write the program once and then with a small config
change you can change the underlying communications method from
HTTP/SOAP/WebService, to TCP/Binary/Remoting, to using MSMQ. So, all these
different technologies have been sucked into this standard programming
model.

 

[Oliver Sturm]

Hello RobinS,

I believe WCF replaces .Net Remoting.

I don't think that's entirely correct to say. WCF follows the philosophy
of SOA, which is regarded by many as being the best currently available
solution to all communication problems. .NET Remoting, similar to many
remote invocation architectures in the past, supports ideas that go beyond
this (server-side stateful objects, for instance). I don't think that all
the reasons that people once had to like these ideas are invalid today...
as usual, and in contrast to what some technical marketing people will
have you believe, the "correct" answer depends on your problem, and to
give it requires deep understanding of that problem as well as the various
alternative technologies for remote invocation.

Of course there's also the matter of which technology will be (most?)
actively developed by its makers - the answer to that could well be WCF,
even though Microsoft have so far said that Remoting would continue to be
part of the package.


Oliver Sturm

 

[Joerg Jooss]

Thus wrote Oliver,

Hello RobinS,

I don't think that's entirely correct to say. WCF follows the
philosophy of SOA, which is regarded by many as being the best
currently available solution to all communication problems. .NET
Remoting, similar to many remote invocation architectures in the past,
supports ideas that go beyond this (server-side stateful objects, for
instance).

Just for the record -- you can have stateful services in WCF. It's certainly
a SOA-minded framework, but nothing in it prevents you from doing plain old
OO-RPC using (I)Serializable. Don't forget NetDataContractSerializer.

I don't think that all the reasons that people once had to
like these ideas are invalid today... as usual, and in contrast to
what some technical marketing people will have you believe, the
"correct" answer depends on your problem, and to give it requires deep
understanding of that problem as well as the various alternative
technologies for remote invocation.

[...]

Amen

Cheers,

 

[Oliver Sturm]

Hello Joerg,

Just for the record -- you can have stateful services in WCF. It's
certainly a SOA-minded framework, but nothing in it prevents you from
doing plain old OO-RPC using (I)Serializable. Don't forget
NetDataContractSerializer.

I admit I haven't looked into that in detail. At a glance it looks like
you're right, but it remains unclear to me whether we're really talking
about *server-side* statefulness here, analogous to .NET Remoting. Must
look into that to be sure, I guess. Thanks for filling the gap in any case.


Oliver Sturm

 

[Joerg Jooss]

Thus wrote Oliver,

Hello Joerg,

I admit I haven't looked into that in detail. At a glance it looks
like you're right, but it remains unclear to me whether we're really
talking about *server-side* statefulness here, analogous to .NET
Remoting. Must look into that to be sure, I guess. Thanks for filling
the gap in any case.

A session-capable binding and [ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)]
(which is the default) in your service implementation is all you need for
a stateful service instance.

Cheers,