Web Things, by Mark Baker

Web site updated. CFP to follow Real Soon Now.
(link) [del.icio.us/distobj]

Bingo. See my comment there.
(link) [del.icio.us/distobj]

How to build a RESTful shopping cart with legacy browsers, aka Javascript saves the day again. Gorgeous.
(link) [del.icio.us/distobj]

In recent years I seem to have become something of a dessert wine fanatic. On my kitchen shelf – my home for soon-to-be-drunk, partially-drunk, and particularly attractive bottles (behind which I can hide the others 8-), I keep about a dozen bottles – mostly demi – of several different dessert wines, including Ice Wine, Beerenauslese, Sauternes, Tokaji, Muscat Beaunes de Venise, and Moscato d’Asti.

There’s one wine I didn’t list there though. And curiously enough, it’s also not listed in this about.com Valentine’s piece on wine and chocolate. I say “curious”, because in my opinion, it’s the single best wine match for dark chocolate; Brachetto d’Acqui. It’s a marvellous though obscure (due to limited production) sparkler gem from my favourite all-round wine region, Piemonte in northern Italy. Even the crappy Brachettos – like the one currently adorning my shelf – still posess a red fruit sweetness that you won’t find in any other wine. The better ones are just more fruity, aromatic, and complex. Plus, a red sparkler on Valentine’s Day? How do you miss that?!

Somebody asked me about this a while ago. Here’s a sample.

Chris writes;

IMO, the semantics of messages in pub/sub aren’t ProcessMessage, they are (or should be) more along the lines of SomethingInterestingHappened. Note the past tense. I think that is the key to achieving a loosely coupled enterprise.

Yes! If it’s your intent that all subscribed Web services implement a “SomethingInterestingHappened” operation so that documents can be submitted to each one then I’m totally in synch with that. I just wonder how it’s different to all of them implementing HTTP POST or SMTP DATA?

“SomethingInterestingHappened” is a uniform application semantic, though. It’s good to see Chris getting behind REST principles! 8-)

Ah, gotta love permathreads. 8-)

Stefan did such a fine job with his response, that I think I’ll just “+1” it (yes, including the agreement with Chris, gasp! 8-) rather than respond myself. Thanks, buddy.

I also wanted to add, in response to Chris, that I only brought caching up as an example of something in HTTP that wouldn’t make sense to have if its application semantics didn’t include GET. I didn’t mean to imply that caching couldn’t be implemented without modifications to SOAP. I was actually specifically thinking about two changes to SOAP which would be required for a couple of important optimizations, both having to do with coarse grained messaging, as SOAP is intended to support. The first would be a framing optimization, the “jump” feature (akin to a chunked transfer encoding). The other would be a push away from strictly interpreted XML, since XML doesn’t support streaming due to the fact that an application can’t make much in the way of forward progress until the end of the message has arrived, lest the message end up malformed.

I also just noticed this MEST response from Steve where he realizes that MEST seems familiar;

The issue was that for at least some people, that paradigm shift had already happened and confusion arose when it was given an unfamiliar name.

Hmm, there’s seems to be a lot of that going on. 8-) It’s why I’ve claimed for about 5 years now, that the Web is what Web services is trying to be. It’s also why I argue that MEST is a specialization of REST. Or, in Steve’s words, that “every behavioral entity works by processing messages” is a special case of “every resource is a container for state”.

Is my spam filter on the fritz, or is anybody else seeing a whole lot more spam in their (filtered) inbox? I usually get 2 or 3 a day, but the few days I’ve received an average of about 25 a day.

Gudge graciously continues the discussion. Here’s my lengthy response that I spent far too much time writing, then rewriting… despite having two Monday deadlines! 8-O

Regarding my concern that WS-A doesn’t require placing the destination address in, for example, the HTTP request line rather than the wsa:To header, he writes;

I really don’t see how WS-Addressing can specify this given that the spec itself doesn’t know anything about the underlying protocols […]

Let me stop him there, since that’s actually my issue; IMO, WS-Addressing should know things about the underlying protocol. As I described when I first raised it, this issue is more about the whole concept of “protocol independence” than it is about anything to do with WS-Addressing.

He then responds to my plea to spend some serious time focusing on the difference between application and transport protocols;

Now, I think I have some idea of the difference between the two, although I’m obviously no expert; transport protocols just move bits around without any regard to what those bits are, whereas application protocols, while still moving bits around, care somewhat about what those bits look like.

Hmm, that’s difficult to respond to because it’s not very specific! 8-O But Gudge didn’t appear mention what I personally believe to be the biggest distinction between the two; an application protocol defines application semantics. This relates closely to my earlier comment that there’s no analogue to such an entity in the historical CORBA/DCOM/DCE style stacks. The reason for this makes total sense though; when you need to support arbitrary application semantics, the only stack that would make any sense would need to separate those semantics from the “thing that frames the bits”. And that’s where the whole concept of “protocol independence” comes from, and as I said, it makes total sense when arbitrary application semantics are required.

Now, consider a system that only has a single application interface, like, say, email, a tuple space based system, or indeed any system built with a coordination language. Does this layering make the same sense there? I don’t believe so. There’s no need to be independent of that layer because there’s no need for any other application semantics. This allows the optimization of the framing and features to the application semantics. For example, had HTTP not had a GET semantic, then there’d be no need for caching. Now consider that with a “protocol independent” equivalent of GET, ala WS-Transfer, you’ve lost the ability to optimize the transfer features for that case. So while you could certainly try to deploy WS-Transfer, it would necessarily perform a whole lot worse than HTTP because optimization would require modifying SOAP. At least HTTP is optimized for the general case because it is the result of the merging of the two layers we’re talking about.

Gudge then clarifies that his background includes messaging and queueing systems, which I presume is a reference to MOM. That’s great; it’s good to have experience with varied architectural styles. I wonder then, if he was aware that a MOM based architecture natively (i.e. it can be abused) uses the same uniform interface constraint as REST (although it goes further to constrain the interface to a single “ProcessMessage” semantics, ala MEST)? It’s not commonly recognized that MOM adopts this constraint because the fact that there’s only ever a single application semantic means that the semantic can be excluded entirely from the message resulting in a pure looking document-in/document-out system with no operations anywhere. I emphasize “looking” there, because REST is just as pure a document-oriented architectural style as MOM, only because it permits operations other than MOM’s one, those operations need to be made explicit in the message… which is why HTTP has “POST”; it’s the name given to the same “ProcessMessage” semantic from MEST/MOM.

Finally, regarding my comment that I didn’t really care what the outcome of the resolution of the issue was, Gudge writes;

It seems somewhat odd, to me, to raise an issue and then not care about the outcome. Like shooting for a basketball hoop but then immediately leaving the court, without caring whether the shot went in or not. I guess this means that if the TAG decide that the decision made by the WS-Addressing WG was OK, then Mark won’t push back.

Ah, minor misunderstanding there. What I don’t care much about is – assuming that the TAG agrees the WG needs to remedy the problem – how the problem is addressed by the WG. Certainly, if the TAG, after considering my issue, decides that it wasn’t a problem after all, I’ll have a lot to say about that. 8-)

Bastard! First he invents the Web before me, and now this! It was close; I think I was # 50-odd million on the list)! Timbl, my nemesis. 8-) P.S. Congrats!
(link) [del.icio.us/distobj]