Just a Little is Enough

Steve Loughran writes...

As an aside, ...it's clear that Tomcat is all that most server-side [Java] installations need.

More Colbert Gushing

Steven Hart writes that Colbert's performance is like Swift delivering A Modest Proposal in the king's court. Of course this is still America and critics are deflecting a lot of heat by writing about how great America is that Colbert has the right to do such a thing. But Hart responds to those statements correctly...

Colbert is as much a target for big media now as Howard Dean was in 2004 once he announced on NBC's Meet the Press that he'd be in favor of disallowing General Electric from owning NBC. He will have more than a little trouble getting the White House Correspondents' forum back again for similar comments. Making this into a triumph for "free speech" is missing the point by as wide a margin as the adminstration missed so many calculations about the Iraq invasion.

It's one thing to march into the lion's den and yank a fistful of hairs from his mane. It's quite another to march into a den full of people who think they're lions and rub their noses in the fact that they're nothing more than fat, spayed tabby cats who are less interested in exposing the powerful than they are in curling up by their feet.

That's what Stephen Colbert did at the White House Correspondents Dinner, and for his perfidy he will now be subject to their endless mewling and kitty-kat clawing. Even if he loses his nerve and backtracks with an apology — something I don't think for a second he would actually do — he will always be their target. After all, the eunuchs of the court were often the most devious and vengeful of the players surrounding the king...

Colbert's performance was a display of wit at its most lethally cutting. He went into a room with the most powerful man in the world and his courtiers, and he excluded them from the land of the free and the home of the brave.

If the White House courtiers had an ounce of self-respect, they'd all book a flight to Alaska, find a good-sized ice floe and shove themselves out into the ocean. Instead, they'll just go about their routines. They may walk funny for a little while, after the way they've been used, but after six years of covering the Bush administration, they're probably accustomed to that kind of thing.

Daily Zen

Daily Zen...

"You’re traveling beyond hope of return"

- Hsieh Ling-yun (385-433 C.E.)

I Have A Brief Statement...

The Daily Show and the Colbert Report are two of the three television programs that I know of where real news is reported. Democracy Now is the third, and ranks above the comedy shows. TDS and TCR though are simultaneously the two comedies worth watching. (If Amy Goodman could even just learn to crack a smile once and again...)

Colbert has balls, so view the videos and thank him for what he did to Washington and the press. Some people are arguing that it was uneven or did not have a comedy crescendo. I thought it was hilarious in places but to be appreciated overall just as a supreme "fuck you" to the establishment in Washington.

Even by TDS and TCR standards, he blew past them in an opportunity that he may never have received again to spell it out plainly right to the president's and the press' faces... the establishment is circling the drain in credibility, so stop with the games.

"It’s not just that Colbert’s jokes were hitting their mark. We already know that there were no weapons of mass destruction in Iraq, that the generals hate Rumsfeld, or that Fox News lists to the right. Those cracks are old and boring. What Colbert did was expose the whole official, patriotic, right-wing, press-bashing discourse as a sham, as more ‘truthiness’ than truth."

-Michael Scherer, Salon Magazine

From Colbert's "audition tape" for the White House Press Secretary's job...

"I have a brief statement. The press is destroying America."

Losing the War (No, not *that* war)

If Microsoft looks at Ruby as competion then Microsoft has already lost the war, let alone the battle. Whatever happened to that IronPython thingy? I thought that was supposed to make any agile language first-classable on the CLR.

Jabber

"Like email, but really fast"

-Peter Saint-Andre (Jingle.pdf)

Heresy

I enjoyed so much reading the abstract from Avi Bryant's upcoming OSCON 2006 talk about Seaside, I decided to replicate the whole thing here...

Over the last few years, some best practices have come to be widely accepted in the web development world. Share as little state as possible. Use clean, carefully chosen, and meaningful URLs. Use templates to separate your model from your presentation.

Seaside is a web application framework for Smalltalk that breaks all of these rules and then some. Think of it as an experiment in tradeoffs: if you reject the conventional wisdoms of web development, what benefits can you get in return? Quite a lot, it turns out, and this "experiment" has gained a large open source following, seen years of production use, and been heralded by some as the future of web applications.

In this talk, you'll learn in-depth about Seaside's heretical design choices, and how it benefits from them. In particular, you'll see how closures and shared state let you ignore the details of URLs and query fields; how the right HTML generation API makes you less tied to your presentation layer, not more; how continuations free you from ever thinking about workflow as a state machine again; and how all of this combines to enable modularity and reuse like you've never seen before.

No prior Smalltalk experience necessary; open mind recommended.

Waiting for WS-Success

Dan Creswell writes about the search for real, rich SOAP-based systems...

Real-world examples are what I measure on, rightly or wrongly.

Maybe they could be captured on the WS-Success wiki when they are found.

WS-Misunderstood

Eric Newcomer writes in the SOA yahoo group...

Web services specifications are misunderstood and not implemented correctly. JAX-RPC is the kind of "poster child" for this.

Steve Burbeck and Multicellular Computing

Jon Udell has an interesting session with Steve Burbeck (who's only apparent career blemish appears to be the design of UDDI 8^).

[Update: Steve explains his role with UDDI in a comment on this post.]

Burbeck's history goes back to that Tektronix Smalltalk community here in Portland that spawned Ward Cunningham, Kent Beck, Rebecca Wirfs-Brock, Gemstone Smalltalk, Digitalk Smalltalk, etc. The work Cunningham, Burbeck, and others did at Wyatt with a Smalltalk-based trading system is a gold mine of ideas barely tapped, yet more relevant than most enterprisey systems built since.

Someone could write a book on Tek Labs and the direct and indirect influence it had not just in popularizing Smalltalk, but design patterns, agile programming, etc. It's reach is far and wide and largely unrecognized.

Back to Burbeck... the current references are to his work on multi-cellular computing. Apoptosis is an increasingly recorgnized pattern, e.g. from the Erlang community the idea that small components should give up quickly and allow a higher-order component handle the fault.

Stigmergy is interesting... it's not really found in Erlang, except I guess it is in a sense what the Mnesia distributed database is for. It's also a key aspect of the Linda tuple spaces / Javaspaces model, and the idea of "blackboards" in artificial intelligence.

Linux Fest Northwest incl. Tim Bray

Linux Fest Northwest is on April 29 in Bellingham, WA. That's a beautiful part of the state in the north Cascades not too far from Vancouver, BC. Admission is free.

I hope I can make it up there. Tim Bray is scheduled to talk on things non-enterprisey...

"XML, Open Source, Complexity, Simplicity"

There are a number of other interesting presentations scheduled.

WWW2007 in the Canadian Rockies

Mark Baker is helping with WWW2007, which will be held in Banff. I will what I can to be there. The Canadian Rockies is in the Top 5 of my favorite locations in North America and I could use any excuse to go back there.

Oh, I'm sure the conference will be interesting too.

When *Everything* Is An Object

James Robertson explains how "the control stack" is just an object in Smalltalk, and what you can do with that. This is what enables systems like Seaside to be so simple for the application developer. Seaside grabs stacks, saves them, applies them again later, etc.

Due Recognition

Jon Udell gets some due recognition. Jon is an observant and curious (in a good way!) person, qualities I admire.

I recently met Jon and several other Infoworld people at their SOA Forum in San Francisco. They were all a fun group of folks, and I was fortunate to have some time to talk with them about all kinds of things beyond the industry.

WS .LT. CORBA

Andrew Townley provides very good evidence that WS-* is significantly *worse* than CORBA. He explains that CORBA (eventually) realized they need to specify the end-to-end world from language-specific API to interface description to protocol...

CORBA is... relevant here because it took the position of defining its own, end-to-end world: an interoperability-focused transport protocol in IIOP, interoperable operation interface specification in IDL and interoperable programming API specifications in the various language bindings. In all, it covered a lot of ground and was quite ambitious. However, I think the people behind CORBA knew that they wouldn’t really have portable distributed objects without specifying all of these things...

Unfortunately, it didn’t work as well as was hoped.

The majority of Andrew's post exposes a huge gap in the WS-* approach by comparing WS-* based reliable messaging to the Java Message Service API for reliable messaging, as well as to CORBA as quoted above. Specifically, the differences boild down this way:

• JMS provides an API for Java only, but not a wire protocol. (Interoperability across JMS implementations typically done by bridging API calls from one implementation to another.)
• CORBA provides an API for various languages and a protocol.
• WS-* provides a protocol but not an API. Each vendor is free to give their customers whatever proprietary API they desire, locking you into their API along the way. Isolating these dependencies is up to you, but this is not a problem the vendors are overly concerned with, and certainly not something they need you to be aware of.

Andrew provides code examples in Java using different vendor APIs to implement the same protocol.

The... 3 examples are supposed to all accomplish the same thing: reliable delivery of a message from point A to B, or in WSA-speak: between a requester agent and a provider agent. However, if you were the one implementing the service, or in our case, a simple Messaging Bridge between JMS and something else (maybe another JMS implementation), your code is intrinsically tied to the vendor implementation. Change vendors, change your code. You’ve just inverted the JMS interoperability problem and have interoperability without compatibility rather than compatible interoperability.

OOPSLA 2006 in Portland

I have not attended an OOPSLA in five years. But this year the conference returns to its original 1986 location: Portland, Oregon. This will be the third OOPSLA in Portland.

OSCON and OOPSLA both in Portland this year.

The day before OOPSLA will be the Dynamic Languages Symposium. (via Steve Dekorte)

It's Enterprisey!

Overnight this new term and meme has taken hold. Would that I were not familiar precisely with that that it implies.

It's enterprisey!

Update:

Bill de hÓra writes in lesscode that the term now has among other things, a wikipedia entry, and a wonderfully animated architectural illustration with its own theme music.

Da-da-da-da-dadadadada! It's enterprisey!

Paul James on REST/HTTP

I don't think I've seen these before. Paul James has a number of useful REST articles on his site.

I believe heavily in developing web applications using the KISS principles of "less is more".

One Method Too Few or Too Many?

Ethan Fremen writes in a lesscode comment...

The main way in which the additional verbs are really helpful in an application is whenever you want to manipulate multiple resources at once. Of course, in most cases where you’re doing that, you’re using even more of those ‘useless’ verbs, like MKCOL and PROPFIND etc.

To me it’s like you’re arguing that the only methods anyone ever needs on a class are gettr and settr methods.

I don't think the comparison with an object-oriented programming language is helpful. Classes with only getters and setters are brittle in their context (very small amount of state that changes often, very closely located to collaborating objects within a single OS process, one or a few developers working together modify most of those classes, short release cycles).

On the other hand with a distributed system it may be that the more methods in a system the more brittle in that context (very large amount of state that does not change often, very remotely collaborating systems across multiple network boundaries, many developers who know little if anything of each other, long release cycles)

A mechanism to "manipulate multiple resources at once" in the latter, distributed HTTP context may be to construct a resource that represents the collection of resources and then manipulate *that* resource using the smaller number of verbs.

The hurdle I've mostly climbed over to the level I currently understand REST, HTTP, URIs, Atom, etc. is that this is not an object system. This is an application protocol (and architecture, formats, etc.) for distant collaboration. The challenge is to understand what are the conceptual pieces in this system and how to map ones needs into this system.

Most of the heavy computational lifting of those resources *does* take place in object systems (or functional or...) where there is a rich processing vocabulary. The distributed part is just about moving representations around in a coordinated fashion to enable the heavy compuational lifting at the appropriate time and place. The architecture for one is most likely not going to serve the characteristics of the other. The more they are considered distinct the better.

That said, I cannot clearly articulate when to create a new method except that the resistence to adopting that new method will be great so the time spent thinking about how to use the existing methods will more likely be the time well spent.

My second articulation would be to suggest that if you want to create a new method or two, then probably so do I and so do several others reading this. Before long we would be drowing in a sea of new methods. There may be a Cambrian Explosion of new collaborative techniques if we focus on how better to combine the pieces we already have. Inventing another nucleotide should be a very high bar.

Update:

In another lesscode comment Paul James confirms this approach...

You don’t need new verbs to manipulate multiple resources at once, you just need another resource that represents all the resources you want to manipulate together and to then manipulate that with your existing verbs.

TSSTTCPW

Good news for Java programmers seeking the simplest SOAP stack that could possibly work...

I am back implementing Alpine. This has no dynamic redeploy, no ease of use features, no Java1.4 support, no annotations. It's going to be so simple I will have it working before I fly off to the Alps for my ski trip

The Coming Breakage: Minimize Dependencies

Steve Loughran writes about old binaries running (or not) on the next version of the Windows OS...

Now, making old apps work bad may finally create incentive for people to upgrade their office suite, but it will also break every single IT-written win32 app out there. That's serious, and going to become and ongoing issue, I suspect.

Fortunately, there is a workaround. Don't write Win32 binaries. Code in Java, Python, Ruby, Squeak or other interpreted language, and trust the runtime to be signed by the time vista ships. You sneak past the security problem without having to go to any effort, and you avoid being at all dependent upon the OS and any more delays.

If you want to take advantage of some specific OS, framework, library, or whatever... why would you not code the independent 80% part, well, independently? Writing software to your advantage is always about minimizing unnecessary dependencies.

$100

Don Box has a couple of interesting posts on Microsoft's support for REST/HTTP. I don't know a whole lot about the products, but there's a long list.

He asks a good question: how would you dole out $100 in support of REST/HTTP within Microsoft. Since I cannot really address specifics within their current product line, I'd consider something like this:

• $25 toward furthering their current investments in open REST technology, e.g. Atom and APP support in various systems and frameworks.
• $25 toward open RESTful "push" technology, e.g. XMPP and mod_pubsub.
• $25 toward a RESTful coordination technology above HTTP per se. Something like Rogue Wave's defunct Ruple XML tuple space, but using REST/HTTP. Deliver this as a live service (i.e. like Amazon's S3 but with somewhat richer associative memory than just keys or URLs (a URL is just a key, right?)) as well as a framework that others can deliver on their own systems and customize.
• $25 for better treatment of dynamic languages at Microsoft. I believe REST/HTTP/XMPP/etc. are to distributed systems generally as dynamic languages are to programming languages generally. To be fully RESTful I think you have to be as simple as possible and fully dynamic. Doing this will stimulate more RESTful ideas within Microsoft. I know they have a number of Ruby programmers... turn that amp to eleven.

LAMP on a Grid

Mark Baker writes...

Finally, the Web's getting its due.

Ok, so who wants to break the news to the Grid folk? 8-)

The most interesting vendor at the Infoworld Executive SOA Forum last week was ActiveGrid, a LAMP-based grid for various purposes.

The Same Old Place

Or was that the old Same place? Nevertheless...

I'd sure like to understand this claim and prediction from Eric Newcomer of Iona...

Now with customers deciding on the approach independently of technology, the roles are reversing. Customers are starting to tell vendors what kind of technology they need by creating their SOA based designs independently of their technology decisions.

This strikes me as a very good trend, and appropriate for where we are in the evolution of the software industry, helping to lead us to a place of resolution for the current frustrations with enterprise software.

I see a lot of people putting blind faith in WS-* because the industry has told them to. But then the industry says WS-* interop is not ready and there is no standard for a full service bus, so you have to make an investment in a specific vendor.

Same old story from what I can see. Anyone that wants an agile enterprise can get it using technology that is ten years old or more. There is *no* need to invest in WS-* or an ESB. I think an ESB could be a good investment in some cases but not because of any promise of a "standards-based platform".

Software Development *Is* Program Transformation

Let's celebrate another post from Ralph Johnson...

I do not say that program development *should* be program transformation, I claim that it already is. Most work on software is after the first released version. The purpose of work on existing software is to transform it to the new version. Since almost all work on software is converting version N to version N+1, almost all work on software is program transformation...

I do not claim that program transformations are easy, or that they can be automated, or even that we can always understand them. I am claiming that thinking of software development as program transformation is likely to lead to improvements in how we develop software.

BS-Transfer?

Mark Baker writes...

I'm calling bullshit on WS-Transfer. Please join me.

Favorite SOA Observation

My favorite observation from Infoworld's Executive SOA Forum last Thursday came from The VP of Enterprise Architecture at Sony Pictures Entertainment. Pointing out that SOA is nothing new, he had first encountered the idea in Tandem's shared nothing messaging capability. (pdf)

The same observation was made by Alan Kay in the 1960's about the Burroughs B5000 and contributed to his invention of Smalltalk. And then there's Erlang and other shared nothing systems.

You wanna make fourteen dollars the hard way? (WAV)

-Rodney Dangerfield, Caddyshack

But Will It Be Compelling?

James Robertson makes an observation that will please my 13 year old (a dyed in the wool Nintendo fanatic)...

Sony's release dates for the PS3 are starting to look like the planning for Longhorn

What is Success?

Tim Bray writes about WS-* vs. ReST/HTTP...

Speaking for myself, not for Sun, I think that we ought to be pouring resources and investment into tooling and developer support around simple XML/HTTP/REST technologies. You know, the standardized ones that work today.

Vendors have sunk a lot of time and money into SOAP and WSDL. Appearances are this effort has gone into easing the burden of programming with SOAP and WSDL. That should tell us something about their languages as well as something about SOAP and WSDL.

What's the result?

Adam Tratchenberg spoke about ebay's approach to versioning their numerous web services at Infoworld's SOA Executive Forum last Thursday. When asked how ebay performs compatibility tests across multiple languages and toolkits, his response was they test with Java, .Net, and PHP. My guess is they don't test with many of the Java toolkits. Perhaps they test with .Net's various toolkits because Windows many programmers are in various stages of adoption.

Anyone with an incompatible toolkit or language though is not left out in the cold... ebay provides an HTTP and POX interface for each method. Can ebay's approach be considered a success for SOAP and WSDL given this lack of universality?

What if the vendors sunk as much money into making HTTP and POX as convenient as they're trying to do with SOAP and WSDL?

Meanwhile at least the long march toward more compatibility in WS-* continues. I've not found a list of attendees to Microsoft's interop session. My sense is the list of languages and toolkits is fairly short (Indigo and Sun's Java toolkit. Others?)

Is this a barrier to entry that guarantees its ultimate demise?

Keep It Simple

mdavidx5 asks a great question in response to my post about Amazon's S3...

Why the fuck do people have to insist on complicating things?

Maybe it is the case that S3 is the simplest thing that could work. But I think there is something between S3 and the full-blown web hosting provider he's fearing.

The simple way S3 works is as an associative memory between keys and values. As long as you know which key to use, this is a great service. But what if you need to retrieve your data based on some contents?

The key / value pair approach of S3 is the degenerate case of associative memory. I don't think S3 has to be about anything more than storage, but there I think there will be some room for associative retrieval of some complexity beyond simple keys.

If the pipe was big enough then there would be no trouble bringing gigabytes over the pipe and doing the associative lookup remotely. Or one could store in S3 the data itself under one key and various indexes under another set of keys. That's clunky but I can imagine someone trying it.

mdavidx5's point is well taken though. Keep it simple.

Storage Paradigms

Stephen Williams writes in the FoRK email list on an exchange about Amazon's new storage service...

I firmly believe that both full filesystem semantics and ACID integrity constraints are red herrings and have seen a number projects reach the same conclusion...

With database-based applications, even when you have ACID capabilities, there are a number of reasons to avoid updates, avoid "accumulators", and otherwise avoid many of the situations where you needed transactions to begin with.

Having worked on and with very complicated object-oriented databases, very complicated relational databases, and other approached, I've noodled for some time on the possibilty that there are three basic persistence patterns that can meet a ton of needs.

I will be interested to learn if Amazon has now or will offer some higher-level services on their storage service. Search, matching, versioning, etc. I see they want to keep it simple, and I agree with that. Before long though people will want to do things with their storage. Some of those things will be better done very close to the data itself.

I wonder if/when we'll see the ability to put computations very near Amazon's storage (including indexes, calculations, searches, etc.) that are aware of the format of the stored data, that is secure, etc. Storage is just the most basic start of a shared grid of services.

First Class Nonsense

A problem with our industry (is it more than ours?) is the loose use of terms that truly have a formal definition. What is the meaning of this claim?

In contrast to standard distribution middleware such as CORBA or Java RMI, an SOA implements processes as first-class entities.

This is on page 58 of the March/April IEEE Software magazine (pdf). I wonder if the editors have any more sense of how wrong this is than the authors?

First of all, SOA has no formal definition. Secondly, in any common use of the term SOA, there is nothing resembling a process, let alone a first-class process.

Smalltalk has something close to first-class processes. Kali Scheme, yes, even distributed first-class processes. Termite Scheme, uh-huh.

SOA is so far from having anything resembling first-class processes that such a claim in an institutional publication is incredibly disheartening. In 2006 our programming languages *should* have first-class processes.

A Little Rest Here and There

Mark Baker points to a really interesting application of REST to dynamic networks of small devices.

The primary mean of abstraction within pREST is a resource. Virtually anything that can be uniquely addressed with a URL is a resource: devices, services, and configurations as well as documents, pictures, and raw data. Resources can be nested, so that services and properties of a component being associated with URL are resources themselves.

Bay Area Adventures

I will be at the SEM SIG meeting tomorrow night in Palo Alto to hear Mary Poppendieck talk about Lean Software Development (see quote below). Then Thursday I'll be at the Infoworld SOA conference in San Francisco.

Jon Udell, Phil Windley, and others will be at the conference, which should be worth the price of admission alone. Well, I got a free pass. So worth *more* than the price of admission!

I will be looking for entries to put on the ws-success wiki. The agenda looks good -- not just vendor fluff.

From Mary's abstract on Lean Software Development...

Lean Strategies for Software Development Leaders What do PatientKeeper, a hospital data management system, and Zara, a high fashion clothing chain, have in common with Dell Computer and Toyota Motor Corporation? All four companies are overwhelming their competition with a constant flood of new products that seem to be exactly what customers want, even as they set the standard for quality and value. How do they do it? To these companies, Lean Thinking is a way of life: Customer Value, Rapid Response, Constant Learning, Built-in Quality and Engaged Workers are part of the culture.

Open Source and/or Standards

Jon Udell, et al. wonder about the value of open source and/or standards.

I would hesitate to adopt any standard that does not already have a up-to-date open source implementation. And I would refuse to define a standard without concurrently defining an open source implementation.

I've been involved in two standards definition processes. Neither had any significant implementation or formal model to guide them. I suspect other standardization efforts have suffered similar consequences.

Mistakes were made.

Bonne Chance

From Ajaxian...

Will Microsoft buy DabbleDB as they realise that it is what Office Live should be?

Jini and Javaspaces -- Distributed Systems Secret Sauce?

From the SOA Yahoo group, Greg Wonderly writes about Jini and Javaspaces...

One of the primary issues we have in the Jini community, at large, is that the Sun Jini team has commented in private that there are many different users of Jini which do not wish to have public recognition. Some developers have told me that Jini provided such an large, positive impact on the development and systems, for such a small investment, that they consider it a competative advantage that they don't want to talk about. I.e. it was so cheap and easy to use that their competitors would be able to be on par with them quickly.

ws-success

I have created a wiki, http://ws-success.pbwiki.com, for capturing and refining success stories about implementing distributed systems with technologies that follow ws-* standards (SOAP, WSDL, etc.)

Please feel encouraged to capture your success stories there or contribute to the stories that may already be there by adding your experience with an existing story, technology, or standard that may be part of that success.

Feel free to leave questions about the stories too, but please respect the content that may already be in place. Don't edit someone else's story unless you are contributing to a faithful rendering of a common experience.

Follow the changes with the RSS feed or the Atom feed.

Fun (and Learning) with SVG

Firefox 1.5 now supports SVG, if you've not heard the news. You can see this in action on a fun learning page about orbits and how our moon may have been created.

Next Move in Programming

Dave Thomas (the Smalltalk Dave Thomas) writes in JOT...

We need to move beyond the complexity, limitations and weaknesses of Smalltalk and Lisp but seek a language with at least as simple a syntax and more expressiveness.

Here's a programming leader who knows his stuff and I love the fact that he refers to Smalltalk and Lisp as being complex, and having limitations and weaknesses. These are not the be-all and end-all even though they are better than anything that's come along since their invention 35-45 years ago. Noodle on that: 35-45 years without a significant leap forward in programming languages.

Maybe we'll go another 100 years without that improvement. Maybe that is to be expected.

ws-success

I have created a wiki, http://ws-success.pbwiki.com, for capturing and refining success stories about implementing distributed systems with technologies that follow ws-* standards (SOAP, WSDL, etc.)

Please feel encouraged to capture your success stories there or contribute to the stories that may already be there by adding your experience with an existing story, technology, or standard that may be part of that success.

Feel free to leave questions about the stories too, but please respect the content that may already be in place. Don't edit someone else's story unless you are contributing to a faithful rendering of a common experience.

Follow the changes with the RSS feed or the Atom feed.

Get to the Point: Open Source Speech to Text

Update: Jon Udell happened to know where to find the information I was listening for. And created the excerpt.

Lisa describes how to use WebDAV to lock events, multiple events, access control, etc. Then she explains that a narrow number of features are needed specifically for calendering, e.g. how to query free/busy information on someone's calendar.

I sure wish I knew whether Lisa thinks we need a DAV extension for every kind of resource. Assuming not, why are calendars special? I think we need *conventions* for using HTTP per se to do versioning, locking, accessing, calendaring. I certainly hope we don't need extensions for every kind of resource. Oops. Isn't that like SOAP?

End Update

I am listening to a podcast, something I have done only a couple of times because I would much rather read than listen. In this case it is IT Conversations with Lisa Dusseault on calendering, CalDAV, and WebDAV.

What I most want is to know whether the question comes up as to why WebDAV and CalDAV are necessary. The logical conclusion of this approach is every resource on the web has its own application protocol... PurchaseOrderDAV, MovieDAV, ShinyObjectDAV, etc.

I don't have the time to listen to 30 minutes of conversation to see if this comes up. So I am on the lookout for a relatively easy to use and free or open source speech to text conversions.

Stasis

Alan Kay paraphrased by Phil Windley...

The future five years out is easy to predict because all of the forces acting on computer science are trying to keep it the same as it is now...

Architecture demands arches...

[People's] stories are inconsistent with what they know, yet they persist in believing them, even though they have the knowledge that contradicts their theory.

When people react instantly, they’re not thinking, they’re doing a table lookup...

To do creative work in computing, you must get past what you think is normal. Write down the 20 things you think are true of computing and try to demolish them...

Most people who graduate with CS degrees don’t understand the significance of Lisp. Lisp is the most important idea in computer science. Alan’s breakthrough in object oriented programming, wasn’t objects, it was the realizing the the Lisp metasystem was what we needed...

Barton taught me “The basic principle of recursive design is making the parts as powerful as the whole.” These ideas led me to an insight on November 11, 1966: the timesharing people got it right with processes, but it was too big.

Wonderfully Empty

In my house there is a cave
And in the cave is nothing at all
Pure and wonderfully empty
Resplendent, with a light like the sun.

- Han shan

Daily Zen

Pig Pile

Bill de hÓra writes (but I transposed it into a question)...

...where could [you] point to a solution and say WS-* was critical to success[?]

And then more...

As for XSD it just does not seem to be helpful. I think that has to do with not only XSD being complicated (due to a requirements creep toward genericity that resulted in something of a monster spec). It's also quite low-level, and in practical terms tends to expose a platform's type system, which is invariably implementation specific. Which is to say there's an encapsulation problem when using XSD - too much how, not enough what. It would be cleaner to expose domain level structures like "Customer" that obey a RELAX or RDF schema...

There is one nice feature about the REST or XML-over-HTTP approach - you can definitely scale down. Scaling down is important because if you can't scale down you presumably have to start big, which is risky for any project, unless you believe big working systems derive form big working systems...

XMPP rocks. Publicly the fuss around XMPP will be in the commercial sector - about Google Talk and Voice Over IM. I think it could quietly become the "other" protocol for the get-it-done school of systems integrations, mainly in situations where push or timeliness is a serious need, and people are talking crazy talk, like long haul JMS integrations.

This is Enterprise Stuff. Look Out

A comment on Bill de hÓra's blog from Mike Champion continues the theme of wizards hiding complexity reining supreme...

...the paying customers in my world DEMAND that intellisense and databinding stuff that people in the web geek world think is gratuitous fluff.

Intellisense and code generation is an isolated developer trick for hiding real complexity and risk. This has nothing to do with architecture, maintainability, interoperability, etc.

If that is the reason for choosing SOAP/WSDL then... it really is over.

It also remains to be seen whether RELAX NG, RDF Schema, etc. are also just simpler tools for simpler jobs than XSD, or really do more with less. I'd be extremely happy to be proven wrong that XSD is a necessary evil!

Yes, why list actual reasons why XSD is good when you can just claim the top of the hill and dare people to knock you off. I think you might fall down on your own.

Customer-Driven Design or Not

Scott Bellware writes in the Test-Driven Development Yahoo group...

Sweet mother of God! MS TDD® is back! :)

I recently got an update on the revision to the Guidelines for Test- Driven Development article on MSDN. An actual TDD practitioner was tapped to write the second rev of the article. I learned that the product folks weren't overly pleased with a more accurate depiction of TDD as it didn't promote the VSTS testing features that they had worked so hard on.

That'll learn 'em. Or not.

If it keeps on raining...

The levee is going to break. Steve Loughran contributes more to the discussion I was hoping to see. I would like to see some constructive counter-arguments. Where are they?

Let it not be said that I critique SOAP/WSDL and the like for ideological grounds. I critique it because I have to use it, and it sucks...

One of the key features is that its easy to debug HTTP problems: point a web page at the same URL, and see what you get back. Work with SOAP, and you are doing tracelogs...

We cannot reliably send an xsd:dateTime between two endpoints on the same machine without its timezone getting confused, attachments are something you need to negotiate on, and nobody even understands why xsd:nil actually exists, since its a way of declaring inline "I choose to break this bits of the public schema, get over it"...

In REST-land, few people work with XSD, even less try to seamlessly map from the schema to native types, and nobody expects the runtime to infer a REST state model from implementation classes. Yet despite the lack of all this integration, REST appears to work better...

Just as Hibernate killed EJB-classic, so can lightweight protocols kill WS-*...

Use XMPP as the back channel. Not WS-Eventing, or WS-Notification. Or let people poll. It actually works quite well when the number of polling clients is very low, as it probably is for most communications between two nodes, and it works around the whole firewall problem...

...kill WS-Addressing. WS-A is the recurring bane of my life. People ask me why, and I have to point them at code that tries to move data to and from the various versions of wsa:epr on the wire. URLs, that's all you should need. If you want async two-way comms, then give a URL for responses; an xmpp: one for xmpp responses...

Bad Idea

Robert Sayre makes the point that it really is over after all...

With the benefit of hindsight, we can see it was a bad idea to try and abstract away application protocols using RPC calls tied to verbose, rigid, statically-typed languages mapped with a Rube Goldberg schema language that has a more flexible type system than said languages...

If you have Microsoft saying "well, the best approach is to make this elaborate infrastructure we've spent billions of dollars building out optional", then the debate is over.

Update: More about this bad idea. First, Tim Bray writes about either WS-angst or WS-flurry or both...

I think the WS-stench of something WS-rotting from the WS-head down is becoming increasingly difficult to ignore.

OK, not much information there but a telling satire on the WS-mess. But Dare Obasanjo informs us...

The main problem with WS-* interop is that vendors decided to treat it as a distributed object programming technology but based it on a data typing language (i.e. XSD) which does not map at all well with traditional object oriented programming languages. On the other hand, if you look at other XML-Web-Services-as distributed-objects technology like XML-RPC, you don't see as many issues. This is because XML-RPC was meant to map cleanly to traditional object oriented programming languages.

I think this has a ring of truth. XML-RPC for all its flaws is fairly modest and easy to implement. The data model is not unlike JSON, again really modest and easy to implement. JSON is even better because it is just a data representation and can just use plain HTTP.

Truth

"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth."

-Umberto Eco

History

"Human history becomes more and more a race between education and catastrophe."

-H.G. Wells

Merit

"In science, 'fact' can only mean 'confirmed to such a degree that it would be perverse to withhold provisional assent.' I suppose that apples might start to rise tomorrow, but the possibility does not merit equal time in physics classrooms."

-Stephen Jay Gould

Don't Make Me Think

"Don't Make Me Think" may be a fine motto for user interface design. Unfortunately, this seems to be the preference of developers promoting the SOAP/WSDL/IDE approach. As Mark Baker points out, the result is not an architecture based on principles. The choice appears to be driven by convenience. A C# or java programmer can point and click their way to non-interoperable code generation almost without thinking.

Look around the net for the architecture principles for SOAP/WSDL. Then look around for HTTP/POX. It's like night and day. Maybe an architecture isn't required if all you need to do is point and click within a single IDE and toolkit.

From what I can tell the problem with interop is:

• The SOAP/WSDL solution space is big, far bigger than HTTP.
• Each vendor seems to be in it for their own benefit rather than the benefit of the whole.

There is no way the web could work under those conditions and it appears the WS-* world is not working well under those conditions. Vendors might have trouble differentiating themselves under simpler conditions though. The HTTP advocates are essentially saying an open source system like Apache, or simpler still, is sufficient. The vendors are between a rock and a hard place.

Simple dynamic programming languages and simple dynamic coordination languages are winning. Vendors will have to differentiate themselves on something more than wizards that mask complexity.

The China Syndrome

For some reason the search engine business is not supposed to profit from China's poor support for human rights. Meanwhile the rest of us are able to do business under their current conditions in the name of "democratizing" their country.

Right.

Java and SOAP/WSDL

Philippe Mougin writes in a comment on Don Box's blog...

I'm quite surprised by Don Box's comment about SOAP/WSDL providing a great experience to Java folks. JAX-RPC (the standard Java API for using SOAP and WSDL) is known to be a terrible API...

Several years ago I used a fairly nice SOAP toolkit called Glue. I recently worked with SOAP again for the first time since then. This time around we tried Glue, Axis2, and another based on JAX. Glue remains by far the nicest and yet still presented problems with interoperability even among Java toolkits as well as various dotnet toolkits.

Web Methods owns Glue now. I don't know how well they've incorporated Glue into the rest of their products. They seem to bury Glue per se deeply in their web site for some reason.

Dyanamic Languages, Part L

Lisp implementations are nearly 50 years old! The ideas go back publicly 50 years to John McCarthy's participation in the Dartmouth AI project in 1956. By 1960, McCarthy had reported publicly on his team's implementation experience.

Here is a two-line status report on dynamic languages 50 years later, quoting from another blog in another debate...

• If you want a great experience for .NET/Java devs, you’ll typically publish schemas (through wsdl) and support SOAP.
• If you want a great experience for LAMP folks, you’ll support POX messages and will provide a non-XSD description of your formats.

And so I would summarize the status of dynamic languages like this: they are mainstream, they are everywhere, and they are so misunderstood.

Update: Phil Windley has some recent items on Lisp.

REST and SOAP

Don Box on REST vs. SOAP...

In hopes I never have to address this debate again...

The debate seems just to be getting started and has a long way to go. I hope Microsoft has not made up their minds yet.

The following design decisions are orthogonal, even though people often conflate two or more of them...

1. Whether one uses SOAP or POX (plain-old-XML).
2. Whether or not one publishes an XML schema for their formats.
3. Whether or not one generates static language bindings from an XML schema.
4. The degree to which one relies on HTTP-specific features. That stated, screw with GET at your peril.
5. Whether one adopts a message-centric design approach or a resource-centric design approach.

Some of the decisions (specifically 5) are architectural and sometimes philosophical.

What does "philisophical" mean? Does "philisophical" mean "does not count"?

Some of the decisions (specifically 1-2) are simple business decisions that are determined by who your target audience is.

What does "simple business decision" mean? (Let's ignore the "simple" part and just consider "business".) I can understand the decisions could have a value and a cost associated with them. But which ones would not?

1. If you want a great experience for .NET/Java devs, you’ll typically publish schemas (through wsdl) and support SOAP.
2. If you want a great experience for LAMP folks, you’ll support POX messages and will provide a non-XSD description of your formats.
3. If you want to reach both audiences, you’ll do both #1 and #2.
4. If you want to reach both audiences before your competition does, you'll avoid indulging in religious debates and ship something.

Starting with (1), what does "great experience" mean? Great *initial* experience? And does that slash mean dotnet *or* java? Or does it mean dotnet *and* java together?

My recent experience (in which I was shocked how little interoperability, not to mention functionality, has been accomplished in the WSDL and SOAP world over the last several years) tells me that if the target is either dotnet *or* java then your chances are significantly better than targetting both. (But then if separate, the questions becomes again *why* WSDL and SOAP when a proprietary solution could do better still.

Doing (3) seems like a lot of work when perhaps (2) would work well for all. Again my recent experience supports that. I think (1) works for vendors whose tools have been aimed at (1) but only *initially*. What little experience I have in this area has even so raised huge warning flags that the initial joy of a dotnet or java SOAP and WSDL toolkit very soon runs out of gas (i.e. I have not seen quantifiable benefits for choosing WSDL and SOAP over real HTTP), yet introduces problems of its own (complexity, lack of interop, little support for versioning, magic instead of repeatability, little in the way of testability).

That last one about shipping something is interesting. In a recent experiment a small group and I found ourselves wrestling a lot with WSDL and SOAP (this was a dotnet *and* java experiment rather than a dotnet *or* java experiment). Wanting to quickly put that behind us, we decided to run a different experiment... address the same business problem but with just HTTP. Very soon we were spending all our time talking about business functionality and messages rather than infrastructure headaches.

And yes, we could have at that time very easily thrown in LAMP, Lisp, Smalltalk, Erlang, etc. Anything that can do simple HTTP could be a full participant. The interfaces were narrowed and became a non-issue. The messages and the funcationality became the concern -- what is the business functionality? what is the message description? (We used xsd's and so I can attest to the above statement about schemas being independent of SOAP, WSDL, etc.)

Mark Baker has additional useful comments and pointers to other recent items (here and here for example) about this debate. To repeat myself, this seems far from over, and neither should it be. There is a lot more to discuss. The lists above from Don seem oversimplified. From his accompanying text, he seems too eager to conclude with this list and live by it. I don't see how that would help anyone.

Update: Mike Champion makes an analogy between messaging technologies (SOAP/WSDL and HTTP) and road vehicle types (trucks and cars). Unfortunately this is an arbitrary analogy. That is, saying that SOAP/WSDL is best "to haul a lot of heavy stuff securely and reliably, use a truck" does not make it so. The question is how to make an objective determination.

Update Day 3: As Chris Ferris says, the saga continues. Chris plays the "if only you knew what I know" card. That could be a good card to play, as I am only reporting what little I know. That is not much, but at least it is based on hands-on experiments.

But Chris appears to advocate SOAP/WSDL over HTTP on the basis of reliable messaging. Here's my (limited) experience... several popular SOAP/WSDL toolkits fail to easily interop over HTTP using unreliable messaging. Should I come back in a few years to see where they stand on reliable messaging? Chris admits...

I will concede that it is taking longer than I might like to drive the WS-* specifications through the standards process.

Yet the standards that are in place already seem open to arbitrarily incompatible interpretations. And the toolkits I have seen appear to do the darnedest things to generate complicated code and require programmers to jump through obscure hoops without a net.

Chris -- promises of paradise sometime in the future may come true, but I don't see that as a reason to invest in the mess we're forced to deal with today.

Stefan Tilkov writes...

If you’re talking about SOA at an enterprise level... whether you end up doing POX over HTTP in a RESTful or unRESTful way, or use WSDL and SOAP with a code-first or contract-first approach, is not the sort of thing that matters...

But he seems to agree there is a significant technical debate. I'm not sure I agree the technical debate does not matter at the enterprise level. The most significant enterprise IT issue I am aware of is the inability to get out from under undesirable technical legacies. My fear is the current SOAP/WSDL, etc. conglomeration is not a wedge for loosening older legacies, but could turn out to be its own significant layer of cruft that drains more resources from focusing on pure business value.

On reliability, security, etc. within the enterprise, Mike Champion in a comment on his blog writes...

Typical enterprise IT shops tend see the Web as a necessary evil to communicate with customers, and must invest heavily in tools and expertise to get acceptable security / reliability; they generally use databases or enterprise message oriented middleware (e.g. MQ) to handle internal communications securely and reliably.

And I agree with this observation. I can see a place within the enterprise for HTTP as well as for some other API or protocol-based database and messaging systems. I don't see HTTP as being the only protocol, especially within an enterprise. However I don't see SOAP/WSDL at *this* point adding value to any of these. Experience shows they are complicated, vague, and underdeveloped (relative to what the adopted and in-progress specifications might lead you to believe.)

Each has their place... but where? Kurt Cagle adds to the discussion. He makes a statement I have heard before, "both have their place". I don't recall seeing useful information about where these appropriate places are for SOAP/WSDL. Some people think they belong between enterprises. Others believe they belong within an enterprise. Kurt appears to uphold the latter at least in part, but I am not sure.

My sense from limited hands-on experience is that the more one's interfaces depend on SOAP and WSDL the more difficult they will be to change. I would be interested in contrary experiences. The last thing an IT shop needs is more cruft that is difficult to change.

Update Day 4: Dare Obasanjo makes constructive observations until he falls back to the apparently default advice...

If you know the target platform of the consumers of your service is going to be .NET or some other platform with rich WS-* support then you should use SOAP/WSDL/WS-*. On the other hand, if you can't guarantee the target platform of your customers then you should build a Plain Old XML over HTTP (POX/HTTP) or REST web service.

Again the "rich" support appears to hold if one does not care about interop. But then the question is, why use SOAP/WSDL for a non-interop scenario? Certainly there are better solutions when confined to just C# or java.

Concurrency-Oriented Programming

Peter Williams needs a look at Erlang and its take on Concurrency-Oriented Programming (pdf slides, pdf paper)...

My gut tells me that none of the approaches I know for apparent concurrency are going to work well for a highly concurrent application on highly concurrent hardware. If that is the case we will see something new and different as soon as the cool hardware gets into circulation. (via James Robertson)

On the other hand I don't see everyone cutting rope and heading over to Erlang. Probably some languages will evolve concurrency mechanisms. Those that are able to evolve most easily will be the simpler dynamic languages like Lisp, Smalltalk, Python, and Ruby.

On the way I would expect simpler extralingual concurrency mechanisms to gain popularity, e.g. JavaSpaces, esp. in the form of cross-language tuple spaces.

Where We Stand

From SDForum via xmlgrrl...

Harold: Web services is where we would have been 10 years ago if MSFT had joined OMG.

Andrew: You’re giving us too much credit.

Oh, was that a compliment?

Structured Speech

Given that I have listened to no more than three podcasts and have found no more than one useful, I would have to agree with Werner Vogels' desire for more navigational structure.

I believe my main problem with the format is you are supposed to use it linearly. I love to read articles, papers, books, etc., but I am often a non-linear reader. I will scan back and forth for interesting pieces. The fact that you cannot build a hierarchical model of a podcast for selective drill down is pretty annoying to me...

It is not that I want everything written down... I believe more structure would be absolutely helpful.

I would probably pay more attention to podcasts if they were written down. 8^(

The Secret

Blaine knows the secret...

Accidental architectures arise from information exposure. Knowing what to expose and what to hide takes thought and planning in design. It just doesn't happen.

This applies not just to an isolated software application. This applies to an entire enterprise information system. Eliminating unnecessary dependencies among components is the key to managable evolution of software systems.

Abstracting Over Time

Motz writes about a recent talk by Richard Gabriel, including better abstractions for time...

there is nothing like abstracting over time (mp3) which leads to a system that - compared with the real world - would mean that "if you go to the beach, you would need a place in your brain that let you remember that you went to the beach".

Faith and Reason

Sam Harris, author of "The End of Faith", from a talk on CSPAN...

"In the west we are standing on the shoulders of dwarves, contemplatively speaking."

From his web site...

Harris argues that in the presence of weapons of mass destruction, we can no longer expect to survive our religious differences indefinitely. Most controversially, he maintains that “moderation” in religion poses considerable dangers of its own: as the accommodation we have made to religious faith in our society now blinds us to the role that faith plays in perpetuating human conflict. While warning against the encroachment of organized religion into world politics, Harris draws on insights from neuroscience, philosophy, and Eastern mysticism in an attempt to provide a truly modern foundation for our ethics and our search for spiritual experience.

Linux and Windows (and Mac OSX)

Here's a funny report on Linux from Microsoft. Not funny "ha-ha" but funny "sad".

First of all I did not even have to read the report to laugh, or cry as it were.

I have a couple of computers that are about 5 years old. They are set up for dual boot to either Windows or Linux. The only facts I need to know about them are these: I can run the latest Linux on them. Every time there has been a new version that I wanted, I was able to upgrade with no problem.

On the Windows side, I am still running Windows 2000. I am unable to get XP running on them. Oh, maybe someone will respond with a statement like, "All you have to do is X." But any value of "X" that I have run into appears to be at best an unknown amount of time and possibly money.

Let me say right now, I'd like to run XP on them just because the other Windows systems I have around do run XP. I could not tell you the reason why XP is better than 2000 other than there are probably some significant security differences. I am actually fine running Windows 2000 when I need them to run Windows at all, which just further makes the point of incompatibility absurd. Did they really screw up Windows NT and then Windows 2000 so much that a significantly incompatible rewrite of the OS was required? Or just an opportunity for more revenue?

I can also run Apple's latest Mac OSX on my six year old Macintosh very well. I have all the facts I need. I have no expectations that anything will get better over the next few years with "Vista". Apparently Microsoft is only looking forward to getting more revenue and not looking at the real value for the customer. To date, that has worked out well for them because they either don't have as bad a reputation as I think they deserve, or they don't have a customer base that cares about bad reputations. And that's a pretty darn big customer base, so I would have to go with what works if I were them, too. Will it catch up at some point? I think it has to, but I have never been successful at predicting these things.

Constant Flow of Ice Cream In

I am watching this Microsoft video to find out what The Roches have to do with sound on Windows Vista. It turns out they have Robert Fripp doing some sounds and in the recording evokes some essence of his work with The Roches. I saw the Roches perform at the Berkeley School of Music in Boston in 1985 (around the time Another World was released).

They are three amazing sisters for getting all kinds of harmonies into their music. (If you have not heard them perform the Hallelujah Chorus, well.) I was looking forward to some harmonies on the Windows Vista OS. Oh, well.

It turns out The Roches web site has a *lot* of video from Soundstage, SNL, the Late Show, etc. I leave you with some favorites of mine...

• Love to See You
• Mr. Sellack (it is good to see Johnny Carson again)
• Another World (I don't feel that great today, there's got to be another world, oh yeah, ooh ooh ooh baby)
• The Largest Elizabeth in the World
• I can't stop watching their videos...
• Married Men
• Keep On Doing/Jerks On the Loose
• The Hammond Song
• And not on their site, unfortunately, their spectacular version of...
• On The Road To Fairfax County (Real Audio) (or Windows Media)
• I Fell In Love (Windows Media) (listen to the following lyrics in three-part harmony... "You're a slick, affected, switchblade-flashing, motorcycle freak... You walk that mean and tough-guy walk of all the other guys who hang around...")
• The haunting "The Scorpion Lament (Windows Media)" and "I'm Losing You (Windows Media)"

Why don't you listen to my little pep talk? Come in off the ledge.

RSS as an Operating System Component?

This is a sign of sure doom.

Problem is, I don't know whose doom it is a sign of.

Have you seen this man?

Wondering if this post will land me on the "no fly" list, I now relay a funny story. Not funny as in "ha-ha" but funny as in "that's funny. hmm."...

The author of a critical biography of Karl Rove ended up on a no-fly list. James Moore, an Emmy-award winning journalist and author of Bush's Brain was recently barred from boarding a flight from Texas to Ohio.

An airline employee gave Moore an 800 number to check on his no fly status. Moore posted this excerpt from their conversation at the Huffington Post:

"Mam, I'd like to know how I got on the No Fly Watch List."

"I'm not really authorized to tell you that, sir," she explained after taking down my social security and Texas driver's license numbers.

"What can you tell me?"

"All I can tell you is that there is something in your background that in some way is similar to someone they are looking for."

"Well, let me get this straight then," I said. "Our government is looking for a guy who may have a mundane Anglo name, who pays tens of thousands of dollars every year in taxes, has never been arrested or even late on a credit card payment, is more uninteresting than a Tupperware party, and cries after the first two notes of the national anthem? We need to find this guy. He sounds dangerous to me."

"I'm sorry, sir, I've already told you everything I can."

"Oh, wait," I said. "One last thing: this guy they are looking for? Did he write books critical of the Bush administration, too?"

Haskell and Erlang

Joel Reymont has an interesting experience report from using Haskell and Erlang. He also has an article published on "Writing Low-Pain Massively Scalable Multiplayer Servers".

Windows Switcher -- I'd Love to Switch, Oh, Yes!

Wow, a Three-Dee view of windows to allow me to switch among them. How... well, oh boy.

Microsoft, do you know what I would really like? I spent an hour or so putting drawings in a Word document. They looked fine yesterday. But today I opened up the document and all the drawings are squished. Expanding the drawing area does not also expand the drawings. Big area, squished objects.

Maybe by sometime in 2006 you'd think Word could embed a drawing and retain the layout correctly?

May Apple, Google, or whoever, run over you with a steam roller... as long as they provide a document processor that actually works.

Microformat => Microprotocol?

I just did a search for "microprotocol" and was surprised I did not find what I expected. Well, I found a couple of citations related to Atom from Bill de hÓra's site.

Shouldn't there be as much attention paid to microprotocols as to microformats? Or nearly so. I understand HTTP GET can be used to provide an XHTML document with multiple embedded instances of microformats. I understand Atom Publishing Protocol can be used to provide even more functionality with other HTTP verbs.

But what about WebDAV and CalDAV? These are fairly complex application protocols with out a clear purpose from what I can tell. Shouldn't this functionality be provided by more conventions on HTTP and APP? Right? The nice thing about microformats is they do not extend XHTML, just tell you ways to use it. The nice thing about APP is it does not extend HTTP, just tell you a way to use it.

To get beyond mere APP, would you want to extend HTTP like WebDAV and CalDAV? Why?

Am I missing where people are discussing ways to *use* HTTP (as opposed to extend it) for calendaring and other microprotocols? Otherwise how many protocols do we think we need? Is 2006 the year for microprotocols?

Glitter on the Highway

Happy New Year, drive carefully...

Hop in my Chrysler, it's as big as a whale and it's about to set sail!
I got me a car, it seats about 20
So hurry up and bring your jukebox money...
Can't move. Resting...
Huggin' and a kissin', dancin' and a lovin' at the love shack

A (young) driver (without a license) in a borrowed car (without insurance) smacked into my car yesterday. He tried crossing two lanes of traffic from a side street and did not make it.

He hit my left front fender. If I was a few more feet into the intersection he would have hit my door. I bumped my head a little bit, but neither of us had significant injuries. Another good thing.

Drive carefully out there, and have fun.

Type Pecked

Brian Foote used the term "type-pecked [languages] like C++ and... Java". I had not heard that before. And so I chuckled.

An Acronym With Meaning

My vote for best acronym in the SOA world...

WSOL

SCA: EJB Redux?

Steve Loughran writes...

A component architecture from a group of vendors including IBM, Oracle and BEA. The last time I saw one of those it was called Enterprise Java Beans... I am so excited I could lie down

I was a participant early (pre-1.0) in that process. It was *truly* frightening. Literally a Jeckyll and Hide experience. I would say a "ping-pong" experience as the spec bounced around, but more scary.

Following the Rest of You

Mark Baker, Jeff Schneider, and others are going around on the WS / Rest debate. (Hey, has there been a live debate on this anywhere? Saved to the web?)

Mark says WS is unnecessary, that HTTP will do. Jeff says, yes but all kinds of things will do. It seems to me in this argument, Jeff should get down to one selection or at least begin to lay out his criteria for when to choose one or another. But...

The funny thing is, I'm a REST fan - I just can't stomach this one-sided bullshit.

But if Jeff is a REST fan then *when* is he a REST fan and when not? Jeff thinks Mark's stance is BS, but Mark is consistently towing the line on his choice. Exactly how does Jeff propose choosing one or another approach in any given setting?

As for my own semi-informed, partially-formed opinion, aren't the constraints of REST in the form of HTTP providing a more *broad* set of capabilities? i.e. an HTTP-based resource-representation-centric approach can be used by all systems that understand that architecture, which includes all the software written for the web already. (That's pretty substantial. 8^)

However if you take some other approach, say WS, then which WS standards do various vendors support? Big problem from what I can see. Then suppose you want to leverage all that existing web stuff. So you have a WS to get some resource in some representation and you want the representation to include a form that will POST requests to update the resource. From what I can see you still need to implement the REST model using HTTP anyway to do this. So why the WS?

So is the question just this: is the representational state transfer approach going to form the core of your architecture or not? If so, use REST. If not, then *what* will your architecture be?

For some situations I could see adopting some other architecture in conjunction with REST. Within some boundary, say an internal set of IT data centers, I could see using various architectural approaches that are more along the lines of what you put *behind* the REST-ful applications. Here you need a request dispatching and approval architecture, a caching architecture, a query architecture, a systems management architecture, and so on.

When I listen to vendors talking about Enterprise Service Busses this is what I think I am hearing -- how do you implement the data center itself? GET should be fairly ubiquitous. Then there would uses of POST, PUT, DELETE, etc. but maybe not so ubiquitously. i.e. eventually there are databases of various kinds: relational databases, file systems, and tuple spaces may form the core, if not completely in their current form.

There are two architectural questions it seems to me -- what do you present as an abstract programming model? And what do you use to implement that model? I am not sure there are enough constraints around a general WSDL model. More constraints are needed to guide the specific model. What do you think they should be?

RDF, REA, MRAM, etc.

On the topic of representing persistent formats for RDF, I came across another favorite paper from some years ago. Reading through this paper in 2005 (Adaptive Framework for the REA Model), there would appear to be some correspondence between RDF triples and REA, which also has a kind of "triple" model: Resources, Events, and Agents. I can't say what that correspondence is except at my superficial level of understanding of either.

The paper's approach to incremental computation results in a kind of graph model that would correspond to a graph of RDF triples representing the same information. i.e. I think RDF could be used in a straightforward manner to represent the fine-grained elements of REA models. Both models have some scenarios where connected graphs would be useful and this paper points out one of them... incremental computation, esp. for aggregating information and computing results not represented directly in the model itself.

This is an interesting approach and I wonder if the authors or others have pursued it since 1998. (Aside: the creative approach is yet another to come out of the Smalltalk community, in particular Ralph Johnson and his U.Illinois squadron.) So if you are not familiar with the history of ideas that have streamed out of the Lisp and Smalltalk communities, start your search now because the list is long.

Also -- this would seem to be an interesting solution for throwing hardware at a problem rather than the typical way low level engineering of computation. (Disclaimer -- I work for a hardware vendor, so you might conclude I have a personal interest in this approach. Actually I am generally interested in simple software approaches that can be accelerated with the evolution of hardware. I recognized this several times over the last 20+ years working for varying employers on varying problems. Through it all, reasonable solutions in Lisp, Smalltalk, etc. became faster simply by migrating the hardware. Meanwhile the industry generally migrated their languages to take on more features of these earliest dynamic languages born in the laboratories of the 1960's.

On another aspect of hardware, unfortunately for soloutions like the one in this paper, I was (now unrealistically) thrilled by the advances in Magnetic RAM (MRAM). This hardware seemed to be on the cusp of a price and density breakthrough which would have virtually eliminated the need for secondary disc-based storage for even very large persistent data sets. That does not seem to be panning out on the rosy schedule presented a few years ago. There appear to be some real limitations that will be difficult to overcome. The run-time / persistence mapping problem will be with us for a while. All the more reason to strive for simple run-time models as well as simple persistence models.

Not Unexpected

You scored as The Amazing Spider-Man. After being bitten by a radioactive spider, Peter Parker was transformed from a nerdy high school student into New York's greatest hero. Peter enjoys the thrill of being a super hero, but he struggles with the burdens of leading a double life. He hopes someday to win the heart of his true love Mary Jane, the woman he's loved since before he even liked girls. Right now, he just wants to make it through college and pay his bills. The Amazing Spider-Man 63% Neo, the "One" 63% Maximus 50% Lara Croft 46% El Zorro 42% Batman, the Dark Knight 42% Captain Jack Sparrow 38% The Terminator 33% William Wallace 33% Indiana Jones 33% James Bond, Agent 007 17% Which Action Hero Would You Be? v. 2.0 created with QuizFarm.com

Google: "All your Base are belong to us"

Via Mark Baker, apparently Google says, "All your Base are belong to us."

At least if you make your base Google Base then Google will prevent that content from being openly searchable on the web.

Also from Mark's same post, apparently Google Base is supporting the most base of purposes. As I wrote regarding another new Internet capability, oh, dear. That seems to be the way of the world.

Which Internet, again, did Google climb to the top of? Is it safe?

MIMO - Super G Wireless

My treat this season is a NetGear RangeMax MIMO wireless Super-G router. Seven antennas and 108 mbps. Actually it was a treat for my youngest who just got his own first PC. He is gaming wirelessly reliably from his room with a very strong signal and 108 mpbs.

I just have an 802.11g card in my laptop so I'm still at 54 mbps. But where the signal from the far corner of my house had been low, now it is very strong. The other son wants a Super-G card now too. I've got my eye on the new round of wireless products for network storage, etc.

'Tis the season I suppose.

Logically Out of the Blue

I did not see this coming. I was in a Barnes and Noble book store the other day and a new book jumped off the shelf into my hands. (I was shopping for gifts, honestly. I don't know what drew me over to the computer section.)

The relationship between Lisp and logic programming goes back to the 1960's and was a precursor to Scheme being invented in the first place. Steele created Scheme as a vehicle to understand Carl Hewitt's actor language which was derived from his Planner language which Hewitt developed about the same time as Alain Colmerauer was developing Prolog. Planner implemented a backtracking capability (for planning, get it?) similar to Prolog's. Scheme has since been used to implement many kinds of programming languages, including several kinds of Planner-like and Prolog-like languages.

And so The Reasoned Schemer brings it all back home to the student of programming and programming languages. It follows the Q&A-with-food-themes style of books also written by Dan Friedman with various authors for learning Lisp and Scheme themselves. (They even have a Java book in this style.) Some people like the style, others do not.

Programmers interested in Lisp, Scheme, functional programming, and/or logic programming will be interested in this book.

Representing RDF

Bill de hÓra explores the upside and down of using an RDBMS for a persistent representation of RDF. This reminds me of several times I've encountered a generic attribute/value pair relational data model. As Bill points out regarding the "disenabling" this does to Rails and Django (as they are currently designed), the generic model moves the domain vocabulary out of the relational schema and into the data itself.

I understand one of the keys to RDF is that this is a conceptual model for the semantic web and not necessarily a recommended persistent physical model. That doesn't mean it couldn't be, but I wonder what other models might make sense.

An advantage Bill points out to this approach is the RDBMS schema itself would change little if any over time. Everything becomes data stored using one simple, generic model. This tells me we need a database, independent of RDF or any other conceptual model, that can recognize more about the domain-specific data and relationships while supporting "agile data refactoring". Some databases are pretty good about this for star schema models. Star schemas kind of aggregate related RDF triples into another conceptual model that is only somewhat more complex than the RDF concept itself.

A star schema relates MxM things to each other through a common "fact". The simplest fact is a statement that such a relationship exists. So when some relationship is established at some point in time, say an employee is assigned a manager, the fact that this exists is established by a fact relating the employee (e.g. a row in the "employee" table) to the manager (e.g. another row in the "employee" table) via a fact (e.g. a row in the "management" table) along with other related "triples" vectoring through the same table (e.g. the "calendar" table for the start date and the "department" table for the organization being managed, perhaps the "role" table for the row of the role the employee is playing).

Then other triples even more tightly associated with each other are those "dimensions" themselves. So the relationship of the employee to their name, address, pay scale, and other vital statistics may simply be represented as columns in the same employee row. The result is a normalized fact table bringing together an array of denormalized dimension tables.

The kinds of changes to this model are simpler than those made to a "fully" normalized model. Columns are typically added to a dimension but are rarely removed. Columns infrequently change data type, but could. Dimensions added to the model, new facts are added, and new relationships between facts and dimensions.

A database not based on 25 year old approaches in the typical RDBMS are pretty efficient about representing this model and refactoring. Sybase IQ is one, e.g. in the Sybase Dynamic Operational Data Store. Efficient in this case means the space used in the database is typically *less* than the space used to represent the same data in a flat file. Very few databases have this capability and at the same time *reduce* the maintenance effort.

This model would be useful for RDF data sets that need to do a good bit of computation. For example when the "facts" of the relationships include numerical measurements of some kind (payments, temperatures, velocities, occurrences (e.g. attendance, page hit, etc.), etc.)

When the model is not so computation intensive I would suspect the queries would be more like searches and path navigation. The structure would not benefit from being in a more general attribute/value exploded RDF-like schema. Some kind of graph model would be better to support path navigation around large networks.

The three activities I think would come up frequently are more or less free-form search (text and other indexing independent of conceptual model), path navigation (across a large network of related RDF triples), and numeric computation (on measurements of some kind related to the things of the triple).

Jini/JavaSpaces/Rio... and Jython?

This one slides out off my sphere of awareness and then it's not too long before something pops it back inside. Are JavaSpaces still the best thing going for Java and yet still the least adopted capability?

I'm thinking about code replacement, etc. to keep a distributed system evolving. Erlang does it explicitly. Smalltalk does it well, too.

Java per se has class loaders, etc. But the still-too-secret-weapon that Java really has going for it is JavaSpaces (and the surrounding capabilities like Jini, including Rio).

JavaSpaces provides a simple distributed-shared-memory model for Java objects. While class loaders, etc. support dynamic loading, the mechanisms inside the language and VM per se do not support evolving interfaces very well. JavaSpaces is that "dynamically typed" (if you will forgive the phrase) surface in which "objects" [1] can actually change entire interface definitions over time. Not much more care is needed for this than for, say, a Lisp or Smalltalk system.

I'd rather be using Smalltalk, but JavaSpaces deserve much more attention. I wonder how well JavaSpaces and Jython fit together?

[1] I use "object" in quotes because I do mean to imply that a POJO will change its entire interface. Rather the POJO that is playing the role of some conceptual object will go away over time, to be replaced by some other POJO that is playing the same or some evolved role. This is like the observation that over time the cells of our bodies go away, being replaced by new cells. After some time and degree of replacement, do we have the "same" body that we had earlier? This is the core essence of a survivable complex system.

A Bag on the Side of the Eclipse

I was recently reminded of a favorite book: Tracy Kidder's "The Soul of a New Machine". I went to Data General developing CAD software and met some of these guys a couple years after the book was published.

A couple of phrases stick out... Tom West saying, "Not everything worth doing is worth doing well." and building exactly what Ed deCastro said he did not want, "a bag on the side of the Eclipse".

This is a bag on the side of my blog. I have not been around a computer much outside of work lately. Hopefully over the holidays I will get back to finding out what this AJAX thingy is.

I am currently engrossed in another book though, "Wicked: The Life and Times of the Wicked Witch of the West". As John Updike is quoted on the cover, it is an "amazing novel". It reminds me of Marion Zimmer Bradley's "The Mysts of Avalon" in its imaginative telling of a new story about an old story. Both books creatively incorporate real issues about society, culture, religion, and politics.

Dabble DB

I've not dabbled yet, but looking at the videos I agree with the consensus... the Smallthought team has put together a nice, simple system in a short amount of time via Smalltalk and Seaside.

This blows Ruby on Rails a bit out of the water. Maybe it will inspire RoR and other systems to become even more radically simple.

The Dabble design has borrowed a number of good ideas from OVAL and Lotus Agenda. They've also thrown some other good ideas into the mix. The mix looks good, great even. Because they've built on what I consider some under-explored fundamentals (simple mechanism to combine semi-structured information) and the simpler interactivity enabled by Seaside, Dabble could continue to go a long way for some time. This kind of thing, if not Dabble per se, should be a fundamental building block of those office applications you wish you had but would cost too much to develop.

The exciting thing is there are even more good ideas that have not been incorporated. I guess the unexciting thing for the developer community is that Dabble appears to be a commercial venture. But I guess that's good for them, because they have a winner on their hands.

I think it will be easier to dabble than it is to jot.

Don't Lose Any More

From Mike Warot at the IT Garage...

This is the 21st Century... don't lose my work any more!