SOA and Messaging

+1 to this entry from John deVadoss of Microsoft. Messaging is at the heart of SOA. Without it, you ain't got no SOA, you've got (most probably) a temporally coupled, exposed object API system.
Sadly, there are lots (probably the majority at the moment) who think the latter is a perfectly good SOA. I think the tide is turning though.

API's are the real lock-in

Stunningly on-the-money comment from Don Box. APIs have failed, time and time again to produce interoperability. Interop comes from data and data exchange patterns. Or if you like, protocols, or, if you like, messages and message exchange patterns. If we look after open specifications of data semantics and open specifications of data exchange patterns, and open specification of bits-on-the-wire syntax, we will be in good shape. I wrote about this on ITWorld some time ago APIs considered harmful.
Note to all imperative programmers out there using languages with static typing and no native conception of hierarchies or lists or maps or continuations or closures or duck typing. These are the basic things you need for a pleasant programming experience in a bits-on-the-wire world. API-centricity will drag your productivity down a dark alleyway and strangle it.

XML Munging - the death knell of imperative programming?

It seems to me that the sheer weight of all that XML out there is starting to drive changes in what we consider to be the "must have" constructs of mainstream programming languages.
In Ada, C, Java, Pascal etc. We have Class/Record. That works fine as an abstraction for good-old record strucures. i.e. endless variations on the "person = name + address + phone" theme.
XML doesn't do Class/Record. There is no such abstraction. XML sticks the word "hierarchy" up your nose and twists it until your eyes water. Its a tree dammit with rough edges, and element order matters, and it can be of arbitrary depth and things can contain other things of the same type. Deal with it.
Attempts to *make* XML fit the Class/Record model are ending in tears all around us, as developers hit the limits of what you can do with Class/Record <-> XML mapping.
Moreover, the awfulness of APIs that attempt to hide the realities of XML behind fancy prophylactic abstractions soon shows itself in non-trivial applications.
The result? A whole new deluge of "lets invent a new syntax for this" is occuring in programming-land. XPath probably started it, XQuery has picked up where XPath left off ("parenthesis delimiters for comments anyone?). Then there is Native XML scripting (BEA), scala and X Omega (Microsoft) to name but three.
Functional/declarative programming languages have the necessary machinery to get passed the Class/Record impass but predate XML. I suspect the whilst some will concentrate on creating new languages from the ground up that have XML as a first class memory of the type hierarchy, others will look at grafting XML smarts onto existing functional, functional/imperative languages.
The latter sounds to me like the road to follow. Keep a close eye on Python and Ruby. some day, all mainstream languages will have the features they have because without them, XML processing in a royal PITA.
Also, watch out for the exasperated Lisp hackers who, with considerable justifaction, point out that nothing interesting has happened since 1959.

An interesting list of languages for the JVM

Robert Tolksdorf has an extensive list of languages for the JVM. Go on, try one. Its good for you.

ESR and comparing share prices

Skip to the end of this article to see what I'm talking about.
I'm no George Soros but I do know that you cannot compare the share prices of two companies in any meaningful way Their absolute values are meaningless happenstances of history (stock splits etc.).
Now read the article :-) Then read this one for another take on matters.

Services versus Components

Clemens Vasters hits the nail on the head:

A service is strictly not a unit of code; it is rather a boundary definition that might be valid for several different concrete implementations.

Amen to that.
Services are all about boundaries. Here is my definition of a service - it is a re-purposing of John Searle's Chinese Room argument.
There is a box. It has two slots. You can send messages (XML documents of course) into one slot. The other slot can be used to retrieve messages (more XML documents) from the box.
You know nothing about what goes on inside the box. It is a boundary. Your understanding of what the box does, is driven purely by the message exchange pattern of messages going in the IN slot and coming out the OUT slot.
Is there a person in the box doing the work? A process? An entire sub-continent of J2EE app servers or .NET boxes? You don't know or care. All you care about is the message exchange pattern.

Forms Engines - the new browser war?

I came across another XForms engine today xformations .
It would appear that a trickle may turn into a torrent and a race-to-zero would seem to be taking shape on price.
Reminiscent of the browser war years in some respects. I guess what's different this time is that there are multiple violently different technologies approaching the same problem from different angles - XForms (W3C), Accelio/PDF (Adobe) and Infopath (Microsoft).

Stately, plump copyright law

John Naughton on the continuing saga of Joyce's Ulysses, copyright etc. etc.
Many moons ago (when multimedia CD-ROMs where the next *big thing*), I contemplated taking a shot at coding up the text of Ulysses in HyTime. The rich tapestry of the novel provides a wonderful playground for HyTime architectural forms. After squeezing some intellectual fun out of it, the plan was to use the rich HyTime coding of relationships to create a Ulysses on CD in which every word of the novel (more or less), every word of commentary (more or less) could be used as a hypertext springboard into/out of, annotations, audio/video, critical analysis etc.
We dipped our toes briefly into the copyright status of the text (actually "texts") and decided life was too short. It really would have been fun though.
Roddy Doyle has recently started to utter the un-utterable. Now might be a good time for the Joyce Estate to, as we say in Ireland, soften the way they look the gift horse in the mouth.
At the time, I devoured Bruce Arnold's The Scandal of Ulysses. A book I heartily recommend to anyone interested in Joyce.

Jeff Schneider on Weblogic Integrator

Jeff points out the perils of putting business logic into custom Java controls instead of web services for effeciency reasons.
Microsoft's Indigo gets this right. Design *everything* to be loosely coupled and then, at run time, decide which invocations are local (and can be turned into direct memory object invocations) and which are remote (and thus will be kosher web service invocations at run time.).
With a little thought, it is trivial to arrange that developers have a single invocation abstraction at design time (web services) but multiple deployment options at run time (e.g. web service or RMI).

Danny Ayers picks up something I missed in Livschitz's article

strong typing (used in the sense of "static typing") is part of the solution? I think its part of the problem. (An upcoming ITWorld article on "duck typing" will noodle this further.).
As for "square backets". Read "angle brackets" :-)

More from Victoria Livschitz's article

I could not let this go unblogged!

"The world has gone crazy with XML and then web services; SOAP and UDDI are getting enormous attention, and, yet, from a software engineering standpoint, they seem to me a setback rather then a step forward.
We now have a generation of young programmers who think of software in terms of square brackets. An enormous mess of XML documents that are now being created by enterprises at an alarming rate will be haunting our industry for decades. With all that excitement, no one seems to have the slightest interest in basic computer science. Still, there must be people out there who think differently. Jaron Lanier is clearly one of them. Recently, one project at Sun Labs appeared to be genuinely interested in beginning work on the "next thing after Java technology" as part of far-reaching research into new computing platforms. So, I don't know, things may begin turning around." [http://java.sun.com/developer/technicalArticles/Interviews/livschitz_qa.html

What a breath of fresh air that is!

Object-oriented programming has a fatal flaw

Today is my first encounter with the writing of Victoria Livschitz of Sun - The next move in programming.
There is a lot to savour in this piece:

"Object-oriented programming has a fundamental flaw, ironically related to one it helped to cure."

...

"Consider a few common concepts that people universally use to understand and describe all systems -- concepts that do not fit the object mold. The "before/after" paradigm, as well that of "cause/effect," and the notion of the "state of the system" are amongst the most vivid examples. Indeed, the process of "brewing coffee," or "assembling a vehicle," or "landing a rover on Mars" cannot be decomposed into simple objects. Yes, they are being treated that way in OO languages, but that's contrived and counter-intuitive. The sequence of the routine itself -- what comes before what under what conditions based on what causality -- simply has no meaningful representation in OO, because OO has no concept of sequencing, or state, or cause. "

Sequencing, state, cause....yes indeed. And later:

"I envision a programming language that is a notch richer then OO. It would be based on a small number of primitive concepts, intuitively obvious to any mature human being, and tied to well-understood metaphors, such as objects, conditions, and processes."

Yes. How about an Erlang meets REST meets JSD (in partic. its state w.r.t. time model) meets Eiffel, all wrapped in a Pythonic syntax?:-)
Yummy.