In a Q&A, the pioneer in developing XML is dubious about SOA, preferring the term "Web-style," and he also thinks the Web community can do better than the WS-* standards.

What's your view of services oriented architecture, SOA?
Tim Bray:  
    
The term SOA, I don't really like to use it any more. It has, I think, become damaged, weakened by over hype, over use, over promise, under deliver. I can't explain what the difference is between SOA and Web services and I'm not sure I've met anybody who actually can without going into paragraphs and paragraphs prose. I want an explanation that's meaningful in terms a programmer can understand, so a programmer can go and build one of these things. So I'm actually becoming actively unfriendly to the use of the term SOA. So I'm happy to be quoted as saying that emperor has no clothes. If you are confused about what SOA really means, it's because the world is.

What needs to be done to make sense of it?
Bray: I think we really do need some new terminology. One term that I've seen used a bit is "Web-style," software that is in the Web-style. The Web has lots of lessons to teach. If you look at the Web there are no APIs. All there are is messages. If you look at the message exchange patterns, there's only one. I send you a message, you send me a message, our conversation is over. It imposes some difficulties, but it allows for fantastic scaling behavior. So I think Web-style is a flag I would like to see more people start to wave because I think it really means something.

What about Web services?
Bray: The importance of Web services is being underestimated. It's becoming plainly obvious that none of Java and .NET and LAMP [Linux Apache, MySQL, PHP] are going to wipe each other out. We're going to have all these things with us for the long haul. And yet, we need them to interoperate with each other. Enterprises need these things to work together. And I'm sorry they just have different APIs. That just the way it is. So if we're going to get them to work together it's going to be something along the lines of Web services that's going to make that happen.

Now, having said that. A lot of us are not sure that WS-* is the future. It seems unreasonably big, unreasonably complex and few of the core low-level elements of the stack seem ugly and awkward and difficult. We observe that people are putting out lightweight distributed applications using good old XML and HTTP and getting them done in days and they work great. Other people are trying to bring WS-* things online and spending a lot more and apparently not getting as much.

For more information
Forrester: Digital Business Architecture emerges from SOA

OASIS panel ponders: What is SOA?

I don't think, we at Sun, are willing to place an unqualified bet on WS-* as the future, which means there's a lot of interesting work that needs to be done. Because whereas the ultra-lightweight, I've seen it called POX for Plain Old XML or the architectural style called REST [Representational State Transfer], this kind of stuff apparently works great. It's being deployed by Amazon, by Google, by lots of people. On the other hand there's not much developer tooling. So I think it's fair to say that's a need that hasn't been met well enough by the vendors. I think Sun, and our competitors too, should be doing a better job of addressing it.

Are there just too many XML and Web services standards?
Bray: It's clearly true that there are too many of them. I also have an issue with the process. If you look at many of the successful standards, they tend to be distillations of technology that already existed. XML was a distillation of a previous technology called SGML. Java was created a dozen years ago applying the lessons that had been learned from many other object oriented languages. We had a lot of experience with object oriented languages and Java distilled those lessons. When you go and look at situations where people try to invent a whole new technology and standardize it at the same time, it's, to be charitable, a high-risk undertaking.