2005/12/31
Add your comment
2005/12/30
That’s how you do it, more or less. I wonder if hierarchy isn’t used properly though, i.e. having “tag” as subordinate to “item”; if you DELETE the item, does the tag go too? Maybe it does.
(link) [del.icio.us/distobj]
(link) [del.icio.us/distobj]
2005/12/29
Phil Windley summarizes a point by Dion Hinchecliffe;
I spoke with Dion yesterday and he talked to me about governance mistakes he sees clients making. The number one problem is something he called the “tyranny of the `MUST understand’ flag.” You get a SOAP-based Web service loaded up with WS-* header elements all tagged ‘MUST understand’ and you end up with something every-bit as much a central command and control structure as if you’d just reintroduced the mainframe. No one can do anything unless they’re using the same toolset.
I think I understand the issue here, but I think there’s more to it than you might extract from that paragraph.
First off, mandatory extension mechanisms like mustUnderstand are a Good Thing, because it makes messages more self-descriptive; if a message is extended in such a way that older processors can’t accurately interpret the message, then you need it to save those processors from processing a message which they can’t process.
That said though, there needs to be recognition that there’s a fairly high cost of deployment of these kinds of extensions because each one that’s defined basically bifurcates the space of interoperable agents (you know, just like deploying a new service interface does … but that’s another issue 8-).
And that’s where I agree with Dion. If you find yourself using mustUnderstand in more than a handful of your interactions, chances are that you’ve messed up somewhere, likely by failing to account for sufficient extensibility in previous versions. In fact, I’d even extrapolate from that to suggest that if you’re using mustUnderstand in version 1.0 of your system, and that system is closed (i.e. behind a firewall, or otherwise not interacting with pre-existing software), you’ve definitely screwed up.
Speaking of which… Perhaps the worst offender in this regard is WS-Addressing, because it effectively mandates the use of at least one mandatory extension in every message; wsa:To. Well, technically it doesn’t require that it be tagged as mandatory, but I think it’s pretty obvious that if a recipient didn’t understand where the message was addressed, that all hell would break lose if it tried to process it. So, if you use WS-Addressing, then all of your messages are prima facie unprocessable by all existing SOAP software. Oopsie!
“The whole point of Ajax is to make the web easier to use. Not to move us back in time.” Amen to that, and a big “ouch” to live.com.
(link) [del.icio.us/distobj]
(link) [del.icio.us/distobj]
2005/12/23
Oh joy! Something to look forward to on Manly beach when I’m there in January!
(link) [del.icio.us/distobj]
(link) [del.icio.us/distobj]
“It doesn’t put itself on the line, so it isn’t science”. Most succinct rebuttal to ID I’ve heard.
(link) [del.icio.us/distobj]
(link) [del.icio.us/distobj]
a common mistake is to take a layered design as a requirement for a correspondingly layered implementation
From Gaining Efficiency in Transport Services by Appropriate Design and Implementation Choices, by Watson and Mamrak, ACM TOCS, 1987.
Compare and contrast;
Specifically, Internet based efforts (including the Web, of course) always start with an interface constraint. This is simply for the reason that they’re (usually) always focused on a single task – for example, email exchange, mail folder access and synchronization, file transfer – and pay little to no attention to what it means to define interoperability between those applications, since that’s tangential to their primary objective. A consequence of this approach is that there becomes little value in using a common sub-layer-7 protocol (like BEEP, IIOP, or how most people use SOAP).
2005/12/21