Only solve the problems you need to solve

Back when I was a grad student I was spinning out of control trying to come up with a thesis topic. My advisor took me out to lunch one day and asked me a simple question: "What is a PhD thesis?" I yattered on for a while and he listened patiently. Eventually he said "No: It's just a stack of 100 pages with 4 signatures on top". I was falling into a common grad student trap of feeling that I needed to do something grandiose and solve all of the worlds problems. He was into "keep it simple". So I did, and I came up with a pretty straightforward thesis proposal. The odd thing was that when I finally finished my thesis, I realized that I had only delt with one sentence out of the simplified proposal.

I got a lot of email about my previous post, a lot of it centered on JINI, RMI and CORBA. Not too many months ago, during the hypon flux storm [by analogy with bogon flux] surrounding SOA and Web Services it was worth one's life to mention that folks had been successfully implementing SOAs for years. That has calmed down significantly. JINI is particularly interesting since it goes significantly beyond what's possible with today's SOA - but it only works in a Java-only universe. The folks who developed RMI/JINI had previously worked on CORBA. A big chunk of the complexity of CORBA comes from trying to solve the cross-language problem. They discovered that if you don't try to solve that problem, some very cool things emerge. The poster child for building SOAs on JINI is Orbitz. There are some interesting discussions here and here.

In response to the comment about OO and granularity: they really are orthogonal axes. OO methodologies work well regardless of granularity. But granularity is related to the question of whether or not an operation can sensibly involve a network transit: it only works well when granularity is high. This is a direct corollary of the Eight Fallicies of Distributed Computing.

October 4, 2005