So this is the 1,000th entry in my blog since I began on December 20, 2003. I thought I’d use this opportunity to revisit some of my favourite entries and the discussions that followed. All of these entries are tagged “1K”. The criteria are purely personal.

• We have always been at war with Eastasia….
  I wrote this piece about the rapprochement between Sun and Microsoft in April ’04. It attracted a number of comments; more significantly it was also linked by Andy Orlowski of The Register. While this isn’t as severe as being Slashdotted, I rapidly hit the puny bandwidth limits on my old hosting service, and a couple of months later I rehosted on Steve Lau‘s grommit.com.
• On the difficulty of keeping on topic….
  This piece was just a little rant about how hard it was to avoid over-complication and distraction when trying to understand a relatively simple problem. (I simply wanted to understand the kind of transaction rate generated by an RFID-based warehouse and shipping system.) To my surprise, it became one of the most-linked-to pieces in my blog.
• Java, open source, standards, and conformance
  I’ve come to the conclusion that software engineers are divided into two camps: those for whom the truth is the code, and those who believe that the truth is the specification. I’m in the latter camp: I believe that it’s important for there to be multiple implementations – interoperable and substitutable – of any important technology. Monocultures are dangerous. The way to avoid them is to create good specifications and build (and test!) various implementations. That’s why I’ve spent much of my life working on standards: X/Open, IETF, NFS, WinSock, W3C, FIPA, etc.
• How people see Sun
  Inevitably many of my blog entries have been about Sun Microsystems, and this is one of my favourites. In it I drew on my experience of talking with customers and the ideas from The Cluetrain Manifesto to identify one of Sun’s problems: how to translate conversations about technology into purchase orders. These ideas became even more important after I became involved in the StorageTek integration effort, because storage involves a quite different kind of conversation.
• Interrelated aspects of interaction (and Interaction: Typing)
  There are some interesting, almost paradoxical ideas floating around in distributed computing. They involve things like type models, composition, static vs. dynamic binding, autonomy. In these two blog entries I started to discuss some of these ideas, but I soon came to the conclusion that a blog is not the best medium for such things. I still like this stuff, though: I guess I’ll just have to write a paper, or something.
• Debating WS-*
  Getting referenced in The Register isn’t nearly as much of a traffic generator as “getting TB’d” – getting a mention in Tim Bray’s ongoing. In September 2004, I took a crack at the slow-motion train wreck of the bloated web services “standards” process. It’s not that I’m against standards, as I’ve already noted. The point is that the governance of the standards process is just as important as the specifications themselves, and Microsoft’s hegemony was (is) in nobody’s best interest.
• The Anthony Flew brouhaha
  Of all the subjects I’ve blogged on, the one that has generated the most discussion is the sad case of the English philosopher, Antony Flew. The short version: eminent atheist philosopher (Antony Flew) gets taken in by a charlatan (Gerald Schroeder) peddling an “irreducible complexity” argument about DNA; eminent philosopher concludes that this may be evidence for a designer; triumphalist creationist huckster (Roy Abraham Varghese) persuades Flew to go public at a conference; creationists crow about the “conversion of the most famous atheist”; Flew talks to some real scientists, and makes a half-hearted retraction, apologizing that he doesn’t know what he’s talking about.
  This first piece attracted 53 comments; later entries included More on Antony Flew, Carrier on Flew, and Antony Flew: at last, the book. The discussion ran on from December 2004 until May 2005, and I was still getting email months after that.
• To Prius or not to Prius…
  Last spring, I wanted to replace my car, and I blogged about my choice: should I get a Toyota Prius or a Subaru Legacy. Eventually I chose the Subaru. The odd thing was that even though this was a non-obvious choice – I had to consider fuel economy, the value of AWD on our hill in the winter, availability, and so forth – it attracted a ton of email either scolding or ridiculing me as a “sell-out liberal who doesn’t have the courage of his convictions”. Weird.
• Wrong premise, misleading conclusion, and Jini, Indigo and the “Highlander Fallacy”
  Two of my favourite blog pieces were written in response to a Microsoft blogger who argued (crudely) “we learned from all of Jini’s mistakes, and Indigo is the One, True Way for future distributed computing”. I thought I did a pretty good job of refuting his arguments, and others agreed: I received lots of appreciative feedback.
• On the guilty pleasure of reading a really bad book
  No, this wasn’t a reluctant confession of an addition to Robert Ludlum or Dan Brown. I bought a technical book while on a trip last June, and discovered to my dismay – and then delight – that while it looked superficially plausible, most of the prose was entirely meaningless! The book was a dead loss – but the resulting blog piece was enormous fun to write.
• My thoughts on Indian traffic
  Regular readers will know that I’ve visited India twice in the last year, and it made a great impression on me. (You can find lots of my blog entries and photographs from those trips.) I was particularly impressed by the Indian approach to traffic, and I tried to distill my impressions in this short essay. Dozens of my Indian friends and colleagues have told me that I captured the gestaldt of Indian traffic to perfection….
• RIF
  If the Antony Flew affair was the most commented-on series of blog entries, the second was clearly the group that followed my getting laid off from Sun. The announcement was followed by my thanks (including my slides from the party), the FAQ for those who couldn’t understand how this could happen, and finally clearing out. As for what comes next, just bookmark my RSS feed!

So that’s the 1,000th blog entry. For the record, it looks as if there are 1,603 comments in the system. Thank you for your contributions. (I wonder how many are undetected spam!) I’ve successfully negotiated the two big hurdles that every blogger dreads: rehosting on a new system, and changing from one technology (MovableType) to another (WordPress). I’ve enjoyed my blogging enormusly, no matter where I find myself, and I plan to continue. The Gadster suggested that I should speculate on what things might be like when I reach my 2,000th blog entry. At the present rate, that should occur around the end of 2008. Hmmmm….

According to the WordPress dashboard, this blog entry will be the 998th that I have made. So what should I do for entry #1,000? Chris (who just arrived from California for a weekend visit) suggests that I pick out my favourite postings from the last couple of years. Any other suggestions?

I spent today at Sun, tidying up loose ends. I returned my library book 😉 , packed up my books, and shifted large quantities of paper to the Secure recycling box. (I’d kept a paper copy of ever performance review I’d received or written for the last 10+ years, along with tons of specs, proposals, project plans, etc.) I removed my pictures from the wall (nicely framed reproductions, hung in defiance of corporate standards), and sorted out which bits of stuff were mine and which were Sun’s. (The Apple keyboard was Sun’s, but the Mighty Mouse is mine.)
When I was done, I joined the rest of the SunLabs gang for lunch. Then I toured the building, saying goodbye. None of the conversations were short, and along with hugs (and a few tears) I received tons of useful ideas and advice. One thing really struck me. Although it’s been many years since I last left a job, I can remember how we would all express our intentions to stay in touch, and how 99% of such professions turned out to be worthless. But today, in the era of blogs and email, I think it may be easier. I’ve bookmarked RSS feeds from the blogs of many friends, and whenever I see a posting from them it reminds me that a quick email is only a click away. I hope all my friends at Sun will take the hint; I will certainly continue to watch what goes by on b.s.c and PlanetSun.
And then I rolled the cart with my boxes out to my car, loaded it, and left. (Thanks, Steve.)

I’ve received so many emails and blog comments about my departure from Sun that I decided to put together a little FAQ on the subject. Obviously these are my opinions; I don’t speak for Sun 🙂

• Q. Why the RIF?
  A. That’s easy: Sun wasn’t achieving the profitability that was expected. The Q2FY06 numbers were significantly below what we’d all hoped for, and it was clear that something had to be done in order to establish an upward trend through the rest of the fiscal year.
  As to why the numbers weren’t what was needed, that’s a different matter. I can think of various contributing factors, but I don’t have an overall answer.
• Q. OK, but why you?
  A. I’m not sure. There are several possible explanations. It could be that Greg Papadopoulos (Sun’s CTO) is simply getting out of the business of cross-company processs work. Perhaps everyone not associated with a strategic revenue-related product, program or customer is at risk. Or perhaps I was simply in the wrong place at the wrong time. I happened to be reporting in to a department whose project was being scrapped, even though I wasn’t actually involved with it. It’s hard to tell, especially because I don’t know….
• Q. Who else is getting laid off?
  A. I don’t have the big picture yet; neither the size nor the shape. Some of it, I suspect, is due to duplication of function or project between Sun and the companies we recently bought. Speaking as a shareholder, I hope that the management will be taking advantage of the situation to re-balance certain aspects of Sun’s operations that had drifted out of sync. (Yes, that’s maddeningly vague, but I’d prefer to see if I’m right before I explain further!) We’ll see.
• Q. Did this come as a surprise, or did you know what was going to happen?
  A. Obviously I knew that a sizeable RIF was likely after the Q2 numbers were released, and a couple of weeks ago I got some indications of the projects that were at risk. But because my recent work was sui generis, I didn’t know whether or not my job was on the line. And since I couldn’t do anything about it, I chose not to worry about it.
• Q. How are you feeling? This must be awful, after so many years.
  A. Thanks for the thought, but I’m actually doing just fine. In this business, in this economy, working for one company for so long feels… well, anomalous. And I must say that occasionally I wondered if I’d become “institutionalized”: did I have a sufficiently broad perspective, was I too focussed on Sun’s internal issues? Well, now I get to find out. I’m approaching this as a fascinating new adventure, and I’m pretty excited.
• Q. So what are you going to do next?
  A. Not rush into anything! I’ve got a decent severance package (one benefit of 20+ years at Sun), and I want to take the time to explore the possibilities. I could get a conventional job, or do some consulting, or kick off a start-up. I want to talk to a lot of people, learn about life outside Sun, and then choose and act, deliberately. However I don’t plan to take much of a break. I don’t play golf, and I’m not going to emulate some people I know who regard this kind of situation as an opportunity to lower their handicap. When an adventure beckons, why dawdle?
• Q. How about returning to Sun?
  A. Quite a few people do this, and I’ve talked to some of them. Sun certainly encourages returnees. But it’s just one option, and I’m not counting on it. (No backward glances, but no bridges burnt….)
• Q. So how about doing lunch some time?
  A. Sure! Let me check my calendar.
• Q. Blogging is very much a Sun thing. Are you going to keep on blogging?
  A. Absolutely! I was blogging before Sun got the bug (though not as long as people like Tim or Alec), and I plan to continue unabated. And that reminds me: if you normally read this blog through one of the Sun aggregators, please grab a direct feed before PlanetSun or b.s.c drops it. Thanks.

I’m overwhelmed at all the kind comments from people about my RIF. I’m not the only one: there are lots of really good, smart people leaving Sun in this process, and the company will be the poorer for their departure. Look for them on LinkedIn, please.
As I mentioned, I was due to host the Thursday afternoon SunLabs tea, and I decided to turn it into a celebration. After all, how often does someone get to spent 20 years with so many creative, imaginative, dedicated people? I picked up some champagne and pastries, threw together a few slides*, and we had a really good time. Thank you all. And best wishes to the other RIFfed folks that joined us.
I’ve amended the info in the sidebar to include my new email address. (It’s going to be interesting to hunt down all of the places which have my Sun address – airlines, iTunes, etc. etc.)
—
* The slides are here – PDF, about 975KB. I don’t think there’s anything proprietary. For those who were at the tea today, I’ve added a footnote with the punch-line to that joke.

Well, after 20.63 years at Sun, I have been caught up in today’s RIF (Reduction In Force). As of 5pm today, I’m out of here.* So far the most common reaction is “You’re kidding!!!” Sadly, no.
However between now and then I’m hosting the regular Thursday afternoon SunLabs tea, so I’d better get on with the arrangements.
—
* Of course over that period you accumulate a lot of stuff, and there’s no way that I can clear my office today. No matter.

If you know me, you’ll know that I’m a sucker for cool new technology. (However I do have some blind spots: I still haven’t got a TiVo. Perhaps I really do believe in network services, in which case TiVo is a short-term fad and a technological dead-end. We’ll see. More prosaically, I donb’t watch much TV.)
Anyway, Lufthansa now offers internet access from their long-haul aircraft, and so I decided to buy an hour of access for $9.95. Latency is quite acceptable, the sign-up process (using Boeing’s Connexion by Boeing) is very straightforward.
Right now we’re at 34,000 feet (FL340 if you prefer), just crossing the Outer Hebrides of Scotland and heading towards Iceland and Greenland. We left quite late – once again, a couple of passengers didn’t board, so we had to offload their baggage; then we had to de-ice which took longer than I expected. However with light headwinds we are told that we should arrive on time,
Reading material on the flight is Kate Fox’s “Watching the English”, a wonderful bit of rigorous sociology/anthropology disguised as a book “for the intelligent layman”. As an expat Englishman, it’s fascinating to explore where some of my weirder* behaviours come from – but also how much of my “Englishness” I’ve lost! For example, I now tend to tip the bar staff in a pub, which is terribly gauche. (Hell, I miss my local pub. I’d love to be a “regular” somewhere other than Starbucks.)
—
* By American standards, anyway, but then most Americans don’t understand the English.

Suppose that you’re driving down a four lane, non-divided suburban street in the USA, with a sidewalk on each side. In decreasing order of frequency, you’d expect to encounter:
– cars
– trucks
– buses
– pedestrians
– motorcycles
– bicycles

In India, the corresponding list would be something like:
– bicycles
– pedestrians (with or without pushcarts)
– motor scooters
– motorcycles (with up to four people on board)
– ultrasmall cars
– auto-rickshaws (passenger and goods versions)
– trucks (huge slab-sided things)
– regular cars
– buses
– cows
– luxury/sports cars
– ox-carts
– goats (in herds)

In the USA, the different types of traffic would be logically segregated: pedestrians on the sidewalk, slower vehicles in the right-most lane, and so forth. Furthermore traffic tends to keep to the right, only crossing the centre line for occasional overtaking.

In India, approaching vehicles keep left when passing each other. That’s pretty much the only rule. Any of the types of traffic listed above may be encountered anywhere on the road, including the sidewalk. “Lanes” are a polite fiction, an occasional decoration on the tarmac; road signs are everywhere; traffic lights are so rare that they actually seem to command respect, possibly because they’re such exotic creatures. Traffic may be moving at any speed from zero to 50 MPH – and occasionally in reverse! – in any “lane”. The sidewalk is simply another space to be occupied by any vehicle, and pedestrians may be encountered anywhere – even in the fast lane of a divided intercity highway. Overtaking takes place on either side; if space is limited, the horn is used incessantly until the gap opens up. At an intersection, nobody stops: they just proceed straight into the flow and somehow they’re absorbed (usually with more horn blasts).

[Amusing touch: Trucks and auto-rickshaws have crudely painted signs on the back, saying “HORN PLEASE”.]

And it all works. Dammit, the traffic in Pune works better than the traffic in Boston, or San Francisco. Even though it looks chaotic, it keeps flowing almost all the time. (On those rare moments when it doesn’t, volunteers step up to direct traffic and sort out the mess.)

Why does it work? There seem to be two related reasons. First, there is no prescribed “right of way”. You can’t assume, or insist on your right of way where none exists. All interactions – overtaking, merging, giving way to crossing traffic – seem to be based on instantaneous negotiations between the various parties, with the “body language” of the vehicles conveying the necessary cues.

The second reason is that nobody pushes 100%. Everybody seems to drive at about 60% intensity. That may seem odd, when you see vehicles packing into a space with scant inches between them, but I think it’s true. When in doubt, yield – if it’s the wrong decision, you’ll be able to make it up later. If you lose a merge, don’t fight it, relax – even if that opens space for someone else. And there’s a rhythm to it, a kind of balancing that reminds me of the women walking by with bundles of goods on their heads. When a car comes up to pass a bicycle, the rider sways out of the way, just enough to allow the car to pass. It’s not a manoeuvre, it’s a dance step. It’s what the AI guys call “swarm intelligence” of a very high order: self-organization rather than rules-based.

And of course at night it gets even crazier, because half the vehicles have no, or defective, lights. But it still works.

[Another amusing touch. High-end cars have door mirrors that fold out of the way at the touch of a button. When the spacing between vehicles is measured in a few inches, this is more than a luxury.]

What does it feel like? This morning as I was being driven to Pune airport, there was one perfect moment when the car I was in was overtaking an auto-rickshaw, which was overtaking a bicycle, which was swerving round a cow. As we did this, a large SUV overtook all of us. Between us, we occupied the entire width of the street, and not far ahead there were two or three “lanes” of traffic approaching us at speed. Somehow it all just flowed together and past.

I can’t imagine driving here myself. I think you’d have to grow up here to learn the music of the street. If you can’t sing it, if you’re not note-perfect, it must be miserable. But watching the performance is totally absorbing – initially frightening, then exhilarating. I guess it could become almost mundane over time, which would be a shame.

This is going to be long – skip it if you’re in a hurry.

Today I was at Sun’s Santa Clara campus for an all day meeting of the DEs. We finished up on time, just after 5pm. The last session had left me feeling exhausted: a 20 minute presentation stretched to a relentless 40 minutes, followed by a complicated debate. I felt like a drink and some food (my body is still pretending that it’s on East Coast time), but 5:30 seemed a bit early to eat. I therefore decided to drive over to the nearby Micro Center store and do what geeks do: ogle hardware and software. There’s a passable Mexican restaurant in the same plaza (the Mexicali Grill), and I thought I might find a book or magazine to read over dinner.

The store was very quiet, and the few customers seemed to be lowering their voices as if they were in a library. I found nothing of interest in the Mac section, or the PDA accessories, or the magazines, or even the discount DVDs. (I wonder who buys those boxed collections of 20 horror movies from the 1950s, not to mention The Neverending Story Volume 2.) And so I made my way to the book section.

It just so happens that I’ve been discussing the possibility of doing some work with Sun’s Network Storage Division, the group that sells such products as the StorEdge 9990 array and the QFS file system software. I’m quite familiar with our products, and I used to work on distributed file system software such as PC-NFS, but there are parts of the storage business that I know little about. So when I came across a large book about storage systems, I started browsing it. The table of contents looked promising. I checked the price: $5.99, reduced from around $50. I put this down to overstocking, bought a copy, and went off to have dinner and a bit of a read.

By the time I’d finished my salad, and a Silver Bullet margarita, I realized that I had acquired a Really Bad Book. It was weird: the organization was plausible, and by speed-reading I could sustain the illusion that it more or less flowed and made sense. But if I slowed down and looked carefully at individual sentences, they were gibberish: ungrammatical, rambling, cliché-ridden, and full of non-sequiturs. At first it was annoying, but by the time I reached the end of the first chapter it had become simply hilarious. Some examples, with original punctuation:

“The corollary, or trade-off to this condition, is the economics of speed and capacity to price.”

“Within the SAN, these operations become more logical and have to coexist with other servers that share the fabric network and devices connected.”

“Finally, as the sophistication of the centralized mainframe computers was downsized, the capability to house larger and larger databases demanded the deployment of the database server.”

It goes on and on like that. Verb agreement is a matter of happenstance; dereferencing a pronoun should only be attempted by trained professionals. At times we seem to enter an Alice in Wonderland world of topsy turvy relationships:

“The most critical element of performance for a business application is its availability to its own data.”

And sometimes a sentence seems to have been assembled by a surrealist playing with magnetic fridge poetry pieces; here’s a final, glorious example.

“Unless the hardware and firmware release levels are inventoried and tracked in conjunction with the network, the NAS systems become unassociated storage servers unbound to the confines of the network in which they operate.”

I cannot shake off the image of a row of NFS servers growing large, colourful wings and fluttering away like butterflies towards the setting sun – unbound, free of the confines of the network!! Excelsior!!!

[I’ve done my best not to identify this book or its author. If you figure it out, please keep quiet. There’s no point in stirring the pot.]

In Craig McMurty’s blog entry that stirred up discussion of Indigo and Jini, he mentions a piece by Don Box, in which “the four fundamental tenets” of service-oriented development are laid down. Craig further asserted that ‘The “services” that one can construct with Jini do not conform to any of those four tenets’. Really? Well, given how badly Craig seems to have misunderstood Jini, I decided to go back to the source and see what the good Mr. Box has to say for himself.

So what exactly are Don’s four fundamental tenets?

1. Boundaries are explicit

2. Services are autonomous

3. Services share schema and contract, not class

4. Service compatibility is determined based on policy

Plausible? Well, the first two are unexceptional, and describe Jini services quite nicely. I suspect the devil may be in the details. The third seems unduly coupled to a particular technology and language; if we replace “schema” with “interface” and “class” with “implementation”, it feels OK – and describes Jini very well. And the fourth? I have no idea what it means, but on the surface it seems to conflict with the second (autonomy) and to overlap with the third. Perhaps we can resolve these conflicts later on. Let’s dig into each of these ideas.

1. Boundaries are explicit: Back in the early days of distributed computing, it was considered a good idea to hide the boundaries, to make remote resources look just like local ones. This is what gave us remote file systems and early RPC schemes; in extremis it gave us things like Locus. Over time the wisdom of folks like Peter Deutch and Jim Waldo cured us of this. These days we all believe in explicit boundaries.

   Box, however, introduces what seems to me like a non-sequitur: “Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message passing rather than implicit method invocation.” Now this is bizarre. He’s saying that because an interaction may be expensive, we have to describe it explicitly at the lowest level. Even if one is performing a higher-level pattern, such as a method invocation, one is required to unpack it by describing the individual message patterns and how they are correlated. While sometimes this may be appropriate, it hardly seems fundamental. For a start, it conflicts with the notion of autonomy. Why should a client and service, mutually consenting adults, be required to describe their interaction in such detail in advance? Why could they not negotiate a mechanism on the fly, using available resources?

   Box goes on to say, “the fact that a given interaction may be implemented as a method call is a private implementation detail that is not visible outside the service boundary”. But this is disingenuous. How detailed, how explicit is the message description? Either we give up on type (or schema) based notions of compatibility, or every interface requires a detailed description of request and response messages which will make the “private implementation detail” instantly public (and will significantly constrains the ways client and service can interact).

   A final thought on boundaries: while they may be explicit, they are not necessarily static. Refactoring is a fact of life. In practice this means that software components will be constructed in such a way that potential boundaries are declared as such (using, for instance, the remote interface in Java), and services will be assembled and composed in terms of such interfaces. Describing a service in terms of a low-level message exchange pattern then becomes one technique among many for defining service boundaries, and one that is generally effected by a design tool of some kind. It’s an implementation artefact, not a design principle.

2. Services are autonomous: Box’s account of service autonomy is excellent. He discusses version skew, the dynamic nature of the aggregations that comprise a system, the effects of unintended usage, partial failure, and security. (He could also have said something about dynamic discovery, self-healing, the use of patterns such as broker and facade, and the use of techniques such as introspection to perform dynamic adaptation.) There is nothing here that a Jini enthusiast would disagree with.

3. Services share schema and contract, not class: Earlier I wondered if this referred simply to a separation between interface and implementation. This understates Box’s position. He writes, “services interact based solely on schemas (for structures) and contracts (for behaviors). Every service advertises a contract that describes the structure of messages it can send and/or receive as well as some degree of ordering constraints over those messages.” And he also says that “the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces. It is common for services to use features such as XML element wildcards (like xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code”. So what we are dealing with here are relatively simple interfaces, evolving slowly, with weak consistency and ad hoc extensions.

   Now there are plenty of situations where this kind of approach is just fine. As Box notes earlier, it’s the kind of thing that made Amazon.com’s services the success that they are today. But for other applications, this kind of thing is hopelessly inefficient or inflexible. For the vast majority of intranet services, for instance, the most common way to invoke a service isn’t going to be by parsing its description and constructing a new client stub ab initio: it’s going to be by invoking a copy of the stub code generated when the service was created. And if you’re going to do that, why not take advantage of it – not just at compile time, but dynamically, so that the interactions with the service can reflect the characteristics of the deployed service? As for the suggestion that one needs more flexibility than “traditional object-oriented interfaces”, mechanisms like introspection allow for powerful and robust run-time flexibility, without sacrificing type safety.

   It seems to me that the fundamental principle involved here is the one I alluded to earlier: establishing a clear separation between interface and implementation. How we do that seems to depend on the application and context; there is no reason to believe that one size fits all.

4. Service compatibility is determined based on policy: It turns out that what Box is talking about here is the distinction between structural compatibility and semantic compatibility. The latter is familiar and unremarkable: XML schemas, class signatures, on-the-wire encodings, that kind of thing. But what Box is interested in is “[s]emantic compatibility… based on explicit statements of capabilities and requirements in the form of policy”. He gives a few hints about what he’s thinking of, but at this stage I think it’s safe to say that he raises more questions than answers. Suffice it to say that this whole area is in its infancy, and it’s not an immediately important issue. By the time we figure out exactly how to express
   such things (OWL-S?), how and when services get to ” apply simple propositional logic to determine service compatibility”, and exactly what customers want to use this for, our initial expectations are likely to change significantly. There’s certainly nothing here that is incompatible with Jini.

So what’s the verdict? Was Craig correct to claim that Jini doesn’t conform to Box’s “tenets”? Unambiguously not: Jini absolutely conforms to every aspect of Box’s “autonomy” tenet. How about the others? Well, it all depends on whether you read the interface or the implementation: whether you concentrate on the broad principle, or how Box chooses to implement it. Jini is entirely compatible with the broad principles, but not surprisingly it’s not going to conform to Box’s Procrustean Bed of message-based service patterns. But why should it? Box gives us no reason to believe that this technology is the only way to realize the principles. It’s just the way Microsoft chose.

I’ve already discussed why Microsoft took this path, but it’s important to recognize that it’s not the only – or even the best – approach. There are more powerful, elegant, and efficient models for realizing the principles of service-oriented distributed computing, and Java and Jini represent such a model. For Box and McMurty to argue that only one technology fulfills these principles is self-serving, not to mention ahistorical. The wide range of problems to be solved, the variety of contexts in which the solutions must operate, and the kinds of constraints and requirements that must be met, are such that multiple technologies will clearly be needed. As Jim Waldo pointed out, the “Highlander Principle” (“there can be ‘only one'”) is a fallacy.