MS to Objects: "Drop Dead"
Microsoft wants to move beyond objects:
Box said technologies such as Java's Remote Method Invocation (RMI) and CORBA (Common Object Request Broker Architecture) all suffered similar problems. "The metaphor of objects as a primary distribution media is flawed. CORBA started out with wonderful intentions, but by the time they were done, they fell into the same object pit as COM."
The problem with most distributed object technologies, Box said, is that programs require particular class files or .jar files (referring to Java), or .dll files (Microsoft's own dynamic linked libraries). "We didn't have (a) true arms-length relationship between programs," Box said. "We were putting on an appearance that we did, but the programs had far more intimacy with each other than anyone felt comfortable with."
"How do we discourage unwanted intimacy?" he asked. "The metaphor we're going to use for integrating programs (on Indigo) is service orientation. I can only interact by sending and receiving messages. Message-based (communications) gives more flexibility
I guess Don didn't get the memo - OO is all about the messages between the objects, and less about the actual objects themselves. Look at that last sentence - "Message based communications" gives more flexibility? What does he think a OO is about? You know, CORBA can be simple - in VisualWorks, it's amazingly, astoundingly simple. It takes a curly brace language like Java or C# to make it complex (at the developer level - I'm not talking implementation layer here).
What I really love is how people like Don seem to think XML is magic. Send a document, problem solved. Well guess what? You send a document, it gets parsed - and stuff happens. Whether you call it sending a message or not, passing a document is not discernibly different from making a remote API call with a document as the argument. So what if I use http as the transport? It's somehow magical now that I'm using a text based protocol? If this is what passes for "expert" in this industry, then we all have a problem. MS' direction - if Box is being accurately quoted - is along these lines:
"blah blah blah and then a miracle occurs blah blah"
The miracle is transmitting an xml document, apparently. Bah. Box needs to go read some of the things Alan Kay wrote as long as 20 years ago. He's decided to rename all the operations, and thinks that somehow that will create magic. Bah.
Comments
Untitled
[Hmmm...] January 28, 2004 14:33:21.000
But just think what astounding amounts of money will increase Microsoft's profit (which has been lagging) if all of a sudden everything needs to be renamed, things don't work, and then you need consultants! Think of all of us who don't have a job unable to wait for the next Big Rename to occur! ... Or is it that our jobs are mostly meaningless due to the sick desire for growth? All things end, you know, so instead of growing something out of proportion, START SOMETHING DIFFERENT.
Re: MS to Objects: "Drop Dead"
[Vassili Bykov] January 28, 2004 15:42:31.000
Comment on MS to Objects: "Drop Dead" by Vassili Bykov
Maybe the real title should be 25 Years After Smalltalk-80, Microsoft Gets Half a Clue about Objects.
Re: MS to Objects: "Drop Dead"
[Michael Lucas-Smith] January 28, 2004 16:56:08.000
Comment on MS to Objects: "Drop Dead" by Michael Lucas-Smith
The only advantage I can see is that you didn't have to pre-define all the structures used in the messaging system. That's an advantage - actually it's de-coupling, which is always a good thing. But really, why do people keep writing articles as if XML is /the/ magic bullet. What's really interesting with XML is the rich data structures being described by 'experts' (quoted because this is a potluck thing :)) that people are agreeing to use as a standard.
MS to Objects: "Drop Dead"
[Darius] January 29, 2004 14:26:18.000
It's all about psychology, NOT technology.
If a computer language is a language - a semantic, syntactic, and symbolic means of communication, the real answer to what succeeds is whatever is easiest & quickest for the developer to understand - as communicated by another developer or development environment publisher.
XML documents have half a chance for the developer to understand it w/o going back to search an object library or schema. OOP messages tend to carry only enough of the meaning that was in the original programmer's mind. OOP message names tend not to really be designed for a larger audience. The document itself is a capsule of what can be understood w/o an infinite landscape of links to follow. The document has an implied rollback, like journaling.
However, documents have implied audiences and unexpressed dates of expiration when the data is no longer meaningful, accurate, or consistent with other data stores or other schemas. These are rarely communicated with the document.
Documents consume extra bandwidth (since you throw away whole documents and consume just parts, like SQL).
OOP is response/up-time sensitive. A delay in one message delays the whole message conversation. Remote message communication is simply a different animal from in memory message communication. OOP is designed for in memory. The OOP code base is a bit less flexible as it scales because of the communication between developers bottleneck. Not the communication between machines.
Documents and web services also lose at this level since UDDI wasn't a hit either.
What role do standards and schemas play? What role do dictionaries play in current speech? Dictionaries tend to be rules of thumb rather than a authoritative controls. Vocabularies really grow by use and by whom it is that you speak to. It's the connotations and shared but not globally shared prior experience in speech that makes translation of ideas across cultures (platforms) difficult. You just need to also transmit the extra knowledge that a beginner or child would need.
My take. We should be sending code back and forth (rather than messages) with the data attached and the meaning, intent, and purpose attached (to answer the question - Why this data and why this code? ?) in a format as easy to understand as possible for everyone, beginner on up. It's the distribution of interpreters & their updates that's the real hang up, even for Java, XML, & schemas.
Since people make decisions on which technology to use, not computers, it's what is "easiest & quickest for the developers to convey to each other" that makes the difference.
Binary v. text doesn't change predefinition
[petrilli] February 1, 2004 0:07:17.096
I don't know where people get the idea that if you send something as XML it is any less important to "predefine" the format. XML is computer-readable, but then so are ones and zeros, which is what computers really read. Just because it might make some sense to a human, though looking at some XML definitions makes my head hurt unebelievably, doesn't mean that the symantics are any easier to resolve. Working in the EDI world, the real difficult was always agreeing what "foo" means, not how "foo" is spelled. It doesn't matter whether "foo" is the text string of the characters 'f', 'o' and 'o', or if it's the numer 42, as that part is easy. What's hard is agreeing that when the tag "foo" is present in a specific field, it means that money should be debited from the account. There's no difference. XML doesn't make this easier. Having said all that, what XML does make a bit easier is reverse engineering to some extent. It's at least a bit easier for someone to look at and figure out what MIGHT be intended. Then again, look at the Microsoft Word XML format, and see if you can reverse engineer it.