| QUESTION & ANSWER |
Web services pioneer Boubez on SOA hardware and policy |
 |
By Michael Meehan, News Writer
21 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, helping 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 one of this interview, Layer 7 Technologies CTO Toufic Boubez makes his case for why SOA will require new-breed networks and expounds on the importance of policy. Part 2Why do you think the network approach to SOA will eventually supersede the middleware approach?
Toufic Boubez: Don't get me wrong, I do believe there's room for middleware in infrastructure. By definition, middleware exists because you've got two endpoints and you've got something in the middle. There'll always be something in the middle. If we define it a little bit more restrictively as software or a specific approach to solving distributed computing, then I believe a network-based approach -- I don't want to use the word organic or holistic -- but from an engineering perspective it scales better and is a lot more robust. Two examples are the Internet and the whole concept of TCP/IP, where there's no central repository for these things. It's very, very distributed. It's very localized in certain aspects, too, and therefore very robust and scalable. What we built in terms of the World Wide Web began with the same type of concept. There's no quote/end quote 'middleware' in the Web. It's network oriented.
I want to also use the example of peer-to-peer. Though it hasn't caught on yet as much as I'd hoped it would, it's not because of the technology. It's more for legal issues than anything else. Things like Bit Torrent are alive and well in spite of all of the hurdles that they have to overcome. It's a distributed model that will happen. The whole process of service-oriented architecture is to be able to build these kinds of flexible, robust, scalable architectures. And robust is an important term. A lot of people concentrate on the flexibility part, which is a good thing. As an architect, you build things that are flexible, but I think the robust part is sometimes forgotten. When something breaks or we want to change something, I don't want to break the rest of the system. When you have a piece of middleware in there, where you have to write rules that are pretty much static or you have central control points, the robustness goes away.
What more needs to come out on the network side of things to make it fully SOA capable?
Boubez: I believe we have a very good foundation. Things like SOAP, WSDL and UDDI, that's there. The next layer is WS-Security and I believe we're fine there. The next layer around that is reliable messaging, which is an extension of security to create sessions, WS-SecureConversation and things like that. Just as a disclaimer, I'm a co-author of WS-SecureConversation and WS-Trust. I don't want to be seen as an impartial observer, but I do believe we are required to have the concept of trust and the concept of extended sessions, so we don't have to carry credentials every time we have a longer conversation.
What is really sorely missing is the glue or the flexible layer around, which is the policy. Think of SSL [Secure Sockets Layer]. SSL took the Web thing from an interesting thing to look at your grandma's pictures to something that you could actually do business on. If you look at the underlying infrastructure, it's based on this sort of awareness or acceptance that browsers and servers have different constraints, different capabilities. How we make them work together is by negotiating parameters for a session. That brought us to the SSL handshake. The SSL handshake is a conversation between a browser and a server around their individual policies. How can we reconcile our policies to get something that's acceptable to both? That's under the covers, nobody's aware of it, but it works.
That's just an analogy, but if you think along those lines, I think something similar to that needs to happen in Web services. It's got to be around policy. It's policies for producers of services and policies for consumers of services, so we can have this sort of automated machine-to-machine interactions. Without that, I think we're going to be stuck hand-coding a whole bunch of that stuff for the foreseeable future.
What sort of specific policies are we talking about? What things have to be encapsulated within a policy framework?
Boubez: Anything from low-level things like security parameters -- what kind of credentials do you accept, do you take any kind of credentials or do you only want to deal with X509 token profile -- to things like do you have any preference around transport or message. Is HTTP OK or would you prefer that I use JMS [Java Messaging Service] or do you want some kind of reliable messaging. I believe, and this is where I might disagree with some of the policy authors out there, things around even versioning, what versions do you accept of this particular API, what kind of transformations and so on. These are all required to enable interaction. Maybe you'll also want to talk about the semantics of the API.
There's another aspect to policy that gets overlooked and that's internal policies that you don't necessarily transmit to the outside world. Internally, I want to be able to configure my systems around policies that deal with access control, that maybe deal with conditional or content-based routing. This is where the policy mechanism becomes very, very powerful. For example, I'm dealing with multiple suppliers, but I'm buying the same kind of things from them. But each one of them has their own version, their own schema of what a purchase order is. Now I'm stuck having to deal with everybody else's purchase orders. I don't want to do that. All I want is to have my own schema and deal with it on my own. This is where things like runtime policy and runtime transformation becomes very powerful.
How far off are we from getting the framework for these kinds of policies built?
Boubez: I think we're far off if you look at standards bodies. We're only starting to talk in the public domain about security policy and reliable messaging policy. WS-Policy, the framework, as a draft has been out for over three years. I've been using it as a baseline for my work, but I don't see it anywhere in any standards body. It's been three-and-a-half years now. That's the frustrating part. That said, on the implementation side there are companies that will let you do it ahead of the standards, Layer 7 being one of them. There are others out there that are talking about policies. Systinet is an example if you want to start putting meta data around policy in UDDI. Vendors are saying enough is enough, we actually are going to start working with this stuff because it supports our customers. The problem is, are these things interoperable? Currently, they probably aren't except at the lowest, lowest level with a security policy or a reliable messaging form.
|
|
|
|
