Microsoft - Longhorn 2

[CajunCenturion]

This news article is chock full of statements from a Microsoft software architect, any of which might worth of its own thread.

http://news.com.com/2100-1046-5148148.html?tag=cd_top

Note the comments about the future of .Net, OOP in general, the future and use COM, DCOM, among others.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[wmichael]

Interesting to note that Microsoft was founded by the same man who was once quoted as saying "We will _never_ use 1 megabyte of storage."


~wmichael

"small change can often be found under seat cushions"

 

[dilettante]

Well irrelevant comments from the Peanut Gallery aside, I have to agree with you CajunCenturian.

I do wonder how many of the "quotes" are real quotes at all though, and I am very suspicious of the attributions that don't even appear between quotation marks.

But my own impression of Don Box is that he only really lke Don Box's ideas anyway. That said, I really doubt he's going around saying "OOP is dead" and even if he says so I don't think he really believes it will or even should.

If there is any meat here between the lines of this obvious provocateur of an article, it's in the area of object coupling strategies. I expect DCOM's role to be diminished and replaced by something on the order of web services, but COM itself has a lot of mileage left in it. The slow adoption of XP Pro on corporate desktops means it'll be a long time before we see Longhorn everywhere - and while all those pre-Longhorn machines are out there we'll have lots of COM and DCOM loose in the world.

This where the remarks about RMI and CORBA come in. The article is really talking about comments regarding remote-object coupling technologies. The weaknesses in both DCOM and RMI tend to be both their proprietary natures and their tendency to be synchronous couplings. Developers seem to have sat on their hands for the most part about moving to MSMQ and MQSeries, which solve the synchronicity problem anyway. I suspect we'll end up with "web service" flavored versions of both MSMQ and MQSeries, possibly even veiled under new names. The big flaw with naked web services is that they don't guarantee delivery or work in a transient network environment, and most of our applications couldn't live on a pager network either for the same reason. But people even run web services over email in attempts to solve that issue.

The king of message-based platforms in the i86/i386 world of course was CTOS, from Convergent Technologies (later Unisys). But during CTOS' heyday everybody was still thrashing around trying to make clunky 2-tiered C/S applications based on crap from Microsoft, Oracle, Sybase, Informix, etc. Much of this may have stemmed from Microsoft's ODBC creature, which made some great things possible but was stunted at birth. The market didn't appreciate what CTOS offered, the market spoke, and so now we have to live through the market's slow maturation and endure rediscovery and reinvention of things many of us already knew well from the 70s and 80s.

Many of us went through this in the 60s and early 70s on mainframes, where crappy ad hoc approaches to building distributed applications were gradually replaced by things like IBM's CICS, Burroughs' (later Unisys') GEMCOS, and AT&T's Tuxedo (on UNIX minis during the 80s).

But I haven't seen where any of this addresses COM's role in Microsoft OSs. DCOM, yes. COM, no. If Box is claiming this (and he could be right) I blame it on the C++ programmers' bias against COM. It's been a fantastic enabler for other developers on MS platforms, but it can be a pain in C++. But that's just me. I blame the same community for most of what I think is poorly done or just wrong about .Net in general.

It's a pain, but life can be a painful process.


Ok, let the flames begin! ;-)

 

[sfi]

Ahhh - CTOS, what a great little OS.

 

[wmichael]

It is refreshing to be relegated to a member of the Peanut Gallery. Your comment may have actually been productive, though it may not be due to your no doubt honorable intentions.

Allow me a few responses to your well-written and knowledgeable repartee'.

My initial comment about Gates was designed to bring to light the fact that very few people, even those who have been so very obviously successful and instrumental in shaping how we compute today, can accurately predict the next five years.

Perhaps irrelevant, but a nice lead in to the following.

dilettante so poignantly pointed out that the article is regarding the diminishing role of object coupling strategies, only to be replaced by message-based services. While I was open-minded in my reading of this (and it was clear enough to not have to read between the lines), I became a bit horrified in the last two paragraphs.

Statements such as "a platform on which they [developers] don't have to worry about how things connect but can instead concentrate on how they want things to look." and "It's all about the power to not have to worry about the plumbing..." make me shudder.

Whose job is it, then to 'worry about the plumbing'?

Much like the recent paradigm shift that WYSIWYG editors have done to the web, where anyone who can use Word can make a web page, is Microsoft now proposing an area where technical acumen will be replaced by, say, a good sense of style? Will developers instead start out a little higher on the run and only concentrate on how

Microsoft's propensity for making coding more productive has been a double-edged sword. Each time a wizzy feature is designed that enables the developer to further abstract himself from the code, that developer is losing an essential part of the knowledge required to do his job effectively.

I guess the essential job responsibilities of a ‘developer’ will have to be looked at as well.

While I do not entirely disagree with the idea of moving forward with a paradigm that may be better than the OO models adopted by so many, I strongly object to abstracting the 'plumbing' from the actual development.

Will I interview someone in 5 years who cannot open VI and write code? Will someone come to me for a job as a web developer who cannot write well-formed HTML or XML in notepad or some other text editor?

If so, I think the industry as a whole will take a hard hit in one respect. Developers will be launched forward as architects without really *knowing* what goes into building a system.

On the other hand, folks who can code on what will be legacy systems will be in great demand, perhaps much like the Cobol craze for Y2k preparations.

In deference to those bred in the 60's-70's, I would encourage taking a look at another trend that may have been addressed in the final two paragraphs of the article.

Web usability, client-server usability and those dreaded green screens have certainly bubbled over to a point where this must be addressed wholesale. Folks like Jakob Nielson and Jared Spool have been pioneering this idea for years, pointing out that software usability, including development software, is an important part of the productivity, communication and effectiveness of every piece of software and hardware being produced.

Could the next 5 years instead be focused on the above issue? Perhaps it is an errant technical step, or may be slow to be adopted, but the idea of focusing on the usability aspects of software, how things look, may be the right one.

Please don’t bother telling me that ‘how things look’ is likely a reference to architectural aspects of software development. While I realize that may be the case, the point remains that enabling individuals to spend more time on design, and freeing folks up from the time-intensive tasks of solving technical issues may eventually lead to a more refined culture that is concerned with all levels of design and presentation.


~wmichael

"small change can often be found under seat cushions"

 

[lionelhill]

wmichael,

(1) I have to say you're making interesting points.
I wonder whether a lot depends on the sort of program you're talking about. Most of the things I'm interested in are simple stand-alone applications that don't need to be intimate with eachother or at arms length. They live alone.

(2) About plumbing: you are so right! The attitudes of different people are so different. The user doesn't care tuppence what's going on underneath the surface, provided the surface looks OK, behaves logically, and produces the right results reasonably quickly. The developer cares about how quickly he can write the thing, not how quickly it works, and cares about code maintenance, which is of no interest to the user. Naturally the bad developer doesn't want to know anything or do any work; plumbing-free programming is ideal.

(3) As a user, I wish more developers would take the trouble to see beyond the architecture and look at how it influences what I get rather than how they make it. If OOP gives me a good product, and helps code maintenance into the bargain, fine, but don't put code maintenance in front of adequate performance of my task! Architecture is a means to an end.

(4) The more you understand the way the means works, the more chance there is of you getting the right end (how many postings here ask things like "I need to define a 4 dimensional array with 1000 elements in each dimension but I keep getting errors"?, let alone the "how do I convert an exe file back into code" question). As a programmer I get frustrated with the increasing number of cut-and-paste merchants who feel that it's unfair to expect them to know anything except how to use Google; and who firmly believe that writing html in a dedicated web-design package makes them a programming "guru".
Let's have more genuine plumbers!
Rant over! Thanks for listening!

summary: by all means debate the plumbing that Msoft give us, but keep it in proportion by thinking about what the end users want too.

 

[chiph]

One of the hallmarks of a good developer is their level of understanding of all the layers their code is built on. So any developer who says "I don't care how it works, as long as I can call the API" is setting themselves up to be burned because they don't understand what's underneath.

Regarding object-connection technologies (COM/CORBA/WebServices, etc) vs. message-based systems (MSMQ, MQ Series, etc) -- that is a design decision based on the needs of the application. If you need a synchronous process, you use a RMI-like process, one in which you make a call, and wait for an immediate response. If you need an asynchronous process, you use a messaging-based system, because then you can drop your message off and check back for a response, or be notified of a response at some undetermined future time.

So, saying one is better than the other is hogwash, because the choice of one over the other depends on the intended use. If you're taking web orders for cat food to be FedExed to someone, an async process is what you want because you just give them an order confirmation number and they continue on their way. If you're transferring money from one bank account to another, you want an instant success/fail notification, so a synchronous process is best.

One other thing to remember -- Microsoft is in the business of selling shiny new toys. They only get money by selling you something new. You, as a developer, need to keep an open mind about whether or not what they're selling will fit into your business model.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[dilettante]

I wouldn't say one is better than the other chiph, I think the real issue is that async, queued, reliable delivery, message-based communications can substitute for simpler synchronous systems - while the converse isn't true. Such subsystems can be built as "swiss army knife" technologies if you accept several tradeoffs in order to get a "one technology for everything" glue to fit between distributed objects or "actors."

But there are some very real trade-offs involved, which is part of why "best" is pretty meaningless. The corkscrew blade of a very generic tool might be a bad choice if your business involves opening lots of wine bottles.

But I think what Don Box has been advocating is something somewhere in between. Something that might be a good ("good enough?&quot replacement for distributed RPC but that has the potential heterogeneity of web services, possibly by adding features overlaid on the basic web service concept.

I can only think that the comments he is quoted as making about distributed object technologies refers to the tight coupling that object RPC-style linkages require. That's the "unwanted intimacy" he talks about. Basically you end up serializing a lot of information in internal formats and then marshalling it over the wire to the other side and back. The point is to try to make the remote object "appear local" from the programmer's point of view. I think he's suggesting that programmers view communicating entities as communicating instead of relying on an abstraction designed to hide the communication.

One reason why financial transactions noramlly do not use simple RPC-style synchronous operations is that the typical technologies employed don't offer any auditing mechanism independent from application code. Most message-queuing middleware does offer this, and transaction queues can be rolled back in sync with the databases and "replayed" for recovery purposes. Synchronous 2-phase commit leaves you high and dry when you find a bug in a bit of updater logic someplace in your distributed application after 50,000 updates have passed through. Rollback recovery is always a nasty topic.

But I have no interest in defending any of it. Aren't we trying to interpret the article first?

I agree with points made so far hinting at the cost and disruption of technology churn. I'm at a point now myself where I'd love the time to get some more mileage out of things-as-they-are.

As for plumbers and plumbing... well I think there have always been very few plumbers while a whole host of people ran amok with monkey wrenches. Trying to make the plumbing invisible or automatic somehow is just another attempt to make toolsets and those who wield them more "productive." That only makes good sense, since the 80-20 rule still applies: most "programming" doesn't require a deep skillset as long as the right constraints are in place so the programmers can't cut their own (or their users') thumbs off. At the same time the other end of that formulation says that some smaller fraction of programming tasks will probably require very deep skillsets. Allocations of tasks among resources is what management is all about.

The very idea of XML turns me off. Talk about bulk and inefficiency! But swapping data around in proprietary binary formats has serious limitations that nobody else has addressed successfully - certainly not in terms of market penetration. EDI messages probably come closest and the success of EDI has been limited outside of the niches where it has been strongly embraced. As the name says, it's a document replacement technology and not an RPC substitute. That's where SOAP came in, to add verbs to XML's nouns and adjectives.

 

[jsteph]

What's ironic is, in an article where MS is playing down COM, if you click on the link in the first paragraph to COM, the headline is "Microsoft Plays up COM"
--jsteph

 

[jsteph]

...and yes I'm aware it's an old article but I just thought it was funny...

 

[chiph]

One reason why financial transactions noramlly do not use simple RPC-style synchronous operations is that the typical technologies employed don't offer any auditing mechanism independent from application code. Most message-queuing middleware does offer this, and transaction queues can be rolled back in sync with the databases and "replayed" for recovery purposes. Synchronous 2-phase commit leaves you high and dry when you find a bug in a bit of updater logic someplace in your distributed application after 50,000 updates have passed through. Rollback recovery is always a nasty topic.

I knew my banking analogy was going to get me in trouble!

Banking has always been a batch-oriented process for three reasons -- the rollback & replay-ability of batch files, the ability to save the days transactions as it's own entity, and (most importantly) the requirement of the Federal Reserve to send files to it several times a day via FedWire for inter-bank transfers.

But it still holds up (sortof) because from the consumer's point of view, it *is* synchronous (only because the funds they moved are considered temporary until the nightly batch run).

since the 80-20 rule still applies: most "programming" doesn't require a deep skillset as long as the right constraints are in place so the programmers can't cut their own (or their users') thumbs off.

I recently read the intoduction to Indigo (MS's new unified communications architecture) in MSDN magazine (I think the article was written by Don), and I'm still not sure what it buys you. It just seemed like more of a marketing bundle than any new technology or a wrapper over the existing communications facilities. If it had provided a new API that made it easier for the 80-percenters to use, that would be one thing. But I didn't see it. Maybe in a future release as Longhorn gets closer.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[dilettante]

Sorry chiph I knew exactly where you were going too. You don't need batch to make it work though, just a transaction monitor that supports journaling. But I agree with your assessment of Indigo. Not being in on the betas (like I have the time anyway) I haven't had much to go on except the bits leaked at MSDN.

As far as Longhorn goes in general, I've looked at Avalon more than Aero, Indigo, or WinFS anyway. But things said about Indigo as recent as October or so tend to be along the lines of:

Q. Does service-oriented development conflict with object-oriented development?

A. No. Service-oriented development complements OO development. OO continues to fulfill an important role in the internal design of services. Service-orientation deals with how to interconnect services to build connected systems. To use an architecture analogy, OO addresses the architecture within a single building (a “service”,) while service-orientation addresses the issues around city planning (a “system”.)

So after all of my own blathering here I guess my opinion regarding the article is:

I don't think Indigo == no more OO. Just no more OO between nodes in a distributed application. So maybe the article was really on-target after all?

That takes me back to my ealiest babbling here on the topic. The COM-style stuff will stay and the DCOM-style stuff will go - eventually COM will be supplanted by something very COM-like while DCOM will be excised and replaced with a message-based model of cross-network IPC. Eventually.

But I hope COM's successor is friendlier than what preceded it: ugly C-style APIs backed up by tons of header-file source definitions. Just look at the crud required in a VB6 Declare Function for a taste of those Gilligan's Island DLL calls - "primitive as can be."

I'm not sure everyone's motivated to read it, but here's something recent from the horse's mouth:

http://msdn.microsoft.com/longhorn/...ull=/msdnmag/issues/04/01/Indigo/default.aspx

 

[chiph]

So "Service-oriented development" is marketing-speak for technologies that include web services and RMI calls.

I, for one, won't be upset to see DCOM go away. I'm also a bit of a Luddite, in that I wouldn't be sad to see COM itself go away. I never liked it, as it was never reliable enough for me. When you have a website with 4-5 million hits a day, and probably 500-times that number of COM calls being made, any level of failure will make itself apparent pretty quickly (and we see occasional unexplained "flakeys&quot.

I'm still hearing good things about .NET. SourceGear wrote their new product "Vault" (a SQL-Server based replacement for VSS) in C#, and has run nightly stress tests on it for months with no failures. Their product uses a set of web services on the back end, which are called by both a GUI front-end and a Visual Studio add-in.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[dilettante]

I haven't seen any reliability problems I could blame on COM though. I worry more about poorly designed web applications that don't scale because of silly things like caching data (and worse yet, COM objects) in the ASP Session object or clumsily defeating database connection pooling.

But "Service-oriented development" precludes things like RMI and DCOM. RMS maybe, but not RMI. That's where "service" comes in... in the sense of something akin to a web server or an FTP server instead of something like a DCOM server. The distiction is the loose coupling. The poor choice of words to describe DCOM remote objects is coming back to bite them in the butt now.

Here's yet another article that talks about MS's direction if not how the actual plumbing works:

http://msdn.microsoft.com/msdnmag/issues/02/02/Basics/default.aspx

And another view of .Net's move to services and how the J2EE world may (or may not) respond:

http://www.chappellassoc.com/HTML_email/Opinari_No8_11_03.html

He has an interesting explanation of why the Java community has failed to innovate: too many cooks.

 

[dilettante]

There is an interesting discussion about a 3rd party product to support service oriented architectures in both .Net and J2EE here too:

http://www.theserverside.com/news/thread.jsp?thread_id=18767

Scroll down for the discussion itself. And be sure to take your "acronym insulin" shot first. ;-)

 

[chiph]

I worry more about poorly designed web applications that don't scale because of silly things like caching data (and worse yet, COM objects) in the ASP Session object or clumsily defeating database connection pooling.

We don't do any of that. In our case it's just that the objects are getting hammered all the time that any small percentage of failure makes itself known with a support call from a customer.


He has an interesting explanation of why the Java community has failed to innovate: too many cooks.

I can agree with that.

In Java's case, because Sun is no longer 100% in charge of it's destiny, they don't have the ability to change direction quickly. I would guess that IBM has at least as much influence on Java as Sun does.

One thing that is very much in .NET's favor is it's purity of vision. Everything pretty much works the same way in the framework. I like that a lot.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[Dimandja]

Everything pretty much works the same way in the [.NET]framework

I like that too. My only concern is that Microsoft may leave it out to dry like it has famously done to other potentially good products.

Dimandja

 

[TroyMcClure]

Excuse me for jumping in here. I don't have a deep technical knowledge of Indigo nor of COM or DCOM, just a general idea of their place in application development. My comments are more abstract, questioning of the veracity of this new (Indigo) direction at a level above the technical nuts & bolts.

Doesn't this sound too familiar? And I don't mean to bash, but I distinctly remember hearing MS say that COM/DCOM was the way to go (and this is borne out following the link noted by jsteph above).

At that time, I recall from the newsgroups, including tek-tips, that developers were spending countless weeks and months and years, and got headache over headache--just trying to get this stuff (com & dcom) to work.

And all the while there were always a few uppity elitist coders who condescendingly said that yes, com & dcom are the way to go, and you greenhorned rookies had better learn it or be left behind.

And now MS says "Oops! Do over!!" and they to say those developers who blindly believed in them: "Never mind. Scrap all that effort in education and practice and missed deadlines, etc. etc. But believe us this time--we're pretty sure we've got it right now". What happens when, in 2007 after numerous upgrades, patches, etc. to Indigo, and all the headaches that go along with it--after coders finally feel they understand this beast--that MS again says "OOPS!! This whole 'messaging' thing isn't the best way to handle communication between programs. We've got a new paragigm, which we're rolling out over the next 4 years."

Because what's really changed from the 90's to now as far as applications? We had the internet then, we had distributed apps then, nothing fundamental has changed as far as enterprise architecture goes. Maybe from a numbers standpoint more businesses use distributed apps but my point is that the idea of using the internet as part of your enterprise is not new and neither are web services.


So my question is, how sure are you that this is really the 'best way' to go, and were you all sure back in the '90 that COM & DCOM were the way to go then? And how much of your opinion of Indigo is based on the fact that--regardless of how well-thought-out (or not) the Indigo/Longhorn platform is--that simply because it's MS and it will be on the majority of desktops that we pretty much have to go with it.

I sometimes get the feeling that if MS said that Objects and Applications should talk to each other via a soup can and a string, that there'd be countless forums devoted to that technology, and so-called gurus would be sitting back speaking with steepled fingers about how the basic Tomato Soup can is better than Chicken Noodle for this reason or that.
--Troy

 

[chiph]

Well, I don't consider myself an "elite" programmer, but even I was able to see that DCOM was a non-starter because it didn't use TCP/IP -- it used NetBIOS, and that didn't route over the Internet (or if you did manage to do it via a tunnel of some kind, it did it poorly). DCOM also had no tolerance for network failure. Unless you had a perfect connection, it got confused. And let's not even talk about the effort to get a DCOM connection working through a firewall!

Having new technologies come out every few years doesn't really bother me -- The technologies are built to solve problems, and if the types of problems change, then the technologies have to change too. For example, the firewall problem in DCOM (and CORBA and other similar RMI technologies) gave rise to SOAP. Now, from a purists standpoint, SOAP is bad because it piggybacks on top of a port that is already being used for another application (

http://WWW).

In theory, it should have it's own IANA-assigned port number. But given the real world, and the fact that network admins only open the bare minimum number of ports, SOAP is a reasonable answer to the problem of getting remote systems to talk to each other.

In Indigo's case, I don't see it solving any new problems. From what I've read so far, it's a solution to a problem that their marketing department has: lack of new buzzwords. It's not a solution to a problem that end-user developers have. They could accomplish the same thing by having the MSDN folks clean up the documentation for the various communications technologies and have it all look/act consistently.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[TroyMcClure]

<<Having new technologies come out every few years doesn't really bother me... if the types of problems change>>

Yes, and part of my point--what bothers me is when a new technology comes out every few years (by the same vendor) that promises to solve the same problem that the last magic bullet had promised. And that's what I see here--the problem was making different parts of an application work with each other. Less than5 years ago COM was it. Now it's messaging via Indigo, and COM is to be abandoned.

I'm all for whatever works, but the problem didn't change, and the technology isn't really new either--messaging was an option when they went down the COM path--it's just that MS made a choice years ago as to the 'solution', and now is abandoning that and making another choice.
--Troy