The appeal of space-based programming (e.g. Linda and JavaSpaces) is that it is all about spaces. Transports get commands and data (documents) from processes to spaces and from spaces to processes. Transports are inconsequential. There can be many. They can come and go and evolve.

The essence is the same: coordination through a set of simple space-based commands that can be combined in an infinite variety of ways.  ¶ 5:57 PM

So the next question is, how do the Linda coordination language and the HTTP coordination compare?

Linda has 'out', 'in', and 'rd'.

• Out - put something in your process out into the shared space.
• In - bring something from the shared space into your process (it is no longer in the shared space).
• Rd - copy something from the shared space into your process (the original remains in the shared space).

HTTP has Get, which is kind of like Rd. Except a Linda system is guaranteed to implement the simple definitions of Rd. A web server can implement anything at all for 'get', i.e. there can be untold side effects.

None of the other HTTP commands are specified to act like the remaining Linda commands. And every one can have untold side effects.

My quick assessment tells me that HTTP is not nearly as simple as Linda for the purposes of coordination. But a web server could choose to interpret some of the HTTP commands to behave more like the Linda commands.

My experience as a developer tells me Linda's commands make good coordination 'combinators', i.e. they can be combined into many variations of desirable sequences for coordinating multiple processes.   ¶ 5:49 PM

Steve Wozniak via email: "In my opinion the guiding principle, for all copyrighted material, should be that if any material is presented to your senses (sight, sound, etc.), free or paid for, then you should have the right to memorialize it, to record it and to get it later."

Presumably then this would apply to software. Which is nearly Stallman's position, right? (Stallman includes freely modifying, not sure if Wozniak's does. Stallman's includes freely sharing, not sure if Wozniak's does.)  ¶ 5:05 PM

"Does distributed computing have to be any harder than this? I don't think so." In retrospect, that was a useful thing to ask at the time. Of course it conveniently swept under the rug a whole set of issues which we now gather under the rubric "service-oriented architecture." Today I might rather ask: "Does distributed computing have to appear to be any harder than this?"

Well said.

I attended another seminar last night on "Service Oriented Architecture". The result was another audience of essentially web and VB developers sitting in stunned silence as they attempt to relate the presentation to anything remote familiar in their own experience. Yet again the presentation included a parade of the various Web Services extensions:

• WS-Addressing
• WS-Coordination
• WS-Inspection
• WS-Policy
• WS-Referral
• WS-ReliableMessaging
• WS-Routing
• WS-Security
• WS-Transaction

Of course Microsoft and IBM will attempt to "peanut butter" over the inherent complexity in their respective IDEs. But is this really necessary? Most of the cases I think could be solved more simply and so with a simpler presentation for the typical developer.

The two missing aspects of every presentation I've attended so far are:

• Coherent use cases that demonstrate the advantages of when and how to use each of these features. A "Use Case" specifically would indicate who (which developer roles) would be interacting with which services during the processes of developing and deploying a "Service Oriented Architecture".
• Evaluations of alternative strategies. These standards-in-progress are not mature. They do not strike me as "the simplest thing that could possible work". And yet they are just assumed to be the new "distributed system language" of the future, that will make everything better. I'd like to have some transparency into the decision making process, and see what alternatives have been discussed. Unfortunately having participated in the development of standards a couple of times, I know that alternative evaluations are rarely given their due.

Coarse-grained messaging. Get everything you need in a single round trip. Why? If not, your shut apps down.

I am interested in space-based messaging. It's cheap and scalable to place a "semi-persistent document space" in the middle of communicating processes.

Even now, the numbers are big: 3000 messages/second flowing through Web services message brokers.

"Document spaces" are a useful abstraction for managing the evolution of documents and processes over time, location, size, amount, and definition, five dimensions of loosely coupled systems.

Public contracts. You can change your operating system, you can change your object model, but don't change your public contract. We know this works. "The proof point is the web."

This works to a point. HTTP should evolve more slowly than a supply chain process, though. So we need flexible contracts and systems that can tolerate change. Contracts must include tolerance specifications. And so defining exceptional behavior is at least as important as defining the straight through behavior.

Asynchrony. "I've been surprised by how slow some companies have been to pick up on asynchrony." The recently-published WS-Addressing "contains the core plumbing for standards based asynchrony."

I have to say I have almost zero knowledge of WS-Addressing. My fear is that it is unnecessary. I am a big fan of black boxes. A process only requires a simple end-point definition. Put anything you want to behind that end-point.

Databases are great at asynchrony. Data comes and goes at unspecified intervals. Space-based data provides a simple database-like end-point for data exchange: putting a document in some space with this pattern implies an offer of or a request for services of some nature.

I am a big fan of black boxes. Another name for a black box is a "public contract". See above. Do what you want with that document, but obey the contract. My process interface only changes when the contract changes.

Message-driven model. We need a programming model for message-driven programming. How does a developer write code in that environment? "It's no problem for systems programmers, but for everybody else, it's a challenge to make it easy for them to write apps that wake up when a message comes in."

This is because the systems programmers run the show. Frankly, they tend to like complexity. I know, I've been one for most of my adult life, working on operating systems, compilers, digital logic simulators, manufacturing automation, video conferencing, financial systems, object-oriented databases, and probably something else.

There are a few examples of simplicity in the software industry. Latch on to those for your life, and question anyone who thinks you should let go.

By the way, to give you some bearings on my position: I think Java and C# are *horribly* too complex. The WS-xxx standards give me heartburn.

Declarative query. "We don't have a good query mechanism for XML... In practice, Web services messages have known schema. A query language that knows the schemas can optimize."

The only point to add here is that schemas and query languages must still allow for change. Queries should say just enough but not too much. Optimizers should not influence the language, simplicity should.

Scripting.

I simply interpret this as the need for simple languages and architectures that can be adapted at run-time. My implementation languages (Scheme, Smalltalk, JavaScript) are my scripting languages. Seamless.

Two complementary technologies will enable "dynamic runtime-modifiable systems, rather than static compile-time systems that make you shut down and restart your services." They are:

• XML Query, for declarative work, and
• ECMAScript for XML (E4X), for procedural work (see also this heads-up)

I'm not overly familiar with XML Query, but I appreciate the point.

XML repository. In Adam's vision of SOA (service-oriented architecture), a message broker sits in the middle of everything. It sees a lot of self-describing XML messages, and it has to do high-performance storage and retrieval. So it's a true XML database. There's nothing relational about this problem. But, being an old database guy, Adam sees an opportunity. In the message broker, the XML data store is not inherently multiuser. "It deals with messages in flight, and this makes it possible to do all sorts of optimization."

I hope to get some specifics on this. What does it mean for a data store to be "not inherently multiuser" and yet "sit in the middle of everything"?

Again the most flexible software device I have encountered is the document space. Gelernter's rules, now more than 20 years old, are the 80% sweet spot between messages, processes, databases, workflow, etc.

Great talk. It's always refreshing to watch Adam Bosworth paint the big picture!

Wish I was there.   ¶ 4:05 PM

Some of their soldiers are mere children. We know we have overwhelming, superior power, yet we can't use it all. We're stunned to discover that the local population treats our well-armed high-tech troops like invaders.

Why is all this a surprise again? I know our hawks avoided serving in Vietnam, but didn't they, like, read about it?  ¶ 10:51 AM