Why Neglect .Net Remoting

  • Thread starter Thread starter Howard Swope
  • Start date Start date
H

Howard Swope

Does anyone have any insight into why .Net Remoting has been so neglected in
the CF. It was the same for DCOM support in Windows CE. It wasn't until
version 4 that it was really supported. I got it to work under 3 jumping
through some hoops.

The argument that embedded devices traditionally don't do that is not a
valid argument given the wide range of applications that Windows CE has
targeted. Many of CE's intended targets are sophisticated appliances that
require higher level (more complex) applications.

The last three projects I have worked on, one of them on windows CE, have
had distributed component architectures. It has been an accepted paradigm
for some years now. It is upsetting that this is so neglected under CE. I
would think that such a fundamental technology would be high on the list of
priorities, especially for an application framework.

???
 
It's big (requires serialization, which is also not present, as well as the
remoting stuff itself), and it's not really the preferred method for
forward-looking applications, was my understanding.

It may be possible to code a different implementation of your distributed
architecture using Web Services

Searching for "remoting" in the archives gives a number of threads, but this
one suggests several alternatives (Web Services first):

http://groups.google.com/groups?hl=...soft.public.dotnet.framework.compactframework

Paul T.
 
Thanks for the information...

I have never understood the fascination with web services or the web for
that matter. It is a nice place to disseminate information, but it is a
lousy place to host an application. Just because companies won't open up any
other port but 80 is not a reason to try to squeeze all your objects through
it.

Our applications are too resource intensive to bare http, xml, or soap. They
can barely stand binary serialization of objects, but the applications are
too sophisticated not to be OO.

I love .Net and C# and wanted to migrate my CE application over, but it
looks like that's not going to happen for some time to come. :-(. The next
hardware revision of our device is moving many of the time critical software
functions into hardware. Maybe I can then move it over to embedded xp and a
full implementation of .Net.

We are also talking about making a light version of our appliance with a
PocketPC. Since there is not even DCOM on this I may try out web services
yet (or write sockets yuk).
 
"Web Services" is really just the name. The only thing that it has to do
with the Web is, as you say, how you communicate with it. My impression was
that remoting was generally being treated as deprecated, so you might want
to see what else you can do for the future timeframe. Putting the
time-critical stuff in hardware is good!

Paul T.
 
Paul,

I would also agree with Howard and would like to add that... The developer
should be the domain expert... and is (in the end) the one that selects the
appropriate technology [foundation] for any particular solution. In the case
of network driven applications, we have to consider performance, security,
interoperability, visibility and scalability. Web Services have their
plusses... and so does Remoting. Saying that one is superior over the other
[without context], or that one is considered 'deprecated' is a farce and
fails to identify how these tools should be used (properly). The danger here
[in my mind] is that your recommendations can lead people into driving down
a single path in their development... without questioning implementation. I
could go on but the original issue needs a response.

In reflecting upon the original post... the answer is clear! We all know
that the .NET CF _could_ get very large and that Microsoft has made a
conscious effort to keep the [size of the] mobile implementation
commensurate with the potential use case. IMHO the reason(s) that remoting
is not included in the CF is mostly due to size requirements imposed by
realizing the serializable interfaces for remoting (very costly). The need
for XML support in the CF was already 'a given' to support application
development... then... web services was a natural choice to implement the
least costly method to get CF apps to 'share the wealth' in network aware
applications. Not to mention that web services is really the direction that
MS is headed... What we are seeing now is an explosion of use cases... where
developers require greater flexibility in tool-sets with the ultimate
revelation that one tool cannot solve all development problems equally well.
This sturm-en-drang isn't bad... it is merely one of the steps in realizing
that it may now be time that the value of a particular implementation
out-weighs the potential increase in size of the CF.

There are some really good posts on Chris Taylors blog on
www.dotnetjunkies.com found at:
http://dotnetjunkies.com/WebLog/chris.taylor/archive/2004/01/31/6385.aspx

Cheers,

Rick Winscot
www.zyche.com
 
Back
Top