In this first of a three part Q&A interview with James Bryce Clark, director of standards development for OASIS, he talks about the turning point for service-oriented architecture and related standards that he sees coming in the New Year as the technology moves from concerns about plumbing, i.e. messaging and security, to more high-level business issues, such as the semantics of business content. Read part two and part three.
What's the biggest change in standards impacting SOA that you've witnessed in the past year?
In 2006, we finally started moving away from concentrating on the plumbing layer. We're moving up the stack of standards and electronic commerce methods and data representation to the content. For the last five or six years, people working this space – the Web services people, before them the ebXML (Electronic Business using eXtensible Markup Language) people – we were always concentrating most of our effort on the old ISO model called the "functional service view," which is the messaging, the database calls, the security, basically the plumbing layer. And we weren't getting up into semantics. We weren't getting up to business message content. Robust e-commerce requires a tremendous amount of reuse and exchange among a broad variety of uncoordinated entities. You not only need to send each other messages and have security and control around it. You also need to be able to consume the stuff each one is sending. Now, we're finally starting to see a reasonably smart number of well-known methods for registries and directories and messaging and security jell. Are these standards mature?
I'm not saying there's one winner in each field and it's all done. That's not true and that's not the way standards work. Standards take a large number of potential candidates' options and winnow them down to a smaller number of reasonably appropriate consensus methods. There's still the marketplace to consider. A standards organization at OASIS or anywhere else can come up with a great idea and bless it. But what if people cannot use it? So when we're done, the market isn't necessarily done. Nonetheless, several perfectly good, mostly stable and approved standards exist. There's UDDI (Universal Description Discovery and Integration). There's ebXML Registry. There ODBC (Open Database Connectivity) and JDBC (Java Database Connectivity), so we know how to get things in and out of databases. There are a number of rendering methods now, all the fun stuff that's happening with Ajax. We kind of know how to get data up and out of our transactional systems into places where humans can interact with it. And there's a lot of progress on security. We have SAML. We know from practical experience how to handle secure sessions. The use of certificates has started to become smarter. The security issues are beginning to be solved reliably as well. So what does this mean for business?
If you're trying to do something commercial today, you can actually do something you couldn't do a couple years ago, maybe not even at the beginning of this year. You can say, "I want to make this kind of information available on the Internet to these kinds of people to do this kind of business. I know how to get the message back and forth. I know how to resolve duplicates. I know how to get acknowledgements and handle them dynamically. I can buy software. There are open source options. Even if it's not standard, if it's Java messaging service (JMS) or MQSeries, I don't have to invent that stuff because somebody's done it for me. I know how to get it in and out of databases. I know how to apply a certificate to it. I know how to describe the attributes of the individual who is receiving or sending stuff, so there's security around it. I have access control. All that's solved for me. I don't have to worry about that." As of the end of 2006, that's one of the things I was grateful to Santa for, our users don't have to fret about the plumbing because of the things that have been developed commercially and in open source have solved those problems. Now we're moving up the stack. We're seeing more activity in the business content layer. Which standards made the difference this past year?
In the area of database manipulation the standards are UDDI and ebXML Registry. They do different things but there's a lot of robust usage. In the messaging space there are a bunch of options. There's the WS-Reliability standard, which we've already issued. There's ebXML Messaging, which in version two is widely used in Europe and Asia. There's a committee at OASIS which is moving along at a very brisk clip with WS-Reliable Messaging. This is the one that was donated (to OASIS) by IBM and Microsoft. That work is finishing up and they'll be done soon. It's moving fast enough now that people are confident that it's going to come out as a standard to solve the messaging problem. What about security standards?
In security, for the world that wants to use SOAP, there's WS-Security, which is an OASIS standard that's been out for several years. In fact, that committee is closing now. That's always a happy thing when a committee says: "Hey, we're done." WS-Security as a base spec allows any security attribute or information to be reliably connected via asymmetric key technology to a SOAP message.
The other famous security standard out there is SAML, Security Assertion Markup Language, which is showing a tremendous amount of use. SAML has been out in a stable version 2.0 for awhile. There are also a number of modules that allow you to attach things like a SAML assertion, a user name/password pair. WS-Security tells you how to do that. What we're really seeing now is the number of users who have evolved their business practices where they need security assertions is growing. WS-Security does a fairly simple function of attaching security information to a message. SAML is about the content of what must be communicated and who is communicating it, in order to achieve a security conversation. To really make robust use of that, you've got to have authenticated lists, who is able to see what. You've got a class of information, so you know to what you're applying the granularity of your access control and security. To use SAML and its related standard XACML (eXtensive Access Control Markup Language) you have to have a fairly robust architecture for content being made secure and being made available to some and not others. Three years ago, I'm not sure there were a lot of people doing that. Now, there's tremendous demand for it.
So in the security space the story isn't only that we're pretty much done with the first wave of good, solid, stable standards, but also that they enjoy robust use. There are a lot of use cases that are ambitious enough and complex enough to need that kind of functionality.