> Comments on this Article
>
> 1. Please refrain from turning technical articles into a
> platform for passive-aggresive non-MS technology bashing.
> Implying that CORBA/IIOP is an inherently flawed
> technology because low skilled "system architects" and
> "designers" didn't know how to use it correctly is just
> plain foolish. In any case, where does MS's previous
> contribution to this space (DCOM, COM+ etc) factor into
> this ? Perhaps MS should critique its own technologies
> rather than taking the opportunity to try and discredit
> its competitors.
>
I must say, I sense a lot more MS-bashing in your comment than there ever was non-MS bashing in the interview. Anders was talking about an idea more than a specific technology in the section about remote objects. The example he gave was CORBA, but it was clear to me as I sat there that he was talking about all remote object architectures. He also didn't bash them in all situations. He said that up to a local area network they work well, they just don't scale to the internet. He may have had a secret plan to bash CORBA, but I saw it as an appropriate example given that CORBA was the big dream for inter-language inter-operability. Now web services seems to be that big dream.

> 3. Can someone please explain what the whole conversation
> under the "The Stateless Fashion" was about?. Bill
> Venners asks the (quite reasonable) question "What is
> the advantage of not having state in the distribution
> mechanism?". Anders answer is a simplified description
> of what a web service is (maybe he misunderstood the
> question). He then goes on to tell us that that we should
> be thankful that they don't provide us with any session
> mechanism so we can reinvent it every time for ourselves.
>
Well, I was trying to figure out what Anders meant by stateless in the O'Reilly interview. What I finally figured out was that he meant there is no state in the transport protocol. I.e., HTTP is a stateless protocol. Something like CORBA (or DCOM, or RMI) has state built-in, because it says that as long as you hold onto this reference to the local proxy, the remote object will be kept alive across the network. I kept asking him to clarify because it took me a while to understand the distinction he was trying to make. My current understanding, at least, is that most of these web services interactions will likely have state on the server, so they aren't stateless in that sense. But because the protocol doesn't mandate a certain kind of state model, developers who build these web services have more choices in how that state is implemented. So I believe what Anders was trying to say with the "loosely coupled, stateless fashion" comment in his O'Reilly interview was that by allowing developers to "reinvent a session mechanism each time," as you might put it, developers have the flexibility to do what is required to make the session mechanism scale to internet sizes.

> 4. With regards to "Object-Relational Mappings",
> when asked "What are the main issues with O/R
> mappings?" we are told that caching is critical and
> most O/R mapping technologies (other than .NET of course
> in which they "tried hard to make sure the caching
> policy can be entirely under your control") have
> inflexible policies. Well, um, err I'm not sure what
> non-.NET O/R tools Anders has looked at but based on the
> answer to the question it would seem to have been a
> somewhat cursory investigation. Oh wait - I get it -
> you're trying to have a go at Entity Beans without
> actually saying the J word - gotcha.
>
Is that what he meant? He may have, I don't know.

Everyone I interview has some kind of agenda to push somehow, and to a greater or lesser extent they always do. For some interviewees it is as simple as mentioning a book that happened to have recently written. For others, is pointing out how much better their language is than the competition's. I am also keenly aware that high-visibility people who work for large corporations, such as James Gosling and Anders Hejlsberg, can't always say exactly what they think, because they are seen as corporate spokesperson by the outside world. Therefore, they have to try and not embarrass their employer, because it could potentially hurt its stock price or at least cause a few sales to be lost to the competition.

I attempt to do a couple things to deal with agendas in editing these interviews. I try to cut out most blatant plugs and competition bashing, but I leave in respectful comparisons, especially if they are trying to make a general point with the specific comparison. Also, I make it clear who everyone works for. Every reader needs to take into account on whose team the interviewee plays as they read the interview.

> All things considered, a drastically oversimplified
> marketing-oriented "look at what MS has invented now"
> article. Very disapointing.

I wonder to what extent your reaction comes from the actual content of the article versus the anti-MS glasses through which you seem to be reading the article. Personally, I am also quite concerned and frustrated by MS's business practices, but not to the extent that I refuse to listen to anyone who works at MS. Anders is a smart guy who has done some amazing things in his career. I gained several new insights through the process of interviewing him, and I have been trying to pass those along along to readers through the articles.

My intent in this article was to publish the idea that even though as designers we try to raise the level of abstraction as high as possible, sometimes we can go too high. I found it quite interesting that Anders mentioned the problems with attempting to hide the network. That is the exact point made by Jim Waldo, et. al., in The Note on Distributed Computing and one of the central ideas that influenced the design of Jini. In other words, allowing an object to be implemented locally or remotely as an implemention decision on the part of the local object is an inappropriate abstraction, because the nature of local and remote computing is just too different to fit well in the same abstraction. I think that is a general design insight that goes beyond remote object artchitectures and O/R mappings: we should try to raise the level of abstraction up as high as possible, but no higher.

Martin Fowler also discusses the issue of having to design differently for distributed versus local in Patterns of Enterprise Application Architecture.