Adam Bosworth paints the big picture and the broad strokes look attractive

From Jon Udell, Adam Bosworth paints the big picture. The broad strokes look attractive, but I think there is a simpler picture that can live within the same basic frame.

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.