Read part two.
First of all what are we talking about when we talk about WOA?
A number of people here are defining WOA, appropriately, I think, as a way to do SOA. It's not that it's a different thing. SOA is a pattern or a way of doing application design with certain principles in mind. WOA is a way to implement SOA. It goes one step further and says take those principles and here are some of the technologies you could or should use to realize that service orientation. It's a continuation of the SOA versus REST discussion. It's not an either/or question. REST is the grassroots way of doing SOA, while WS-* style WSDL-based SOA is the top down way. The WOA discussion is just continuing talking about those two different paths. So you don't see it as a debate?
One of the things that's frustrating to me is we have this pendulum swinging so far to the left or the right. The WS-* guys have all these specifications and it seems like they are creating more committees than there are implementations out there. So the reaction from those who are very practical and implementation focused is to go in the exact opposite way. So you could call WOA the equivalent of anarchy for service orientation. While the WS-* guys are the oppressive government, so ultra strict that it is very difficult to get anything done. So you end up with this wide gulf and somewhere there's a happy medium. Are you starting to see WOA used and is it actually using REST?
Yes and yes. Several of our customers who originally came to us with a very Web services, SOAP and WSDL and compliant with policy approach, have now all said they would accept RESTful services as well. RESTful services are essentially what WOA is all about. It's HTTP-based, XML-based. It allows for schema changes. It doesn't require any mandatory compliance to certain standards. That presumably makes it easier or more useful. Now, I'll caveat that if you want to go a little further into it. Yes, what is the caveat?
The problem is that while it's very reasonable to say that too much structure and too much policy is going to make change difficult because it's too much of a burden. That's fair. The WOA guys claim that against the WS-* guys, but one of the tenants of WOA is you just don't have these kinds of standards at all. You basically do XML over HTTP and anything goes. But if you have too much change, you'll be breaking too often. You can go too far with WS-* standards and have change inhibitors, and you can go way too loose and have change inhibitors as well. WOA is a great way to go, especially if you're doing ground-up SOA, but many things I've gotten for free were worth what I paid. So don't get the impression that WOA is SOA for free. It isn't. You've got to have a certain level of governance, otherwise there's no real way to manage change.
Possibly. From the Web-oriented side, you could start by standardizing on certain schemas and constructs. Those schemas and those constructs are going to allow us to have predictability. That's our mechanism for making sure changes are not random. But that flies in the face of one of the tenants of WOA. So you'd have to relax that. You'd have to put more rigor in to come a bit closer to center. The WS-* guys could just get off of this absurd level of structure. It's all for a good reason, but the problem is by the time there are so many standards, interoperability becomes impossible. How do you solve the interoperability problem?
Our product supports all kinds of Web services stacks. And, of course, Web services are supposed to be interoperable. Yet, we see all kinds of scenarios where when our product talks to this Web services vendor it has to talk in a certain way. When it talks to a different Web services vendor, even with the same service running, just changing the vendor in the implementation, it has to talk a different way. And it has to talk a different way for the third vendor. So the problem is the WS-* guys have so much rigor that the implementations are non-interoperable. What we've got to do there is simplify. Throw half of these things out. Make sure there are good interoperability standards and not worry so much about all the little details. That will bring them back to center.
In part two of this interview, Michelsen outlines a practical approach to governance for both RESTful-based WOA and WS*-based SOA.