Sun waits out Microsoft

TalkBack 1 of 5:: Next »

Thread View
Flat View

Binary Compatibility? To even suggest it is folly: "I pushed the envelope, just for giggles, calling for binary
compatibility between Java and .NET/DCOM/COM"

This isn't useful and the mere suggestion brings back
memories of the Object Request Broker (ORB) wars of years
ago (CORBA R.I.P) and it doesn't solve anything that can't
be solved with a simple level of indirection such as XML-
RPCs. Worried about performance? That's too bad, deal
with it, most of the world has. (Financial apps are an
exception, but then those iceholes usually have the money
to pay for development skills that have become very niche)

.NET is an over used marketing term which means
different things to different people. But for the sake of
argument let's take the vantage point of developers. So
we'll assume C# and/or whatever revision Visual Basic
happens to be at... does anyone really care about VB
anymore? Honestly I don't know since I stopped caring
about that space long ago.

Anyway, the C#/.NET camp is likely to be using SOAP (aka
XML RPCs) and this is a different animal altogether than
what DCOM was and/or wanted to be.

All the old die hard (D)COM afficionados such as Don Box
have moved on, for good reason, there's not much value
added at this point. That hasn't been the case for years.

DCOM and COM are really just Remote Procedure Calls
(RPCs) under the hood. Their "wire format" (the bits
transmitted via TCP/IP) were largely an implementation of
the Distributed Computing Environment (DCE) RPC
specification that Digital Equipment Corporation (DEC)
spearheaded long ago.

DCOM allows you to instantiate "objects" (snippets of code)
across machine boundaries. Big deal. It might be novel
when you first do this on a network but the reality is,
management of such software architectures is tedious. Not
to mention this vision assumes you plan on deploying
snippets of code (COM servers) all over your network.

I have news for you, such an exercise is an IT manager's
nightmare. There's a reason web services and thin clients
are in and the last vestige of "client/server" (the usage of
ORBs), i.e. architectures based on RPCs, are out. It's called
cost. Both from an implementation and subsequent
management perspective a DCOM infrastructure is
expensive to manage. Not to mention that most people
who wrote a COM server just plain didn't know what they
were doing.

Having once read every word Don Box used to write like a
preacher talking to the converted I discovered long ago the
real world is a very different place.

If anything, the greatest thing COM begat was the OLE
interfaces (the ignorant often using "COM" and "OLE"
interchangeably). These baseline interfaces ("API protocol"
for those unenlightened but hell that's still a disservice)
along with requisite object instantiation via the OS
(CoCreateInstance) created an environment where it is easy
to leverage other people's code, e.g., "Spreadsheet in a
document" or "Use IE to render pages inside your own
application." Since the COM DLLs on Windows (and
because EVERY copy of Windows has them) are not tied to
one language it didn't matter if someone wrote their COM
server in Borland's Delphi or Python.

This "rich" leveraging is something you don't necessarily
see on other platforms, at least not in a trivial manner. Sun
might have specified interfaces such that one applet can
embed another applet (or whatever the vernacular is) but
that doesn't do me any good if for some useless reason I'm
writing a thick C++ application on LINUX. I say useless
because at this point, there's very little reason to build
"thick interfaces", it's all about "web interfaces" nowadays.
There are vertical markets that still require them, but
there's a reason they're called "vertical" - niche.

I know the focus of the story wasn't "binary compatibility
between Java and .NET/DCOM/COM" but to even suggest it
in this day and age considering what's gone on the past is
a bit foolish.

I have news for you, many company's and department's
notion of "interoperability" happens to be the use of FTP
(and increasingly SFTP) to post files to each other. Yes the
antediluvian File Transfer Protocol concocted in the 80's. Sad but true. DCOM, CORBA, ORBs... those were all wet
dreams if you see how B2B actually happens nowadays.; Posted by: betelgeuse68 Posted on: 03/10/08 You are currently: a Guest | Members login | Terms of Use