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?
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?
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.