Web Things, by Mark Baker

Just came up with this. I’ll have to use it someplace. It’s a bit too brash for my .sig unfortunately, especially for WS-Arch emails. 8-)

Update; just whipped together a blog at my O’Reilly weblog.

There are two kinds of people; those that believe that XML-RPC was SOAP‘s predecessor, and those that believe that PEP was.

Paul Prescod responds to Adam Bosworth’s “One Fell Swoop” article. Right on again. But there was something else in there that I felt needed some clarification; application state.

Adam writes;

[…]Thinking of the Web servers as “objects” is an extremely bad idea. Objects are repositories of state. Conversations with them are by definition not stateless.[…]

There, Adam appears to confuse object state and application state. The former, object state, refers to the state held by the object, in the “behaviour, state, identity” sense of the word. For example, the state of the current weather in Ottawa is 11 degrees C.

“Application state” refers to the progression of the system during the execution of the application, more commonly (and less confusingly, IMO) referred to as “session state”. In the weather example, “session state” is held entirely by the client as the weather service need not remember anything about my invocation in order to serve it the next time (though that’s obviously a weak example). Any stateless interaction means that application state is maintained by the initiator of that interaction. Any stateful interaction means that application state is, at least in part, maintained by the recipient; this can range from part initiator, part recipient with HTTP+cookies, or full-recipient state in a remote session architecture like VNC.

Sometimes I see signs of smart folks figuring out how to do Web services properly, and I feel a glimmer of hope that the industry may not be wasting hundreds of millions of dollars with SOAP and WSDL. Then I see stuff like this, and I realize, nope, it’s going to hell – specifically this part;

Bergandi: With a wizard-based environment within the SOAPswitch. The SOAPswitch itself has self-discovery capabilities. It has the ability to, in the example I gave you, inquire into the metadata of what the Siebel system looks like; discover what business objects are available and what methods are available against those business objects; and then, based upon that, in a very, very simple way, generate all the SOAP that’s required for communication.

Internet-scale distributed computing just ain’t that easy, folks, sorry.

I just made an interesting observation regarding all these orchestration, workflow, choreography Web services specs recently released. Let’s see who in the Web Services Architecture WG picks up on this …

An interesting discussion on xml-dist-app about implicit versus explicit use of the Web Method Specification Feature of SOAP 1.2. I guess I just have a hard time understanding why you’d want to hide the method, either by defining a default, or deriving it from the MEP in use. I mean, how else do you accomplish something without knowing what method you’re invoking?

Spent some time thinking about how the Apache Axis project could support the SOAP 1.2 “Web Method Feature”, the major architectural difference between SOAP 0.9/1.0/1.1, and SOAP 1.2. I’m not sure that many Web services folks understand the implications of this yet, but it’s clear to me that it dispells the notion of SOAP as a layer, which is bound to mess with some software. Layers hide other layers beneath them, but what the Web Method Feature says is that a developer must be aware of which HTTP method they’re using if they’re using SOAP bound to HTTP. Let’s hope they all see it that way too. 8-)

The topic is being discussed on axis-dev now.

The big news from yesterday, WS-Security is submitted to OASIS. For those who don’t think Web services have much of a future, this is really good news for the Web and the W3C, as it removes influence from the Web Services Activity, specifically the Web Services Architecture Working Group (of which I’m a member, but that I’d be happy to see go away). Of course, many Web Services proponents are quite concerned, as it puts more control in the hands of MS and IBM.