Web services pioneer Boubez on SOA development

Interview

Web services pioneer Boubez on SOA development

Michael Meehan, News Writer
You helped build the foundation for what we call Web services, but you're not a fan of some of the terminology. Why is that?
Toufic Boubez
I've always been reluctant to use the term Web services. It's something we came up with when I was at IBM and I always thought it was a misnomer. Which one do you want me to take: the "Web" or the "services" part? The implication is that there's a technology that needs to happen over the Web. To me it isn't about any particular technology. It's about how you build systems. Inside of IBM it was always the SOA project. It was [about] how you build flexible architectures and flexible systems. While we are talking about services what I find objectionable about it is more around nomenclature and semantics because a lot of people in those days, in the late 90's and early 2000's, when people were thinking about services on the Web they were thinking about creating Web sites with services on

    Requires Free Membership to View

    Login

    When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSOA.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSOA.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

them. This was the implication that was hard to get over in those days. What don't you like about WSDL?
All it is, and I don't mean that in a bad way, is a glorified API [Application Programming Interface]. It's an IDL [Interface Description Language], nothing more. We had them in CORBA. We've had them forever. They are required. They're a necessary component of any kind of distributed architecture, but they're the lowest, most uninteresting part of a distributed architecture. The IDL is sort of the lowest you can get in terms of bits and bytes. Let's do it, get it done and that's it. Not to take away from the importance of an IDL. Like I said, it's critical. It's actually a necessary component, but I think a lot of hype has been put around it as a Web services description or definition language when it's not. It's an API description language if you want.

WSDL is being fixed in version 2.0, but [I ranted early] around how unclear it was. The concept was you could have an abstract description and then lots of different visitations of that API whether different endpoints, different addresses or even different transports for the same API. In practice, the way WSDL was written originally would not allow you to do that. You would have to rewrite the WSDL every time. All of that is being fixed. So WSDL has gotten a lot better, but it's still only an IDL. Regardless of how well it executed was it important to establish the concept that APIs should be open and not proprietary?
Yes, we learned from other attempts that it had to be a standard, interoperable IDL that everyone could use. Though this brings up another point of contention with WSDL. It's not WSDL's fault really, but it's the fault of the people who are building tools for WSDL. What has happened a lot in the last few years is that you have tools that allow you to write code, whether it's Java, .NET, C#,and then click a button and generate WSDL out of your code, which is to me an abomination. How can you write an interface after you write the code for it? It absolutely goes against everything you learn as an architect, everything you practice as an architect. You have to build a robust interface that's not going to change and then you write the code around it because you might want to change your code later on, but you better not change your interface. Unfortunately the opposite has been happening everywhere because of the tools and it's led to a lot of misuse of WSDL. What do people need to start thinking about in terms of making SOA work?

For more information

Read about IBM's acquisition of XML networking vendor DataPower

Learn about the latest standards to make their way into the public domain
Aside from what I've talked about in terms of standards, I believe some people are stuck in the request/response model, client/server, RPC [Remote Procedure Call], whatever you want to call it. To me, that's a little bit disconcerting. One of the things people need to start looking at and thinking around is how do I architect systems that are not necessarily request/response systems, but have more flexibility in them and more asynchronicity. That to me is one of the major hurdles we need to overcome in terms of best practices for SOA. With the entrance of companies like IBM and Cisco in the XML networking space, what's the upside and downside of having some of the big dogs in your yard?
There's a lot of upside to me as a vendor. It validates the space. I know there's enough business in it for not just the small vendors, but the bigger ones like Cisco too. The other thing is that, as an architect, I believe this is great because all of a sudden the whole concept of a network appliance has become a commodity. It's something I've been saying for the last two years: the end aspect of it is going to be a commodity. So [that's] fine with me because that's not where I believe the important thing or the money is. To me it's all about how you build a layer for policy infrastructure and policy management, policy publishing, policy coordination. That makes the whole SOA thing work.
Back to top