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