Web services zen¶

Sean saw that I had achieved WS-zen (his words :-). You don't want to "call and API", you want to send over a document. Btw, read this comment on Sean's site.

Mark Baker was happy with the new recruit, but warned that for everybody I know who came from a CORBA/DCOM-like distributed systems background, but now understands the Web, serious mental model rewiring occurred. If you haven't had that rewiring, you don't (yet) get the Web.

But Lucky for us fules then, who never started with CORBA or DCOM to begin with, according to Bill de hOra

Well, I haven't ever used CORBA or DCOM so there is no rewiring to be done there. It sure helps me to be a linux user since somewhere around 1996, as the web and the http-uri-document-mindset just seems familiar to that linux background.

On the other hand, more sobering, is the fact that I don't have a lot to show yet. What I did take care of is that most of my web-based programs allow you to access most everything in XML through a simple http GET interface.

But I'm juggling both a PhD dissertation and a few prototypes at the moment, so I'm not yet that impressive as a recruit when looking at the amount of good stuff actually produced :-)

But, but. But I'm doing research (almost finished) in the building and construction industry. There's a load of paper-based communication there. And it is impossible to get one nice big ontology or whatever running as the backbone of one single nice big XML exchange format. Imho, of course. Likewise, getting SOAP-APIs accepted and working in such a divided and decentralised industry... No chance.

The big, big chance for this industry is to get cracking with plain http, xml, rdf. Just make the information that you've got available in XML on some website. Password protected mostly, I guess. First, it will be in a heapload of different XML formats, but that doesn't really matter. XML is better than some undocumented binary format.

Just imagine having the specification, a cost statement, a planning and the drawing available on the internet... Instead of having the drawing on the architect's harddisk, the planning printed out on the wall in the shed, etc. At least you've got a fighting chance of hiring some coders to wire it all up. For a big project, this one-of-a-kind wiring-up should pay for itself.

Slowly, things will settle down a bit and some common tools and formats will emerge. By economic reasons. Transforming one XML file into another, even partly, saves money on personel that is then free to to "real" work. Not just typing over a drawing...

A bit of XML, a bit of RDF. Accessible using http . That should be just too attractive not to use. But it should be user-friendly to use and economically a no-brainer. For this last one, keep in mind the 80/20 rule as told by Tim Bray which I would put a little bit differently by looking at market share. Some technologies need 100% market coverage to be successful. "If everybody would just accept this standard!". Other technologies already give you 80% of the benefits if only 20% of the market really does something with it. What I'm proposing is probably pretty 80/20-ish.

If you want some more info, read the internet operating system for the building industry