The Realist and the Idealist

I recently had the opportunity to engage in a technical discussion with Chris Sells. We found ourselves agreeing to disagree. He took on the role of the realist, I took on the role of the idealist.

First, Chris and I seemed to be in agreement that distributed computing was easy to screw up. As he stated, it was necessary for consultants to travel the world preaching about *round-trips* (overly verbose message exchanges).

The Realist
Now, I hope I don't screw this up (Chris, correct me if I do).
Chris is of the opinion that we shouldn't paper-over the complexities of distributed computing. By extending the object paradigm into a distributed object paradigm, we unintentionally encourage developers to think in *local mode*, when really they should be thinking in *distributed mode*. His point is that additional considerations must be met (time, reliability, security, etc.) And by forcing the developer to acknowledge these concerns, runtime disasters will be decreased. His feeling is that Indigo (from Microsoft) does a good job of making the developer acknowledge the distinction between local and distributed calls, thus meeting a need in the developer community.

The Idealist
On the hand, I am the idealist. It is my opinion that we should continue to strive towards location transparency. Thus, we should continue to use one programming model (and invocation model) for both local and distributed calls. I believe that the SOA model largely facilitates location transparency and this should be leveraged. However, Chris (and others) will be quick to point out that this is like getting half-pregnant. Either your system is working efficiently in distributed mode, or it isn't. And in virtually every occasion, computer scientists will tell me that the great hurdle in location transparency deals with the static nature of message exchange sequences between client and server. In local mode, people strive towards fine-grained calls and in the remote mode, the coarse grained method is preferred. As an idealist, I am of the opinion that we shouldn't *dumb down* the programming model to reduce developer design errors. Rather, I feel that we should take the bull by the horns and look at the real issue of automating the granularity at run time (based on costing functions). However, to accomplish this, we need to give our runtime containers mode knowledge about our *intent* (think 'use case based sequence diagrams'). Now, instead of asking for a single method to be called, we ask for a 'use case' to be fulfilled. IMHO, more emphasis needs to go on writing smart software that fulfills an intent, rather than acting out a predetermined recipe.

Does Indigo excite me? Not really - I see good concepts from P2P, AOP and Trust rolled together. The exciting part is that MS has the resources to pull it off and make it easy to use.

Chris is a smart guy - he might be right. I don't know.