| QUESTION & ANSWER |
Reactivity's Nash: Get ready for the SOA deluge, part 2 |
 |
By Michael Meehan, News Editor
24 Jan 2006 | SearchWebServices.com |
|
|
Andrew Nash is the chief technology officer at Reactivity Inc. He is the co-author of numerous Web services specifications including WS-Security, WS-Trust, WS-Federation, WS-SecureConversation and WS-SecurityPolicy. Previously he was a director of technologies at RSA Security. He has also authored a book on public key infrastructure. Read Part 1
What's the coolest thing XML gear can do now that few people realize or that few people utilize?
Andrew Nash: You can actually do some business logic type stuff in the network. I don't think this is going be the thing that grabs us by the throat in 2006, but I think may be the piece that grabs us by the throat in 2007 or 2008. In 2006 what we may see is people beginning to make some of those decisions separate from the platforms because they can use that logic across many different platforms. That creates a really different dynamic in how you go about creating your applications.
And does any of this rely on the near-term appearance of WS-Policy?
Nash: For 2006 the thing we're going to want to see most of in the Web services space is effective movement on agreement between vendors as to how we actually define policy. That has less to do with standards documents than it might seem. WS-Policy defines a framework for policy. [Web Services Description Framework] is an interesting way to talk about how you define management points and how you use the protocol to send stuff to them. But think about t networking years ago when we tried to do network management stuff, the hard part for all of that was not the intervention rules, even SNMP for example, it was getting agreement about what the hell you had to manage.
So it's the semantic content and agreement about how you pass around interesting things that's difficult, sort of like the definition of what's a useful knob to have or what's a useful dial to be able to read to make this stuff work. In all honesty we haven't been in a position to do this until about now because we're just starting to get large enough deployments to start to understand, for want of a better word, best practices. What are the sort of things that you ought to care about? What are the sort of statistics that you need to be aware of? How would you like to use a checkpoint to protect backend systems and how would such a checkpoint handle peak loads? It's really the whole topic area of what do you manage and how do you do it.
Reactivity has been working with people like AmberPoint and Systinet, for example, to begin to define some of those common policies that you can begin to share between say Web services management components and the operational management and infrastructure that we play with.
Given your point of perspective into the SOA marketplace, is there anything the software companies are doing that you wish they'd stop immediately?
Nash: The most interesting thing I wish the software guys would get their act together on is Binary XML. At the XML2005 conference I saw a roundtable which had Microsoft, IBM, Sun, Oracle and two other vendors talking about Binary XML and basically what they said is, "We're not going to do it." It's too hard. There's too many issues. We can't work out how to make it backwards compatible.
Yet the reason why I think it would be incredibly valuable is the piece I would most like to add to our appliance is, with the processing that we currently do, I would like to be able to handle it all and ensure that what was passed back to the application was a small-piped, pre-processed sort of structure that you could open without all this SOAP and XML-parsing that you need to handle it at the moment. We can already do a certain amount of that, but if we could turn it into a binary format that was small type and very easily processed, it would be a great step forward. Please give me only like two types of mediation to do instead of 10.
If you and your competitors are racing toward anything at the moment, what would it be?
Nash: In this space, we pretty much have most of the technology you need to do this stuff right at this moment. The grail for us is not so much the technology, it's really a case of in 2006 what we're looking for is people using the technology they've had available to them for the past two or three years and taking the size of it.
Though we're starting to see some big SOA deployments are they necessarily good deployments? Do size and quality travel arm-in-arm in this space?
Nash: When you get asked the question of "How do you know you've got a good SOA?", the trite response is "Unplanned reuse." You know, that you're using your Web services in way you didn't expect to. But I think just the number of the services is not going to be a sufficient metric. What I have found with most of our customers is that if they're successful with the first half dozen that they roll out they almost invariably want to do a bunch of additional projects in the same area where they want to repeat the same process. So I think it has to do more with scale. It's one of the reasons I'd like to see some bigger deployments so we can get onto the next maturity wave, but from an SOA perspective just having a large number of Web services doesn't help you if no one's going to reuse them.
What you should care about is how quickly can you get your next internal Web service up and running? And what are you trying to do with your external customers? As browsers begin to natively provide XML interfaces and the client-side applications begin to implement that, what's about to happen in many cases is a hell of a lot more XML flying around the network in 2006. So now everything becomes much more interesting – the need security, the need to do automization, the need to deal with effective processing for XML, the need to be able to handle privacy. All of a sudden we're going to have a deluge of players that didn't have to be smart about building an SOA or Web services that are going to be using XML and Web services and you're going to need to come up with a uniform way of handling them.
We're seeing a lot of vendor consolidation in the SOA space of late, is this a good time to get snatched up?
Nash: You always want to look at the analog historic cases for other types of technology development when you consider these things and one I tend to look at is load balancing. Microsoft and IBM, at around the time that F5 was our size, acquired load balancing companies. Well, where are those guys now? The point is that F5 is actually a large and successful company whereas the companies that were acquired by the really big guys aren't even talked about anymore. So simply being acquired doesn't guarantee success for you or the technology you're dealing with.
The second part is that at the time the big guys are starting to acquire this stuff it's an indication that the market is really starting to get big enough to be interesting. It means there's more potential opportunities for revenue. In all honesty, this is the best possible time to be an appliance vendor. We've proven over the past three or four years that we can do this stuff and now the big guys are acknowledging they're interested in the market as well.
|
|
|
|
