Monthly Archives: August 2005

Bound by bindings

Here’s a simple question for WS-* advocates; how does one take a SOAP envelope/infoset generated by the WS-Addressing SOAP binding, and send it via the SOAP 1.2 default HTTP binding? Should be trivial, right? Let’s see. Here’s an example envelope (from the WS-A spec);

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
           xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <S:Header>
   <wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
   <wsa:ReplyTo>
     <wsa:Address>http://example.com/business/client1</wsa:Address>
   </wsa:ReplyTo>
   <wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
   <wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
  </S:Header>
  <S:Body>
    ...
  </S:Body>
</S:Envelope>

That envelope contains both a wsa:To and wsa:Action header, which are, respectively, where the message is to be sent, and the action that is requested be done. Now, off in SOAP/HTTP land, we have a set of properties of the default binding which are required in order to construct a SOAP/HTTP message. Amoungst these properties are ImmediateDestination – “where the envelope is to be sent” – and then either Action or Web-Method (or both – who knows?!) which define the – you guessed it – “the action that is requested be done”. So, you’d think that WS-Addressing would have to define how to populate those properties from a WS-A infoset, ideally as a function of things like wsa:To and wsa:Action. AFAICT, it doesn’t.

And to think this think got to CR?! Egads.

The concept of a “SOAP binding” is prima facie broken because it necessarily requires treating underlying protocols as transport protocols, as if the SOAP envelope was actually a SOAP message (hint: it isn’t). WS-Addressing should either a) map the relevant part of its infoset to the property model of the default SOAP/HTTP binding (e.g. wsa:To -> SOAP’s ImmediateDestination), or b) define a new SOAP/HTTP binding that does the same thing, should problems be found reusing the default binding.

Aggregators are splogs?

Mark Cuban writes;

Whats a splog ? A splog is any blog whose creator doesnt add any written value. Im sure some might argue that packaging data , such as news feeds or the blog posts of others is added value. I dont think it is. After all, thats why there are topics and indexes. If I want information about the Dallas Mavericks, I can search for it, optimize it, and save it. Because indexes are based on freshness, my searches are automatically updated, freshest data first, as new posts are introduced.

Gotta disagree with him there, in particular where he says “A splog is any blog whose creator doesnt add any written value”, as that would include useful aggregators such as Planet Web 2.0. With these aggregators, value is added not just by content, but also by the aggregation itself. For example, while it’s true that, today, a subscription to Planet Web 2.0 will provide me the same content as if I’d just subscribed to the individual feeds it’s subscribed too, I get something else by subscribing to the aggregate; I’m buying into Ian‘s view of the Web 2.0 world for perpetuity, including the removal of feeds he feels are no longer relevant, as well as new ones he finds that he feels are relevant (temporally varying membership function anyone? 8-).

Search helps too, as Mark correctly points out. I’m subscribed to a number of Technorati/Bloglines searches. But there’s a lot of noise there which doesn’t make them a viable solution in the general case, IMO.

My time is valuable. If I can use the trust I have for Ian’s opinions to turn an O(N) integration complexity problem into an O(1) one, I’m so there.

Horse before cart, except after ..?

Via Radovan, a slide set that makes some odd and ambiguous claims (granted, it is just a slide set), including this doozy;

Projects and enterprises should define their Service Architecture FIRST

Requirements and process need to be in the context of that architecture

Geez, and folks rag on me for claiming that the Web is a far more general solution than believed; apparently, you can just assume SOA for all problems, independent of their requirements! Think of all the time saved actually trying to fit a solution to the requirements of the problem! 8-)

I can only assume this is an error.