Summary: A transcript of Omri Gazitt's video What is Microsoft doing with Web Services?

The original video can be found here: http://channel9.msdn.com/ShowPost.aspx?PostID=34980

---

00:56
Omri Gazitt: So, I think at the bottom we have XML. The Infoset . There could be alternate encoding to the XML. The key here is you have a consistent data model.

You have things like, below here, you may have different transports. So this would be the transport layer. This would be the data model layer (XML). So you may have HTTP here, which is a very popular transport for SOAP. You could have TCP, you could have other things as well. (? 01:37) and people to have other bindings for SOAP into these things. We introduced one called UDP Binding. It lets you send a SOAP message over UDP datagram. It's a useful thing to do sometimes.

We have above that the messaging layer. And here we have things like SOAP, things like WS-Addressing. This layer basically kind of provide you the framing. You can also probably put MTOM in here because MTOM lets you put attachments -- attach large binary objects to the SOAP envelop in a way that's composable with (? 2:25).

On top of that, we typically like to draw it this way. You have metadata that sits up here. We have things like WSDL, WS-Policy, Metadata Exchange. And these things are kind of interesting. If you're a COM developer, this (WSDL) is IDL, that's all it is. This (WS-Policy) thing is, you know the TransactionRequired attribute in COM that says use a transaction for this particular method, that's what this is. This is, you need to use reliable messaging to talk to me. This is, you need to use security, both integrity and confidentiality, need for both sides to encrypt the message. Oh, and by the way, you need to use these particular token types and and this particular key length.

So things that aren't really expressed in IDL, sort to speak. They're not about how the message looks on the wire. They're about what kind of things I need to do in order to properly be able talk to you. Kind of a higer level than just operation syntax.

And Metadata Exchange, again, if you're a COM person, this is just IUnknown QueryInterface. This is, what do you do? Like, tell me about yourself. What kind of interfaces do you support? What port types do you have? What bindings do you have? And in fact, these things are, effectively, communicated from the service to the application developer through this protocol, Metadata Exchange.

Then on top of that we have what we called the Assurance Level. You can circumvent all this thing. So there's Security, there's Reliable Messaging, there is Transactions. And here (Reliable Messaging) would be WS-Reliable Messaging. Here (Transaction) would be WS-Coordination, which is nothing but a extensible framework for coordination types. And the most important one being atomic transactions (WS-AT).

And Security has things like base message level security (WS-Security). Things like WS-Secured Conversation, which is TLS for SOAP. It's basically having long running session with another service. You need to have a conversation or session. There's something call WS-Trust, which is kind of a somewhat mis-named spec or unfortunatedly-named spec. All that is is, hey, I want to be able to trade security tokens with you. I have an identity, a Kerberos identity, but I know I need to talk to use using SAML identity. There's some third-party trust broker out there that knows how to translate my Kerberos identity into a SAML token for you. This is all that is. This is request security token, get security token back. So, it's almost Metadata Exchange for security tokens, if that makes sense.

Then there are things on top of all of this -- like there's application-level protocols, which we will draw way up top here, App Protocols, and we have plenty of those. We have things like WS-Federation. So, this allows you to use single sign-on over the web using a combination of these things like Trust, Conversation, Addressing. There's another one called WS-Management, and this one, basically a way to go use again all this protocol framework to go be able to manage hardware or software. There's another one called -- there's actually -- there's the Windows, the (? 6:57) Windows Printing Protocol that's built on top of this whole thing. So we're starting in Windows, in all of Microsoft products, to go, hey, we need a new protocol, it probably ought to be based on SOAP. So, in the same way that managed code is one of those tools in people's tool belt right now, where they say, hey, we're going to build a new piece of operating system, or a new piece of Office, or something, that tool's kind of a cool tool. It makes me more efficient, more productive. Should I use it? Probably. You know, here's the pros, here's the cons, I'm going to make an engineering decision and do it. But, more often than not, you find that people are drawn to managed code as a cool, efficient new tool. Likewise, we have so much infrastructure now built around this set of protocols, a set of protocol framework, that people, naturally, want to go build their next generation of protocol on top of this stuff.

And there's actually another link here, just to be complete, which is, I would call this common patterns, Common Messaging Patterns. That we decided that would be useful to go, that really sits on top of this layer right here (Messaging). They're independent of the Assurances. So, things like WS-Eventing, this is basically nothing other than, hey, in the world, there exists solicit-response kind of message exchange pattern. I send you a subscribe and you start sending me notifications. Let's go write down what a subscribe message looks like. And so, things like WS-Management use that.

There's something called WS-Transfer, which is nothing other than just HTTP for the web. It's great to have verbs like GET and PUT and CREATE and DELETE, you know, the CRUD kind of operations. Just write them down so that people don't have to go and re-invent them every time. So Management, clearly, when you want to manage a resource, you may want to get its state, you may want to set its state. So, it uses WS-Transfer for those kind of things.

And we have other kind of common patterns that we've written down, just so that other people won't have to do it all over again.

Channel 9: Looking at this board, I see a lot of complexity. I see a lot that developers on this: Oh man, I have to spend the next 3 years of my life learning all these different things. Is that what Indigo is going to trying to solve for the developers to make this whole board easier to adopt.

OG: Exactly right. I think that all the vendors recognize that interoperability is going to be achieved by doing this. But as I said at my PDC talk last year, the best thing about this talk is that none of you would have to know anything that I have talked about. Only maybe a dozen people in the world will have to really kind of understand, these specs, their full complexities. Understand exactly how to implement each and everyone of these things. Because vendors will have frameworks. We will have support of this in the .NET framework and we call that little piece of code Indigo. IBM and Sun and BEA and others are planning to do the same thing. Many of them, most of them, obviously, already have SOAP implementations. A lot of them already have double Security implementation. Most people are starting on Reliable Messaging implementation. IBM announced that the have AT (atomic transactions) now in the next version of WebSphere. WSDL has been popular for quite some time, so a lot of this stuff now, in real time, finding its way into the core platform products that platform companies like IBM, Microsoft, BEA, and Sun are putting out.

So, we feel pretty good about that -- we'll be able to shield the complexity from the developers. Back to my point about frameworks, I must have the framework picture here somewhere. I wish I did, because if I pulled it out for you, we should just go into somebody's office and take a look at it. If I pulled it out for you, you'd have more boxes, more little names of classes by far than anything you'd see on this board. So we think this is at the right level of complexity, we're actually doing something substantial here. I mean, we're putting together a set of frameworks that will sustain an architecture well into the future. And if you look at all those class libraries that you see on all those posters, there's probably an order of magnitude more things that are written down. But again, you don't have to know about all of it. The nice thing about the Microsoft development environment is you have tools that help you cope with that complexity by helping you drag a control onto a form and viola, a lot of the stuff is set up for you -- then you start writing just logic.

C9: Whenever a new platform comes on, and this is a really new platform. This is like, the MacIntosh, the Windows 1.0. What's the killer app? When we wake up one morning, and we read eWeek or InfoWorld, what is the new app that's going to come along that's built on this platform that we don't have today, or it's just so hard to build?

OG: It's a great question and I think some of them you already kind of seen. So Atom, for example, is the syndication format that Sam Ruby and others came up with. Atom builds, basically, on top of this (SOAP). The SOAP thing, and the WSDL thing, and has something that looks like WS-Transfer. Whether it actually ever adopts WS-Transfer or not is actually not that big of a deal. You're seeing people build application protocols based on this today. Atom is a very popular syndication format and Tim Bray believes that it'll overtake the rest of them. And so, our blogosphere is going to be built on top of web services.

Things like single sign-on, web single sign-on, are killer apps for this particular space. And not just browse space, but really kind of full, rich client kind of applications that I can federate single sign-on across different companies, different trust domains. If you think about the complexities that people have to face with today, I have a set of users, and now if I want my set of users to go and kind of access resources in your system, you have to know about all my set of users. What if I fired someone? What if they quit? Now you need to know about that, you need to go erase them out of their database and out of your database and so on. So, this idea that you may want to go extend your reach of your users into some body else's network and some body else's trust domain -- it's kind of an important, it's critical part of today's business and yet, we don't have great ways of doing that today. And we think that web services is going to be a killer app for that.

So, I think there are many kinds of domains where you're going to see web services and protocols take off. Now, in the end, I think the thing that -- you may actually say that but Omri, we have protocols for all this today already. Maybe not Federate yet, but Management, we have SSMP, we have all this stuff. What's new about SOAP? I'll tell you what's new about SOAP. It's the fact that everything is self-describing and I can go do an "Add Web Reference" on you and just be able to go program to it -- using strongly typed proxies. I have a unified programming experience for everything now. And that's the vision. The vision is, eventually all of Windows will become that kind of -- will become exposed using that kind of methodology. I now have a metadata-rich environment, where I can go aggregate a certain component of the operating system to talk to it. One of the coolest demo in last year's PDC was, you went and talk to the actual task bar, you know, the little bar on the side of the Longhorn shell, and you add things to it using web services. You got the WSDL for it, you generated some proxies for it. You went off and say, put a new gadget in that particular window and here's what it's supposed to do and it just worked. So everything is programmable in a uniform manner. And that kind of uniformity is what will kind of fuels developer productivity in the next wave of applications.

C9: How's business going to change? Are we going to see some fundamental shift -- the way we saw when the PC got into the business? I've seen the pistacchio factory run on a set of TabletPCs.

OG: And those are pretty big shoes to fill. I don't think that this particular architecture will usher that kind of change. I think that it's going to be a little more subtle. I think you're going to see that it's going to become inherently easier for businesses to integrate functionality, integrate process across each other. And over time it will lead to, kind of, a more efficient, digital enterprise.

So, today, you have e-commerce happening today between businesses, clearly. You got big auto manufacturer that has 50,000 suppliers, and the suppliers are in charge of making sure that the inventory for the auto maker are exactly supplied right and replenished at the right time and we have systems today, and they work. But they're so britle and expensive. Auto manufacturers, they take a piece of software and a piece at the computer and put it in the supplier's office, all 50,000 of them. Because they need that, like, today, the only way to do things is tightly-coupled. Whenever they change that centralized computer, in that auto manufacturer, all the suppliers have to change their software. You have to ship new PC's to them. It's just amazing. It works, but, it's amazing it works, but it's hard work. And think that, for that auto manufacturer, sure, they can save a lot of money, by having a more inherently loosely-coupled way of integrating the system, and having things like federated identity, that doesn't require them to keep a user account for every one of those supplier and things like that. But is that going to change the world in a significant way? Probably not for that application, but it's going to enable a wealth of other applications just like that one that were previously too expensive to build.

C9: If some MVP's were here, developers were here, what would they say (? 18:41) on Microsoft vision.

OG:: Hell, yeah! That's interesting.

C9: Because, you just gave the Microsoft vision, right?

OG: They would ask a few questions. They would ask, for example, is all this really neccessary? A lot of people who gets stuff done with HTTP and XML. That's actually one of the big debates, technical debates, in the community. Between something called, the movement that people often called REST. It's named after Representational State Transfer, which is Roy Fielding's terminology for the architecture of the web, of HTTP, and the SOAP model. It's kind of interesting. At Microsoft, we never quite understood that controversy, because we've always thought about this whole model as a pay-as-you-go model. At the very bottom, there's HTTP, so you need that. You need XML. You need that, too. And on top of that, if you want to, you can put a little SOAP envelop. Now, all that SOAP envelop is, beyond this XML that you send back and forth, a tag called SOAPEnvelop, a tag called SOAPHeader, and a tag called SOAPBody. If you actually partition your XML that way, you basically just wrap it. You put that payload you previously had just laying around as the root element, you put that in the body tag. All of a sudden, you can scale up to a lot of other kinds of capabilities.

If you want to do security that's message-based, later on, for example, one of the big difference between the message-based security and TLS-based security is with message-based security, I can actually keep the message around, and it's still encrypted, after I'm done with a particular session. That kind of longevity on security of the messages is kind of important for e-businesses. It really is. And so, if I ever want to do that, the fact that I ate this little thing called SOAP, is well worth it.

If we see an XML datagram without a SOAP header, we just kind of process it. If we see the SOAP header, we process it, too. It's like an "if" statement. You know, code. It doesn't really cost us a whole lot to support this. And we think that actually buys us a whole lot, too. So, you know, it's worth it. Like, we want to support all this stuff. And once you start to support SOAP, you can get start paying-as-you-go. You can say, hey, now I want some of this other stuff. I think that some of this other stuff is kind of important to me, but I don't need to go swallow it whole. That's in some sense, the biggest difference between this framework approach and the DCOM / CORBA approach -- which is a big monolithic protocol and you kind of have to eat it all up or have none of it.

C9: What does Microsoft get out of this? In other words, why should I help Microsoft get richer by adopting, help you get your pay check?

OG: That's a great question. I'll tell you what Microsoft gets out of this. In the end, we want to sell software. Our customers told us "we have software from other people, too. And hardware, by the way." And we go $#!+. But you know, at the same time we go, that's life, OK, maybe you buy from other vendors, too. Seriously, the more we reach into the enterprise, the more we realized how heterogeneous the environments are. Hence, doing this, for Microsoft helps us be able to sell more of our software to that space. And it's something our customers just demand of us. He says, hey, I have a J2EE environment today on the server. I would love to bridge clients out there except a little detail. All that stuff runs on some other vendor's platform, and your stuff runs on Windows. Can you make it work for me? If you do, I'll write more rich client applications. Yeah, that makes sense, we'll do that. And even more importantly for us, on the server, as we ramp up our enterprise server offerings. It really has come of age in the last few years. Nobody in the world, these days, does not take Microsoft server products seriously, which was not true, probably, 5 or 10 years ago. It's even more important to integrate with glass house kind of operations, which has been in operation for 10, 15, 20 years and will probably continue to be in operation for that long in the future. People don't rewrite those systems very often, and so you have no choice other than to integrate with those things.

And so, this is kind of, in some sense, a maturation process for Microsoft where we've recognized the world is heterogeneous and we want to play in that world. It is important, though, that we believe that interoperability is achieved on the wire. And people ask us why don't you adopt J2EE or things like that and our answer to that is always we think that we actually have better developer frameworks. We can make Windows developers more efficient by having our developer frameworks target Windows in a very deep and rich way. So we're doing our developers a service by offering all that rich functionality, and we offer them a lot of tools, we offer them a lot of languages, we offer them a lot of choice. And by integrating with all these other systems, we offer them the last thing that they want, which is being able to work with the stuff I have today.

So we think it's a pretty good, pretty strong story for developers. And in the end, whether you buy into this or not, that's not going to make Microsoft rich. Microsoft is not looking to make money off the protocol architecture. We think that indirectly, it's going to help us sell more software, and that's why we're doing it.

You know, the other, kind of more subtle reason we're doing this is our customers are dealing with complexities all the time and we try to help them. We ourselves are dealing with a lot complexities, too. I mean, Windows has tens of millions of lines of code in it, so it's a pretty big program. And it's hard to go evolve that program, and if we have an architecture that let us componentize Windows in such a way to be able to deal with that complexity, contain that complexity, that makes us be able to be a little bit more nimble. So, we invented this particular architecture along with our partners for the entire world. But we're included as one of those vendors that is going to benefit from having a kind of architecture like this -- to be able to go build the programs at the kind of scales that we do.

C9: What kind of questions should developers be asking themselves, in this new world?

OG: I think they should be asking, OK, you've got specs, that's great -- words on a piece of paper and the fact that you've go a bunch of vendors on them, that's saying the same thing as great. How do we really know that this is going to be interoperable? And I think the answer to that is -- there's a lot of hard work between now and when we ship the product to be able to get its interoperability. I think that's one of those things you constantly strive for more and more.

C9: Are you going to have Interopfest where you invite people up here?

OG: Great question. So, indeed, we are.

C9: There's a (? 26:43) Interopfest going on right now (? 26:45)

OG: Exactly. So, that's kind of the way you do it. You can go code that stuff, but in the end if you don't have these things talking to each other in the lab before you ship them, you won't get the interoperability. So, part of our workshop process is having this kind of Interopfest where people bring in their implementations. That kind of stuff started with SOAP builders. That was kind of the initial community for people who build the SOAP stack and people used to get together, either in person or on the internet, and just kind of interop test their stuff together. And that was very successful for making SOAP real, and we're basically doing the same thing with the workshop processes. And as we mature Indigo, we'll start to bring Indigo into those workshop processes and, likewise, we're going to end up working one-on-one with a bunch of different vendors to make sure that, you know, to work out the tweaks, to work out the kinks here and there that develop. OK, you interpreted the specs this way, we interpreted that way. Split it down the middle, we'll do what you're doing here, you'll do what we're doing over there. In the end, it's a game of give and take and we'll end up with something that's interoperable. I think what developers can do to make that process as expidite as possible, is kind of demand interoperability from their vendors. They're doing it with us, we're answering the call.

C9: What's the agenda for between now and September, when the next PDC is? What should developers be looking at, learning? What would you hope that they would know coming into the PDC so when you have a conversation with them, you can have a good conversation.

OG: I think that looking at the ASP.NET web services stack today can be very informative for people. Because that kind of service-oriented, loosely-coupled model for development is what we think Indigo is going to push you towards, that's going to be the sweet spot, right? So understanding that set of technologies is a very important thing. You can start building a service-oriented app using .NET framework 1.0 or .NET framework 1.1, Visual Studio.NET or Visual Studio 2003. You can do that today and you can start adding more features, you can start exploring with this space by using WSE, the web services enhancement products that we have. So we have technologies today that are fully supported that let you build these kinds of applications. I think PDC is going to be the big Indigo, hoo hah, coming out party. We're going to be all excited to show the next generation of the development frameworks and how we're able to take all of these things and integrate them into 1 framework, so not just ASP.NET and WSE, but also .NET Remoting and MSMQ and COM DDC. All these things are kind of merging into a single development framework called Indigo. If you're a user of one of those things, I think you'll be very excited. Or at least, I as a former user of all those things, I'm very excited about being able to use that thing in my apps, not just being able to build it. Because, in the end, I have 1 framework that doesn't have me fall off the cliff. With MSMQ, I love the message-oriented approach to things, but does it let me do some of the other things that I would really like to do. For example, I have a very easy programming model, an actual (? 30:30) programming model that say, hey, add reliability to this. Does it give me "Add Web Reference" where I can just get all this rich metadata over -- for the other service? No, it doesn't. Likewise, with ASP.NET, does it give you secured, reliable transacted today? No, it doesn't really. So, integrating all these assets together is going to make it very easy for developers to pick what actually they're going to do. They won't have to pick between all these vulcanized different technologies. So, I'm, personally, very excited about that.

C9: Awesome. Well, thanks for spending some time with us and explaining to us this wonderful world of web services and we look forward to seeing you next year at PDC.

OG: All right, sounds good. Thanks Robert.