I am having my doubts about WebServices.
The premiere issue of Queue, the new magazine launched by the Association of Computing Machinery, most articles were devoted to WebServices, including interview with the guys that came up with the idea. They looked at the great revolution of the Web amd wondered whether it couldn't be generalized further. The Web is very successful as a catlog and a communications medium with very simple tools: as a client you have to understand (meaning that you have to have a program that can make sense of) the HTML that marks up pages into pieces like "this is a headline and this is a button and this is a paragraph", and then you have a human brain to read the information in the HTML messages and make decisions. For a company, makingt this connection on the supplier end was cheap: put up a server, connect it to the database. Now, what if these big pages were made with a generalized from of HTML language that allowed you mark up other things than pages called XML and other languages that defined per industry what was in that XML message ("this is a catalog, this is the thickness of that screw, this is the amount of your interest rate") ? Suddenly this succesful paradigm could be used for far more, like computers talking to computers. And we get re-use all the tools that worked for the Web to connect all this stuff.
Now we have a bandwagon and WebServices is the buzzowrd of the year. Now there have been many attempts at connecting computers to swhare data and compute together in generalized ways, but they all used very fine messages. The dialogs were like "Hi."
"What time is it?"
-- "Who wants to know?"
-- "Ok, it is 12.34 PM"
"And the date?"
-- "Who wants to know?"
"That other guy using me. He's military."
-- "Oh, he gets to know more. It is exactly ten days since the last secret mission. Also known as October 12th 2003."
Now you could use those old methods, called RPC and CORBA and COM and what not to make coarse queries ("Hey it is me I need the time and the date and the temperature.") but the plumbing of these standards was all defined on very small methods, little things you'd want to do. WebServices, according to inventor guy, was supposed to be just like webpages: you don't go to a page and type everything just to get a minute update, but you exchange these big pieces of data. "Hi, I want the time and the date and widget seven in red and you should sent it here but route it through there and I'll pay for it this way."
-- "Well it is on its way but it will take 12 days and here's the time and the date."
I am a UI guy. And I am trying to let people interface with WebServices. From a phone. That's my current project. And I am just not seeing the big difference between CORBA and WebServices, once the nuts hit the bolts. Because in the end, I will probably have to offer the results to people. And people like to tweak. They like to explore, they like to change little things to make up their minds. Do they have the item in red? In stock? How much does it cost then? How about blue? What if we took that other route? Can we go through a town?
So if I want to stay close to the WebServices ideal, I keep uploading big chunks of catalogs and maps and whatnot, and that's expensive. People still pay by the packet. And it gets even stupider for the project I am doing now: a distributed game. Players end up sending single moves as thse stateless pages that the programs on each end have to stay synchronized on. Next idea was doing IM on WebServices. IM! Single lines of text only useable for humans.
So basically for my purposes, I am not seeing the difference between WebServices and CORBA tunneled over port 80. In fact, WebServices for now will be more complicated since the XML and associated languages (SOAP, WSDL) are not human-readable but not particularly program-readable either, you have to write plumbing to hook up the SOAP and XML messages to your database and clients and what not. Same with CORBA, but there what plumbing to build was defined directly by the CORBA syste, no guesswork. Fortunatly my project is using an experimental toolkit (IBM AlphaWorks WSTKMD) that makes all that work go away, much like CORBA. So why am I trying so hard with these new WebServices again?
Because CORBA didn't look right at the wrong place at the wrong time. CORBA made it look hard, WebServices makes it look easy: you just exchange generalized webpages -- doesn't everyone understand how simple it is to exchange webpages?
WebServices is good if you already know what you want, but bad to find out. People may know exactly what they want, but that is before the real world hits and comes up with all these choices. And for that WebServices offers no compelling advantage over other protocols -- in fact, its messages really have quite the amount of overhead when they get small.
It's funny: studying UIs you find out that people are most comfortable in exploratory environments where they can make little tweaks, with instant feedback, no commitment, no stress they are "breaking the computer" or doing something irrevocable. UIs where everything they can do is visible, in paradigms they quickly understand, tailored to the task, simple building blocks that can be collapsed into powerful tools for advanced users. Yet the plumbing we are working on, the revolutions around us, all end up being about bigger and bigger messages, whole pages of changes being transported around to interact with, catalogs in a medium that make it hard to flip the pages and compare the goods. That very simple universal paradigm of browsing actually makes it very hard to do something complex with. And now it is supposed to start running everything.
OK UIers, just make it work now!
[Cloned from my Slashdot journal]
Now that I am a researcher and am supposed to have opinions, I am considering putting a link from my personal Intranet page to that journal. So innocent people can be exposed to it too.