Zope at lastminute.com

Zope keeps popping up out there. Have you noticed?

Web Services and Proprietary Standards

Steve Vinoski on the realities of the Web Services standards mess. Sad but true.

Now, given half a chance, any self-respecting, shareholder-value-generating company will use "standards" as competitive weapons. If you were in that position you would do the same. It would be your duty after all.

I'm all for it but I'm also all for the consumers being cognisant of the rules of the game. We have seen "deep commitment to open systems" time and time again in this indusry. Yet, time and time again, we seem to be suspend disbelief and let yet another consortium have yet another crack at it for us and we sit back having bought into yet another this-time-it-will-be-allright pipe dream. Then it costs us money to buy into it, then in crumbles, then we start again...

Anybody finding themselves succombing to the allure of the lastest incarnation of this story - the Web services stack vision of open systems and interoperability - should run, not walk to get a copy of Information Rules by Varian and Shapiro.

Remeber this: true open systems only come about through market pressure because true interop lowers switching costs which is bad for business if you are an IT vendor.

If you can stop true interop happening you will - you must - it is the obvious commercial thing to do. If you cannot stop it, typically thanks to user pressure, you make sure that everyone other vendor is dragged along with you so that you don't leave any competitive advantage behind you.

Remember this too: users drive open systems and interoperability - not vendors. Period.

Schemas considered bad - Duck typing in the coming age of loosely coupled systems

What is a schema? In XML (regardless of flavour (DTD, XSD, RNG)) it is a top-down model of a class of XML instances. A generative grammar. A dictatorial assault on the mereology of knowledge. A mercurial nomothete, granting or barring structure and content down to its Democritus inspired indivisibilities.

Then there is "information", realy world stuff supposedly modelled by our fine abstractions. Fitting snugly onto the shadow holders we design for them at the back of Platos cave.

Information is, chaotic, fluid, messy. Information classes are slippery, statistical, fuzzy things. Both information and information classes are predisposed to change over time - especially in commercial applications.

When they do change, the lord of the schema sits on his throne like Canute, commanding the onrushing seas of change to halt. To no avail.

Maybe we need more Ducks and less Canutes? Duck modelling in commercial IT systems is an ITWorld article on the subject.

Client and server - a question of power?

Andrew Clark sent me an e-mail with an interesting approach to distinguishing client and server. A client must ask whereas a server has the power to grant or not grant requests at its whim.
The beauty of this definition is that it works in the troublesome XWindows case that none of my attempted definitions could cope with. I.e. the application (the client) asks the GUI system (the server) for permission to draw stuff on the screen. Yes, that works.

What is it that makes a client a client and a server a server?

Beats me. The more I look, the harder it is to find a nice clean distinction. This ITWorld article chews the matter over.

There is no alternative to messaging. Your only choice is good messaging or bad messaging.

So sayeth Phil Wainewright. No argument from here.
Paraphrasing Somerset Maugham here. There are only three rules that go into good enterprise messaging. Unfortunately, nobody knows what they are :-)
My three "must-haves" for good enterprise messaging are:
(a) Model *all* your business processes as long lived processes that communicate asynchronously via business level messages (documents if you like) *NOT* API calls.
(b) Make messages human readable and stateful. Make processes - as far as humanly possible - stateless.
(c) Provide synchronous behavior as a layer on top of the asynchronous substrate and stick a big health warning label on it.

And this years prize for best named paper at a Python conference goes to?

Anthony Baxter.

Adam Bosworth on asynchronous messaging

I have italicized the key bit below:

"...And the other thing is I haven't yet seen [in Indigo] what I'll call a sufficient focus on messaging. This is very basic to me. Any time I wire together a set of services I want to architect so that whether they are up or down it goes on working, whether they're slow or fast it goes on working. I just want robustness in the system. And that says to me you want to send message whenever you can. Sometimes you can't. But much of the time that's not true. And as we move to a sync world even less of the time that will be true, because in the background… The reason this works so well [holds up a Blackberry] is because they synchronize my mail in the background. So when I look at my mail it's right there. So I believe we're going to move more and more towards an asynch and message-oriented world. And that should be a key focus of where Web services go..." http://www.eweek.com/article2/0,4149,1530449,00.asp

Amen.

Bookshelf added

I have added a bookshelf page. Stuff I'm reading. Stuff I have read. Necessarily, it is starting very thin. I'll add to it as time permits.

New flashing thingy

Yes, there is a new flashing thingy on my blog. No I don't live in Belmullet but it is the closest place to where I do live (Sligo) that I can see on wunderground.

Go on, subvert something this week

Subversion, a source code control system, designed to get rid of the well known warts on that old warhorse CVS. Subversion appears to be all the rage amongst the technorati right now. I'm hearing effulgent reports from the technorati. The all important Python binding has been spotted. Watch that space.

Misquote alert

Thanks to Benja Fallenstein for pointing out that the person quoted by Don Box here was apparantly misquoted.