| QUESTION & ANSWER |
Web services pioneer Boubez on SOA development |
 |
By Michael Meehan, News Writer
24 Oct 2005 | SearchWebServices.com |
|
|
Toufic Boubez is the chief technology officer for XML networking vendor Layer 7 Technologies, Inc. Previously he served in IBM's Emerging Technologies Group back when that group helped to build the foundation for service-oriented architecture and served as its lead Web services architect, publishing the company's first SOA toolkit. He is also the co-author of UDDI specification and other emerging Web services standards. In Part 2 of a Q&A, Layer 7 Technologies chief technology officer Toufic Boubez addresses architectural misconceptions about SOA and explains why he considers some WSDL tools an "abomination." Part 1You 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 them. This was the implication that was hard to get over in those days.
What don't you like about WSDL?
Boubez: 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?
Boubez: 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?
Boubez:
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?
Boubez: 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.
|
|
|
|
