|
death of COM/DCOM?
Is COM/DCOM? going to be dead soon as said in this article.
http://news.com.com/2100-1046_3-5148148.html?tag=nefd_top
Spencer
Tuesday, January 27, 2004
.NET has solved so many of the problems with COM/DCOM that I expect it will. Not very soon mind you because so much is invested in it. But I will none the less.
Marc
Tuesday, January 27, 2004
From the article:
"Box stressed that COM and DCOM are not dead. 'Only now are some groups inside and outside Microsoft finally taking advantage of COM,' he said. 'Our commitment to COM is not finished...but our annual $6.8 billion (research and development) spend is not going on Ole32.dll,' Box said, referring to the dynamic linked library COM uses."
Nick
Tuesday, January 27, 2004
What did the article mean that OOP is not good? .NET totally uses OOP especially with VB finally getting all of the benefits! From what I understand OOP & services go hand in hand.
Anyone know what they meant by this?
GenX'er
Tuesday, January 27, 2004
"Microsoft is giving developers a platform on which they don't have to worry about how things connect but can instead concentrate on how they want things to look"
Until longhorn 2010, of course. Then you'll have to rewrite everything again.
Tuesday, January 27, 2004
He isn't referring to OOP; he's talking about COM objects, or basically, DLL's that package COM components.
Walt
Tuesday, January 27, 2004
It meant that OOP sucks for distributed systems.
And it does.
Distributed object systems have been tried many times, many ways, and they've mostly failed because of deployment difficulties, brittleness (change one thing and everything breaks) or poor performance.
It doesn't mean that OOP isn't useful for building the pieces of a distributed system; it absolutely is. But don't try to model the communication between the pieces as method calls on objects, or you'll regret it.
Chris Tavares
Tuesday, January 27, 2004
Hardly.
COM will survive for many more years. Just because MS isn't investing truckloads of money into the tech, doesn't make it dead.
Much of what's in .NET is merely a wrapper around existing COM components. Go write a .NET application that uses WMI and you'll find you're still dealing with the COM libraries. Ditto for stuff like Active Directory and ADSI. .NET just wraps around the COM.
It will be some time before MS has moved things such as these into managed code. And even then, the legacy systems that still use COM will still be out there.
Mark Hoffman
Tuesday, January 27, 2004
Walt, thanks for the info. I guess he worded it kinnda bad with:
"object-oriented programming is just not all it was made out to be"
GenX'er
Tuesday, January 27, 2004
gotcha Chris Tavares thanks again!!!!
GenX'er
Tuesday, January 27, 2004
When people talk about "the death of COM / DCOM", I think they really mean "the death of abstractions that make remote objects look exactly like local ones". Which is what DCOM is, _especially_ to VB programmers.
It all works fine until the remote server goes down, is moved, or you've got security problems, then the abstraction really leaks.
Better Than Being Unemployed...
Tuesday, January 27, 2004
I believe Don Box said Com is finished. Meaning complete. Not deprecated.
Mike
Tuesday, January 27, 2004
Alternate / Related Question:
Will dotNet ever be truly viable as a way to integrate in-process components for a complex desktop app?
I suggest perhaps:
First Microsoft recommended leakily abstracting COM interfaces into DCOM interfaces, and woe befell those who took that advice to heart and tried to gloss over the essential distinction.
Now Microsoft recommends the reverse - leakily abstracting the dotNet distributed architecture for non distributed apps - and again woe will befall those who take this new advice to heart and try to gloss over the essential distinction.
jsaitken
Tuesday, January 27, 2004
BTBU beat me to my point, but my question stands. I don't know enough about how the dotNet compilation and linkage business works to guess whether it will ever allow you to make things work efficiently with dozens or hundreds of put together bits and pieces... but I'm skeptical.
Will we have to use fewer and larger components?
Or else could dotNet really just be viewed as going back to (semi-precompiled) source code libraries?
Anybody got enough experience with dotNet to say?
jsaitken
Tuesday, January 27, 2004
"Will dotNet ever be truly viable as a way to integrate in-process components for a complex desktop app? "
Yes, it's viable NOW to do that.
Let's look at what you need to integrate in-process components:
1) A loader that lets you specify components somehow, and bring them into memory. COM did this via CoCreateInstance and the registry. The CLR (Common Language Runtime, aka .NET) does this via Assembly.Load. Check.
2) A agreed upon calling convention. COM did this with binary layout standards, which worked but were very brittle. The CLR uses metadata instead, and it's much more robust.
3) Some way to exchange interface contracts. COM used type libraries and IDL files, but in the end it all boiled down to the developer compiling a binary and hoping that the component lived up to it's promises. The CLR uses metadata again for this, so at least you'll get a nice error instead of a hard crash if there's a mismatch.
4) Memory management. COM used reference counting. We all know where *that* got us (if not, I can tell you about the month I spent tracking down a reference count bug in IE 6). The CLR uses a garbage collector.
.NET works best when everything is a .NET component, but you've got a fairly large amount of freedom to pull in existing COM components, DLLs, and to call .NET stuff from unmanaged code in a variety of ways.
Working with .NET for these kinds of architectures is really nice, because, for the most part, everything just works. No more tons of glue code to write.
Chris Tavares
Tuesday, January 27, 2004
"COM used reference counting. We all know where *that* got us "
Where did that get us? Well, let's see -- reference counting and programmatic lifetime management are what is the foundation behind the _overwhelming_ _majority_ _of_ _successful_ software. Don't throw the baby out with the bathwater just to try to garner support when a couple of web sites run on .NET, and billions upon billions of lines of code using the "old school" technique run the world.
"The CLR uses a garbage collector."
I fancy myself a fairly smart guy, but I've never read a description of the technical background of garbage collection that doesn't leave me agog at how insanely idiotic the whole process seems (it seems like someone couldn't figure out how to elegantly do dynamic heap management, so instead we get the miracle of garbage collection -- Objects hang around for an undetermined period of time when absolutely unneeded!). It sounds like the most unbelievably ridiculous and, pardon the expression, BULLSHIT technology (the sort that people who constantly use words like "metadata" clutch onto).
Of course now you get a whole slew of new and ridiculous errors -- like forgetting to call Close() on your ADO.NET connection and exhausting your connection pool because garbage collection hasn't bothered destroying the objects (despite going out of scope long ago -- reference counting [programmatic or smart pointers] would never have that problem).
As a bit of an aside, it's fascinating reading as if garbage collection is something new -- I recently bought a bunch of old Compute! magazines circa 1984 and got a little laugh reading a description of BASIC on the Commodore 64, and how garbage collection periodically frees memory by finding unused memory. Everything old is new again.
Anonymizer
Tuesday, January 27, 2004
" (it seems like someone couldn't figure out how to elegantly do dynamic heap management, so instead we get the miracle of garbage collection --"
We all wait with baited breath for you to post your solution to dynamic heap management.
Oh...you don't...have one..do you? Hmmm..Didn't see that one coming.
I Hate Whiners
Tuesday, January 27, 2004
I've wasted far too much of my professional life chasing down refcounting errors to think that it's a "foundation of reliable software."
The problem with reference counting is that it looks easy, but it's actually really hard to get right. And unless everyone involved does everything exactly right, the whole thing falls apart.
To add to the problems, the "deterministic destruction" property of refcounting encourages people to take advantage of it, and then you get all KINDS of errors when you suddenly have a circular reference.
At least with GC you know up front what you're getting into, and even when you forget to call "close" occasionally things will eventually get cleaned up. It's not a permanent leak like a refcounting error gives you.
I never claimed that GC was new; heck, LISP used GC 30 years ago!
As far as the accusations of uglyness are concerned, all I can say is that when the copying GC algorithm was explained to me, I was amazed at how elegant it actually was. I guess it's just a matter of taste.
Chris Tavares
Wednesday, January 28, 2004
I am going to go out on a limb here and say allocating memory in the middle of running an application is a bad idea (garbage collected or not). New and malloc have caused more security and stability problems than any other language constructs. In my opinion an application (especially a server) should allocate all the memory it will ever need at startup.
If you don't do this you have built a time bomb waiting to go off. Almost no application does something sane when new or malloc fail. You will claim you do, but trust me you don't.
This is a controversial position to take, but I stand behind it. This is how I write server apps now, and it works.
Servers such as Apache and IIS have no reason to grow their memory requirements while they are running, and doing so is dangerous.
Everyone is going to call me an extremist here, but in the end I'm certain I will be proved right. If the industry is serious about addressing security and stability, then a new memory scheme will have to be deployed.
christopher baus (www.baus.net)
Wednesday, January 28, 2004
"New and malloc have caused more security and stability problems than any other language constructs"
New and malloc don't kill apps, people do.
sanmou
Wednesday, January 28, 2004
Wow I can't believe I only got one comment on my memory management comment.
christopher baus (www.baus.net)
Wednesday, January 28, 2004
I'll simply add this:
I can agree that if you know up front what your memory requirements are going to be, then you should allocate it up front if you can.
Not all code is server code, and not every app knows up front what it's memory requirements are.
Chris Tavares
Wednesday, January 28, 2004
Just out of curiosity, give me an example of an application that doesn't know what it memory requirements are?
It is true you can get away with a lot more on the client, but on the server, I will argue day and night that all memory should be allocated at startup.
christopher baus (www.baus.net)
Wednesday, January 28, 2004
An example? How about a word processor? A spreadsheet? CorelDraw?
Chris Tavares
Thursday, January 29, 2004
Just about _any_ stand-alone fat client application, really, except maybe for simple command-line programs that run in a stdio pipe. Fat client apps manage their own data (i.e. they don't get it from a remote database), and that data usually grows in response to user input. How are you going to avoid that?
Chris Nahr
Friday, January 30, 2004
Odd to think about that one way of making your code harder to use and understand is now dead, and being replaced by a new way of making your code hard to use and understand.
M<
m b s
Tuesday, March 9, 2004
The fact that there will be no more R & D work related to COM / DCOM proves only that both technologies are mature enough and there is no space for their further improvement. While maturity of a product is very good news for its users, it means decline of profitability of its providers. Microsoft share prise depends on their ability to create inventive and useful things with their $6.8 billion R & D budget, and to find buyers for them.
In some cases, the only way to make others buy a new stuff is to declare existing one obsolete and / or unfashionable. To declare COM / DCOM obsolete is similar to saying that a 20 yo person is too old just because you are not sure about how much profit you can continue squeezing from him.
I suspect there might have been some internal struggle inside Microsoft between COM and .NET supporters. This however does not mean that who controls Microsoft has the power to control the world of software developers.
The 20 yo person has his own independent life and relations with the rest of the world outside his own family and it’s not up to his parents to decide how long he is going to live.
Ivan Klianev, Sydney, Australia
Wednesday, March 10, 2004
"Microsoft is giving developers a platform on which they don't have to worry about how things connect but can instead concentrate on how they want things to look"
Yeah, and you'll HAVE TO spend all that time concentrating on how you want things to look, because the default Windows.Forms controls don't include much of the functionality that we (users AND developers) are used to seeing in 'Rich-client' Windows applications.
Because I don't want to wreck this comment thread with a 4-page list of broken features and all-too-operable 'anti-features', I will only list a few pieces of supporting evidence:
- no 'press escape to return to original value' in text boxes & derived controls.
- no auto-complete in combo box.
- no 'limit to list' in combo box. (sure it has dropdownstyle of dropdownlist to attempt to achieve this functionality - but then, typing results in a 'repeatedly select the next item beginning with the letter whose key I am pressing' style ala web combos, as opposed to classic 'auto-complete'. most users aren't interested in that.)
- labels don't display text properly when set to 'right-align' (this single issue is enough to render the entire Windows.Forms control library a joke!)
i'm close to wrapping up my first .Net project after years spent in access/VB.old land: I'd conservatively estimate that 75% of the time on this project was spent massaging UI elements into behaving the (exact) same way (or better than) their thoroughbred* counterparts do! (*i.e. - the ones we see in the applications that MS writes & releases! I don't know if these are from MFC or if they are 'proprietary' for MS-internal use only. either way, it's bunk that .Net offers only a crippled, reduced set.)
in reference to the topic, tho: the data-access aspects of the framework are great. i look forward to leveraging their power even further on my next project. (it's the UI aspects i'm dreading....)
From MS-Access land
Friday, March 26, 2004
 Recent Topics
Fog Creek Home
| 
