Making it stick.
Saturday, April 05, 2003
  Space-based Programming is About Spaces, Not Transports SOAP is a virtual transport. WS-xxx extensions are sometimes about transporting, sometimes about routing, sometimes about data (documents).

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. 

  REST and Linda Does HTTP make a good coordination language?

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

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

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.  

  Wozniak and Stallman: Separated at Birth? From Scripting News...

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.) 

Friday, April 04, 2003
  A Perfectly Phrased Question re: Distributed Computing Jon Udell puts it like this, referring to XML-RPC...

"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:

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:

Tuesday, April 01, 2003
  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.


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:

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.  

Monday, March 31, 2003
  U.S. Inactions Hindering Search for Al Queda and Taliban? The chief of the US forces in Afghanistan, Lt-Gen Dan McNeill, said he was "frustrated" that the West had "not made a more bold step" to rebuild Afghanistan, adding that this could be an important lesson for Iraq. The US search for al-Qa'ida and the Taliban would have been easier if the aid had flowed faster, he said. 
  Why is all this a surprise again? Maureen Dowd's op-ed she should have written before the conflict started...

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? 

Patrick Logan's weblog.

March 02, 2003 / March 09, 2003 / March 16, 2003 / March 23, 2003 / March 30, 2003 / April 06, 2003 / April 13, 2003 / April 20, 2003 / April 27, 2003 / May 04, 2003 / May 11, 2003 / May 18, 2003 / June 01, 2003 / June 08, 2003 / June 15, 2003 / June 22, 2003 / June 29, 2003 / July 06, 2003 / July 13, 2003 / July 20, 2003 / July 27, 2003 / August 03, 2003 / August 10, 2003 / August 17, 2003 / August 24, 2003 / August 31, 2003 / September 07, 2003 / September 14, 2003 / September 21, 2003 / September 28, 2003 / October 05, 2003 / October 12, 2003 / October 19, 2003 / October 26, 2003 / November 09, 2003 / November 16, 2003 / November 23, 2003 / November 30, 2003 / December 14, 2003 / December 21, 2003 / December 28, 2003 / January 04, 2004 / January 11, 2004 / January 18, 2004 / January 25, 2004 / February 01, 2004 / February 08, 2004 / February 15, 2004 / February 22, 2004 / February 29, 2004 / March 07, 2004 / March 14, 2004 / March 21, 2004 / March 28, 2004 / April 11, 2004 / April 18, 2004 / April 25, 2004 / May 02, 2004 / May 09, 2004 /

Powered by Blogger