Vaughan: You have been working at services for quite a while. Since before there were services! I know you are always looking forward, but I wonder if you could take a bit to look back. I think it's useful.
Toufic Boubez: I agree. I think in SOA or IT in general it's a mistake for people not to look back and see what's happened and where they came from, at what the original goals are, and try and learn from those patterns. I don't want to say necessarily from mistakes, but from the patterns, at least, that have happened before. I totally agree with looking back.
Vaughan: UDDI was certainly a major step toward SOA. Can you recall some of your thinking around that early on?
Toufic Boubez:The reason some of my early efforts were around UDDI was because I believed that was a missing component of a natural service oriented stack. Aside from just UDDI, which I was involved with in the early years, I started the SOA group at IBM in the late 90s. The reason that's important is that a lot of the ideas came from that group.
The main issue there was interoperability. We had no way for one stack to work with another stack, for one product from one vendor to work with another from another vendor. That's where XML came in handy. People can argue the merits good or bad of XML, but what XML gave us was a bandwagon, if you want, that everybody could jump on so that software vendors could agree on something. That sort of led us down the path to what became service orientation and eventually web services. But everything we did came from taking patterns that have worked in the past, specifically from object orientation and component orientation, component architecture and object architecture.
Vaughan: And this set the stage for the SOA is dead movement!
Toufic Boubez: Well I was part of two "software revolutions." One of them was the object oriented revolution. What came out of SmallTalk was object orientation, which became a big thing. SmallTalk gave us something that is fundamental still to this day. But the lesson I drew from that is that, no matter how exciting a technology is, a good cycle for adoption takes about 10 to 15 years.
Later, again, we got all excited and to a certain extent we forgot the patterns of the past. It's going to take 10 to 15 years for the cycle to be established. Now, lo and behold we're ten years into it, about the same time frame, where at the beginning everybody thought "Alright, service orientation is going to be the next big thing in a couple years, everyone will be doing service orientation and web services." Where, in reality, just because of momentum and all kinds of established procedures and established mechanisms, it takes a while for big corporations and organizations to move. Another 10 to 15 years and here we are. I think we keep forgetting the time it takes for these cycles. That's one thing I learned from being exposed to these two big waves.
Vaughan: Where did we go with the wave?
Toufic Boubez A few years into this service oriented stuff we got sidetracked and we forgot the original principle of why we were doing it and ended up just doing just web services, which is what we were doing before in client server technologies but now doing over in XML, which made it less performant and more prone to a whole slew of issues.
So we were getting all the bad stuff without getting any of the benefits. That was unfortunate because it took several years for people to start getting out of that rut and start to realize that it's not about XML, it's not about web services, and it's not about request response, but it's about service orientation and how you build decoupled or loosely coupled systems that allow you to exchange messages back and forth. I think we're back on track now. It took us a few years to get out of that for a variety of reasons. I don't want to start blaming individual people or organizations, but I think we've gotten back on track.
Vaughan: When you say "back on track," is this REST versus SOAP that you are talking about?
Toufic Boubez: No, not necessarily. SOAP and WSDL, all those technologies, are part of the issue in that people concentrated on the technologies. But just the fact that I'm using SOAP or XML does not mean that I'm doing service oriented architecture. All I'm doing is maybe taking systems that I already built and just putting a SOAP front end in front of them. It is important to think globally about what service orienting an enterprise means. People were just slapping XML back and forth without really paying attention to what it means.
And SOAP versus REST is part of that problem, of course, because we were in the mindset of "Okay we have to use SOAP, we have to use XML" without really paying attention to the bigger picture of how to build an architecture that is loosely coupled versus how we put bits on the wire.
That degenerated into a big religious war between the SOAP camp and the REST camp which sidetracked us even further. SOAP versus REST should be a technology implementation detail.