… to the cottage for a couple of weeks. Not an IP packet in sight.
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
“where the envelope is to be sent” – and then either
(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
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.
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
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.
‘Matsumura says the technical committee intends to stay above the fray of what constitutes a “proper” SOA, and work to define the architectures that people have up and running.’ Bravo.
Rule of thumb; any
or paper on distributed computing that lists integration technologies
such as DCOM, CORBA, or RMI, without mentioning the Web, probably isn’t
worth your time.
“Applications that do not have a RESTful web interface are pure, unmitigated evil.[…] There are, of course, exceptions but the application you are working on is not one of them.” Nicely said.
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
I can only assume this is an error.