Apologies if that came out sounding harsher than I intended. Treat my comments as light banter. I actually have no hard feelings at all.

Regards,
Ganesh

Thanks for the detailed response on XML.

Another of the REST limitations that I deduced from your last comment is that “getting” REST does not confer a sense of humour, thicken a thin skin or enable one to respond graciously when people are trying to be nice.

Never mind.

A RESTful explanation for my blog post that has so offended you: Resource representations that are parsed by humans as provocative blog posts tend to generate more hyperlinks and create a more powerful hypermedia state machine that can drive the application state of more browsers compared to those that are parsed as bland. Hence human psychology when layered architecturally over the scalable web tends to favour the creation of resources which may not be to the taste of humans advocating a scalable web or such architectural layering. Make sense now?

Someone should write a thesis on this law of the web along the lines of Godel’s theorem:
“Within any formal system of logic, there will always be some propositions that cannot be proven using the rules and axioms of that system of logic.”

;-)

Regards,
Ganesh

I need to be careful here because I’m talking about the label “SOA” and its use in the market, and you and Ganesh are probably talking about something else, that you call “SOA”. I am concerned about the vacuity of the word “SOA”, and the height of abstraction.

So here’s the essential problem: I have no idea, specifically as to what you and Ganesh mean by SOA and more importantly, whether you mean the same thing.

You and Ganesh might be implementing successfully and calling it SOA, but the term itself has no common meaning, as such it has no value to me.

I’m a technologist that understands business, I expect some crispness and precision for technology and technical design paradigms. If SOA is purely a business process concept like Six Sigma or Kaizen, we can stop there. If it has technical import that can be assessed and measured as fit for use in designing software, that’s not coming across at all.

Loose coupling itself is better, but it doesn’t tell me much (eg what coupling dimensions? how is SCA not coupled?). That said, given the amount press and backing it gets, there must be surely something more to SOA than restating an engineering tenet.

I don’t feel “vindicated”, that’s not the point, but I am happy that WS-* has not overrun the deployed Web. So please give this line of reasoning a rest; focus instead on why you feel you need to tweak the people you want answers from:

“Being new to the REST-SOAP debate myself, I have no baggage”"

“Paying restafarians back in their own coin”

Hmm.

“Yes, but in your experience, have you found any relative advantages of XML over other data interchange formats like JSON?”

Yes. The toolchain is bigger, and it deals with Unicode better (this is becoming less true over time). It’s also easier to read for non technical people, although that depends on how you design the markup, eg, CamelCase markup that is optimised for roundtripping with OO languages has poor readability, whereas Rss/Atom is decent. These days readability via browsers is a main reason why I like microformats. To its credit, JSON has identified the basic machine interchange types that can work; XSD by comparison has been a mess.

When I talk about XML I tend to exclude stuff like XSD/W3C Schema, and I don’t see its unicode/textual nature as being a problem, ie, I’m not sold on binary infosets and such and have record of arguing against them.

The downside to XML are at least twofold, First is that if what you actually needed was MIME after all, it’s a poor substitute – witness how the SOAP community went round and round on this for years, and how Atompub allows non-XML upload by design. Second, it also suffers from a gensym fallacy of sorts (this is why you need transformation) as many of the vocabularies that needed one, don’t have a formal model, and as such aren’t inerligua of the kind SOA and BPM seem to need. But this can also be a feature, and it’s worth pointing out that the semantic emptiness of XML is designed in.

“Ah, but business processes and services are not necessarily highly transient. It depends on how they’re modelled.”

Business requirements are the least stable kind that I’ve seen ;) I think the number of modeling efforts, and their length, the sheer cost of data integration, the cost of implementing m&A, the entire nature of enterprise tech, does not support you here. This is in part because people have started from the wrong foundations, and in part because people just don’t want to agree on the meaning of words and terms.