Columns

Q&A: SOAP gains traction

• By Jack Vaughan
• August 29, 2003

Q&A with Rebecca Dias, Microsoft

Q: In the last year, interest in Web services has revolved around Service-Oriented Architectures. What’s the status of interoperability between Microsoft’s .NET and IBM Java?

A: There’s a great deal of traction in terms of just general SOAP message processing and interop, and that goes across the board. Actually, it’s more than just IBM and Microsoft, it’s the Java world as well as other worlds that exist out there. There are Lisp implementations, for instance, that are finding interop, as well as WSDL and the WS-I basic profile they’ve defined. There are about a 100 partners, if not more, collectively collaborating on profiling how you do interoperability of SOAP, WSDL and the basic Web services protocol. There are also numerous implementations deployed based on that interoperability.

There are also a lot of implementations that are starting to use some of the advanced capabilities that fall in line with the greater vision of the Web services architecture, where you can do true enterprise distributed computing with reliable messaging, security and transactions based on the Web services architecture. And there are lots of deployed systems that are leveraging security aspects of that architecture. WS-Security has been very successful, and I think the next stage [will be] more scenario usages of security interop, starting with policy and then the different reliable messaging infrastructures.

Q: Web services at first seemed to be a combination of SOAP, UDDI and maybe WSDL, certainly an implementation of XML. Some now say that you can have Web services without SOAP. Is this about different binary communications? What is your take on that?

A: I think it’s important to not try and steer away from a definition of Web services. Web services’ primary function is to try and build highly interoperable, loosely coupled, heterogeneous systems, which starts to give that vision of building a Service- Oriented Architecture. The key to that is the meta data provided to you in the different SOAP headers, so SOAP is very quintessential to that. If a standards specification comes out that defines a different way to do the encoding that is highly and widely adopted, there’s no reason why that can’t happen. But today, the spec is still SOAP and XML meta data.

If you have two intermediaries that are intelligent, that understand and know that the next intermediary hop happens to be in the same technology domain, and knows that we can actually do some kind of binary format from here to there, there’s no reason why that can’t happen and why your corresponding infrastructure can’t support that. And if it ends up going to the next hop, which happens to not be potentially aware or know how to deal with that binary format, those systems had better know how to translate that back to SOAP, otherwise you’re losing the whole value of a highly heterogeneous, interoperable system.

Q: What are the goals of Web Services Enhancements (WSE) V2?

A: The primary objectives were to track the specifications in the security domain of the Web services architecture, the messaging domain and policy. Policy is part of the meta data infrastructure, which helps to describe assertions that you place on different Web services. We’ve implemented a security policy where you can actually declare that this service endpoint requires that messages be sent to it encrypted and signed with X509 certificates. On top of that, we wanted to supply the baseline infrastructure for messaging, so we’ve actually implemented WS-Addressing, which is the core messaging specification in the Web services architecture. You can look at WS-Addressing as being equivalent to what WS-Security is for the security infrastructure. WS-Security is a baseline spec.

Q: And it allows you to use TCP transport and forgo the use of IIS or a Web server?

A: WS-Addressing is the specification, the protocol in terms of how you do asynchronous communication and correlate messages coming in and out. To enable different types of usage scenarios for our customers -- for instance, if you wanted to build a peer-to-peer infrastructure -- we actually added a TCP transport. That’s not per se part of the specification of WS-Addressing, but it facilitates different usage scenarios of implementation. TCP is something we support and that really enables the peer-to-peer type of infrastructure. And you don’t need to have IIS to host the Web services.

Q: In terms of policy, it could be said this supports a declarative programming model. Could you expand on that?

A: If you think about it, you can either program and write code that says “Do this with information,” or you could author something that tells the runtime environment to do it for you. If you write code, you’re actually manipulating and doing things yourself, whereas in the declarative programming model, you’re telling it what the runtime will do for you.

In essence, you can author a policy that says, “I want the WSI runtime to take care of doing authentication and authorization for this Web service and ensure that this user is within this group.” Basically, you can author a policy relative to that and change it at runtime so that it dynamically gets loaded in and the policy for how that Web service might be accessed can change on the fly, and the WSI runtime will take care of the security legwork for you.