Tag Archives: xml

links for 2007-02-02

links for 2006-12-05

links for 2006-11-18

WSO2 doesn’t get it

I like how news of Sam and Leonard’s REST book is kicking off a new REST/SOAP thread. This time though, it seems the tables are turned and it’s the Web services proponents who are having to defend their preferred architectural style, rather than other way around. It’s about freakin’ time! I’m kinda tuckered 8-O

Sanjiva chimes in, in response to Sam’s probing questions;

ARGH. I wish people will stop saying flatly incorrect things about a SOAP message: it does NOT contain the method name. That’s just a way of interpreting SOAP messages […] SOAP is just carrying some XML and in some cases people may want to interpret the XML as a representation of a procedure call/response. However, that’s a choice of interpretation for users and two parties of a communication may interpret it differently and still interoperate.

Oh my.

Every message has a “method”; a symbol which is defined to have a certain meaning understood by sender and recipient so that the sender understands what it’s asking be done, and the recipient knows what it’s being asked to do. A recipient which doesn’t understand what is being asked of it cannot process the message for hopefully obvious reasons.

What Sanjiva’s talking about there is ambiguity as a feature of Web services; that some recipients will interpret a message to mean one thing, while others another. Note that this is very different than what the recipients actually do in response to the message; that can and should, obviously, vary. But varying interpretations of the meaning of the message? Absurd.


Via David Wragg, a pointer to a great description of the roles and responsibilities of senior technical staff, written by a former colleague, Mark Kampe. Interestingly, that version was drafted 4 weeks after my tenure began (retroactively) as a Senior Staff Engineer at Sun. I’m surprised I hadn’t seen it until now.

The snippet that David quotes is the one that struck a chord with me too;

When the “Emperor has no clothes”, it is the responsibility of the senior technical staff to stand up and say so. Sales people are driven by short term business. Marketing people work with all manner of vague and ambiguous factors. Executives work with the information that other people have given them. Managers work with the directions they have been given. Engineers are the people who responsible for figuring out how this stuff is all going to work … and if it isn’t going to work they have an obligation to say so.

links for 2006-10-21