Vendor Interoperability

By eweek  |  Posted 2003-10-26 Print this article Print

So do you see things coming together on some of these issues—like WS-Federation versus Liberty, and WS-Reliability versus WS-ReliableMessaging? Rudder: Well, I hope so. I think the most important thing is that there really are vendor implementations that solve real business problems. People forget about that. If people could … Again, given the choice between a de jure standard or vendor interoperability, I think many customers would take vendor interoperability. We should never lose sight of that—that a standard really isnt a goal unto itself. You know, I think in the end we are going to end up with interoperable implementations because I think the customer pressure is going to be so great. And I think standards bodies can actually help us work through some of the vendor interop issues. And standards bodies are expert at resolving consensus issues between vendors. And again they have an important role to play and we absolutely will utilize them. So Im optimistic over time about this stuff working out. And I tend not to focus so much on the standards issue de jour and look at the larger questions on are we really going to keep this industry moving forward on Web services.
And the reason I say that is because there wont be a Web services market unless we have interoperability. Were trying to grow a new market as an industry. And the fundamental value proposition of the Web services market is interoperability. And thats what we really need to keep in mind.
So where would you say we are in terms of the maturity of Web services? Are the specs there and available that we need? And whats missing? We typically talk about where we are in terms of three phases. The first phase was about getting a message from point A to point B. So Level One was about SOAP, about XML, about UDDI. Can I call another vendors implementation with a simple Web service? That work clearly by any account is done. People can really build systems on that. As people started to build systems on that, they said, "Hey, we can really build systems on that!" But you know what? Its hard building systems that require security, transactions and reliable messaging. And that really is Level Two for us—taking the base framework and making sure we can build a secure, reliable, transacted Web services infrastructure. And I think were well on our way to doing that. We made fantastic progress over the last year. Who would have thought wed be able to get the industry together on WS-Security? And I think weve done it. Transactions made great progress, and reliable messaging made great progress as well. I think well finish that up. Then the core infrastructure is in place. Level Three is less about WS-X, WS-Y, WS-Z and more about vendor- and industry-specific profiles. So what does Web services mean for insurance? Or what does Web services mean for manufacturing? Or what does Web services mean for health care? And this means going back and looking at a lot of the good work done in industry-specific standards bodies and really kind of, to make up a word, "Webservicizing" it. People have done great work on schema, but they really havent factored it in relation to Web services. And we have to think about things like HiPAA or HF7 work—we need to think about how Web services impact that work is really the third level. And there I think the technology providers like Microsoft and BEA or Oracle are more advisers to the vertical or specific domain rather than driving the ChemXML standard. So have you done any preliminary work at Level Three? What are you doing? We have worked with ACORD, as a good example. I think weve had good preliminary discussions with lots of groups, and now that were kind of through the Level Two stuff, I do think youll see the work accelerate in that area. Next page: Microsofts plans for Orcas and SOAs.


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel