Re: Why Neglect .Net Remoting

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Rick Winscot ((_at_))
Date: 12/27/04 

Date: Mon, 27 Dec 2004 04:29:20 -0600

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

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message news:u%238l%23cSvEHA.1296@TK2MSFTNGP10.phx.gbl...
> "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.
>
> "Howard Swope" <howardsnewsATspitzincDOTcom> wrote in message
> news:eddeENSvEHA.1308@TK2MSFTNGP09.phx.gbl...
>> 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).
>>
>> "Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
>> wrote in message news:epiZr2RvEHA.1404@TK2MSFTNGP11.phx.gbl...
>>> 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=en&lr=lang_en&threadm=OiKw46HZEHA.2576%40TK2MSFTNGP10.phx.gbl&rnum=4&prev=/groups%3Fhl%3Den%26lr%3Dlang_en%26q%3Dremoting%26meta%3Dgroup%253Dmicrosoft.public.dotnet.framework.compactframework
>>>
>>> Paul T.
>>>
>>>
>>> "Howard Swope" <howardsnewsATspitzincDOTcom> wrote in message
>>> news:enaDJuRvEHA.680@TK2MSFTNGP10.phx.gbl...
>>> > 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.
>>> >
>>> > ???
>>> >
>>> > --
>>> > Howard Swope [howardsnewsATspitzincDOTcom]
>>> > Software Engineer
>>> > Spitz, Inc [http://www.spitzinc.com]
>>> >
>>> >
>>>
>>>
>>
>>
>
>

Relevant Pages

  • Re: And Speaking of Other Windows Crap
    ... Web applications (which most users probably don't think of as ... The only special code that resides on the ... object" on a server somewhere--the nearest equivalent of a COM object. ... In fact, however, most people seem to prefer Web services over .NET ...
    (rec.audio.pro)
  • Re: Anybody notice that Microsoft doesnt write in .Net?
    ... It has always seemed to me that it is more suited to web applications than desktop applications, although the name may have some bearing on that. ... That's been my theory all along...that Microsoft wrote .Net to further their internal goals of software-as-a-service and just decided to drag everyone else down that misguided path for 2 reasons. ... Rather, it is a set of capabilities in products that enables people, information, systems, and devices to connect and exchange information seamlessly through the use of Web services. ... There is also .NET Biz Talk server that allows .NET applications and applications running on mainframes to communicate with each other through the use of XML over TCP that have nothing to do with Web services, ...
    (microsoft.public.dotnet.general)
  • Re: how can you use mshtml DOM object to grab rendered asp.net page?
    ... > to generate your charts, html tables, and other output mechanisms? ... > even in VBA in Office applications. ... you can call the methods via web services and not have to bother ... >> PowerPoint with 2 simple lines of code, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Is .net faster tht vb6?
    ... >>to connect to the Web and use web services. ... That give some points to VB6. ... > C applications without it's satellite DLLs won't run either, ... We only support 2K and XP now... ...
    (comp.lang.basic.visual.misc)
  • Re: Why Neglect .Net Remoting
    ... "Web Services" is really just the name. ... > Our applications are too resource intensive to bare http, xml, or soap. ... > can barely stand binary serialization of objects, ... > hardware revision of our device is moving many of the time critical ...
    (microsoft.public.dotnet.framework.compactframework)