I never touched COM+ with any length of pole... the sheer complexity scared
me off. I don't know if that gives me any more credibility than Don, but
I'll pick up his slack and be openly derisive of Remoting too. ;-)
1) There is no safe, robust out-the-box remoting channel appropriate for
IPC. The closest you can get is to use TcpChannel, bind to an arbitrary
port on localhost and remember ot set rejectRemoteRequests=true. But then
you have to publish your endpoint somewhere -- most folks use a key in HKCU,
but that breaks on W2k3 Server (which allows multiple termsrv sessions of
the same user)! And of course, on a multiuser TS box, you'd better have
taken some means to keep other users from stumbling into your TCP endpoint
too -- can you say "elevation of privilege"?
You can get a little closer with Jonathan Hawkins' namedpipe-based channel,
but the default secdesc for np is way too open -- the user unfortunate
enough to be running in session zero will have his namedpipe endpoint
exposed on the wire, and susceptible to DoS (or worse). You'd have to do a
*lot* of grungy p/invoking to construct a well locked-down secdesc...
2) People may vehemently disagree with me on this, but I've come to believe
that the abstraction provided by RPC-style language bindings (ie: making a
remote call look exactly like a local method call) is just too easily
misused. Even the most trivial of remoted calls can fail -- ok, so you take
care to wrap your calls in catch-blocks. What if the call blocks for a
really long time, before failing (or succeeding)? Are we performing any
remoted calls on a UI thread, or some other critical thread that shouldn't
block for an unseemly amount of time?
All the RPC abstraction is doing for us at this point is making it hard to
review our code for the above conditions, because the calls look just like
local calls! .NET makes it so easy to serialze object graphs into/outof a
byte[]... I'd much prefer an explicit model of messaging for IPC, something
like:
byte[] messagePayload = IpcHelper.SerializeArgs(arg1,arg2,arg3);
SharedMemoryEndpoint sme = new
SharedMemoryEndpoint("MyWellKnownSectionName");
sme.SendMessage("MessageName",messagePayload);
or maybe even
byte[] returnData;
sme.TransactInterprocessMessage("AnotherMessageName",messagePayload,
out returnData);
object outArg = IpcHelper.DeserialzeArgs(returnData);
That's explicit -- clear to any reader of the code -- and hey look, it's not
much more typing than Remoting! Oh but oops, I meant to use xml instead of
byte[]... Don's going to be pissed.
-S
-----Original Message-----
From: Kamen Lilov [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 11:04
Subject: Re: How to comunicate from .NET with an older C++ library?
We all know and love Don, but we know how religious he can be sometimes.
Especially when what he tells the audience coincides with the current 'party
line' of Microsoft :)
If you need proof, just remember that giant flop "Build all your multi-tier
web applications with COM+ transactional components." This was the official
Microsoft strategy a couple of years ago. I personally managed to screw
quite a few $$$ by making wrong architectural decisions back then. Looking
back, writing middle-tier COM+ components with VC++/ATL (or even VB) was
wrong every time in terms of performance and maintainability, as compared to
plain old ASP script.
What happened a year after that? Well, even though it was half-mouthed,
every Microsoft and non-Microsoft employed expert who knew their stuff
suggested that you avoid transactional components at all costs for read-only
operations, and use them in read/write scenarios only after giving a long a
hard look at the real needs of your application. (The same applies to
Enterprise Services nowadays, BTW)
XML is great, guys. I really love it. However, before you plunge into the
"XML everywhere" abyss, remember that there are passengers for every train
(as we say here in my home country :) -- binary data representation is here
to stay for quite a few purposes and applications. XML is a panacea when
you need to communicate between different apps. But intra-application
communication, when you control both ends of the channel? Think twice...
</rant>
Just to let everybody know, I am not a Microsoft basher. In fact, until two
years ago, I was an MSDN Regional Director (not a MS employee, but a
honorary unpaid partner position). I love .NET -- it was long overdue, and
put Java back where it belongs -- in the "we won't do it on Microsoft
software, even if it's slower and buggier" camp.
To reiterate, XML is great, but not as great as to make the "there is no
such thing as a silver bullet" axiom untrue.
Maybe Ingo could pitch in here with some strategic thoughts on Remoting. He
is, after all, the foremost (publicly known) non-Microsoft employed expert
on the subject.
-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Philip Nelson
Sent: 17 Ноември 2003 г. 19:09
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] How to comunicate from .NET with an older C++
library?
> I can think of one more approach that will give you better performance
> (although it still won't be nearly as fast as the shared memory
> solution): .NET remoting.
I'm sure others here can elaborate much better than I, but .net remotings
seems to be heavily de-emphsized in Whidbey. Don Box was openly derisive of
remoting and of the idea of strong typing across processes. Indigo will
also have the ability to do a binary format of xml to dramtically reduce the
overhead as I understood the presentation at the PDC. So, depending on your
timing, you may want to consider how Whidbey might influence your decision.
===================================
This list is hosted by DevelopMentorR http://www.develop.com Some .NET
courses you may be interested in:
Guerrilla ASP.NET, 10 Nov 2003 in London and 26 Jan 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnet
Guerrilla .NET, 8 Dec 2003, in Los Angeles
http://www.develop.com/courses/gdotnet
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor- http://www.develop.com Some .NET
courses you may be interested in:
Guerrilla ASP.NET, 10 Nov 2003 in London and 26 Jan 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnet
Guerrilla .NET, 8 Dec 2003, in Los Angeles
http://www.develop.com/courses/gdotnet
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor╝ http://www.develop.com
Some .NET courses you may be interested in:
Guerrilla ASP.NET, 10 Nov 2003 in London and 26 Jan 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnet
Guerrilla .NET, 8 Dec 2003, in Los Angeles
http://www.develop.com/courses/gdotnet
View archives and manage your subscription(s) at http://discuss.develop.com
