ERIC RUDDER: Well, good morning, thanks for coming. I think Soma got to do most of the hard work yesterday talking about Visual Studio 2005, and all that encompasses, and I’m here this morning to talk a little bit about what comes even beyond Visual Studio 2005, mostly “Indigo.” Maybe I’ll throw in a few other nuggets of stuff coming beyond 2005 as I talk as well.
As some of you may or may not know, I’ve actually spent the last, oh, six months or so living in Paris talking to customers, and developers in Europe, the Middle East, down in Africa, I got over to Asia, Japan, Singapore. And I’m often asked, you know, hey, you’re living in Europe, you’re talking to all these European ISVs, what’s the difference, what’s the difference in customers, and what do developers want that’s different, and what do IT pros want that’s different? And my answer is sometimes a little bit surprising, because there’s absolutely some regional differences, there’s some ISVs that are bigger in markets that are smaller in other markets, and there’s some key suppliers, and there’s differences in service capacity, but basically I think a lot of the challenges are the same on a worldwide basis. Still getting that application life cycle, getting up and going, getting developers, meeting end user requirements, working with the IT shop, really driving integration across applications, focusing on total cost of ownership, and really delivering business value to the end users, that’s the same no matter where you go.
And it’s tough living in Paris, eating croissants, drinking wine. You may not want to use Visual Studio’s CTP after you’ve had a couple of glasses of wine, I recommend doing that in the evening, it does lead to, god, is that a beta bug. But other than that, I think a lot of the challenges are the same. And a lot of the technology I’m going to talk about today really is designed to solve those problems, solving the integration problem, solving the interoperability problem you saw some of Bill’s mail and some of the publicity around that, about how dedicated we are to interoperability driving total cost of ownership, and delivering business value.
I think the other thing we’re focused on is really driving complexity out of the organization, and part of the way we do that is developer working together with IT pros, and making sure that we have a solid management foundation, and a solid management architecture. And our initiative around this area is called the Dynamic Systems Initiative, and the modeling technology that we use we call SDM. We’ve made a tremendous amount of progress in our management roadmap in 2004, 2005, this year, and the future looks very healthy. We’ve delivered Microsoft Operations Manager. I encourage you to check that out. That will be the product that does the real-time monitoring of applications, lets you set thresholds, Visual Studio will make it very easy to add MOM triggers. It will be the product family that essential manages Web services, and manages these “Indigo” environments that we’re talking about today.
Virtual Server is a product that required some connections that we were actually able to ship at the end of last year. And you may say, that’s kind of a weird product to talk about, but I’ve found that even though we’re primarily motivated on the IT side to do the acquisition, it’s turned out to be a fantastic tool for developer productivity. It’s so easy now to get an image downloaded, and it’s got the right version of the operating system, with the right version of Visual Studio, with the right version of “Indigo,” with the right version of “Avalon.” You don’t have to worry about, oh, my God, if I install it on this machine it will mess me up for weeks. It makes it very easy to actually play and take a look at some of these advanced technologies. I think we’ll be delivering CTPs even more frequently with more confidence because we know that people can use the virtualization technology to take advantage of it.
It also lets people do some interesting scenarios around scale, and around fail-over and redundancy. You don’t need to go buy a laboratory full of machines to go test out some advance server scenarios. So, I encourage you to consider this product in terms of how you do your daily development, and in terms of how you think about some of your architecture, and even, I think, in the future, the way we think about batch processing, and keeping consistent environments, I actually think we’ll probably move more towards the virtualization environment than the batch environment we see today.
And, of course, SMS, in delivering software, and making sure that we stay up to date, I think that’s a very important part of security with making sure that we secure the edge of the network, and secure the edge of the desktop with firewall technology. We’ll be continuing to enhance the core management foundation that we delivered with management packs throughout the year, and we’ll build on the core architecture that we’ve done with Visual Studio 2005, with the SDM support. Hopefully you started playing with the White Horse designers, started modeling out your Web services, and you can see the actual schema is kept in the SDM information, and where we’re headed with Web services, and the Management Initiative coming together with the core architectural foundation is really being able to kind of do end-to-end problem solving.
Now, today, you can get an alert from a management system that says, I’m out of disk space, or something. And today, you can get another alert from a management system that says, oh, my Web service is down. What you really can’t do today is get an alert that says, my Web service is down because three machines ago I ran out of disk space. And we actually will have enough schema information about the services, and about the orchestration of the services to actually cascade that all the way up and do advanced problem resolution. I think people are going to find this amazing synergy between the tools that spit out this meta-information and the run time productive environment. I think we’re in a much better situation.
You’ll also see all of the management information that we collect from applications, from our management products and from yours, hopefully, storing that information in SQL Server, and then using SQL Server reporting services. So if we don’t give you a view you like, if you know the view you want in your application, people can do that customization on their own.
So you’ll see kind of operations manager, and SMS, and some of the reporting come together in a suite, we’ll call it System Center. We’ll deliver that, the core of that will be via SDM, and you’ll see us build on that architectural foundation with things like performance monitoring, like capacity planning, and other tools that utilize these base models.
I think the imperative to connect is overwhelming. It’s not just IT applications. We see lots of interest in peer-to-peer applications. Certainly mobility is an increasing theme, whether it’s a Tablet or a PDA, or a smartphone. We see lots of applications, I don’t think there’s any question any more about e-commerce, banking, or those types of applications really connecting. Yet, still there’s a core focus on the enterprise in terms of making it work, making sure that we have the interoperable foundation.
Yet, we don’t want to learn a completely new set of skills when we move beyond the enterprise. We shouldn’t have to learn something completely different to do peer to peer. We shouldn’t have to learn something completely different when we want to code the same type of application that supports mobile devices. And a large part of the work we’re doing with the .NET framework and with the mobile framework is to make sure that we have one model that spans the entire fabric of devices that we’re doing. And of course, it’s based on Web services.
This is something that we’ve been working on a long time, with a lot of key players in the industry. I think that we do have a great vision. I think we do have the ability to execute. Hopefully we’ll get some stuff out to you and convince you that we have the ability to execute. And it’s nice to be recognized by folks like Gartner for that leadership.
This is a slide we’ve been showing for a long time around the Web servicesarchitecture, certainly at PDC, and before that. We build on top of the core XML foundation. We layer the messaging abstractions on top of that, and then we make sure we do a great job building secure, reliable, transacted Web services. And that’s mostly what I’m going to show you today and how “Indigo” makes it easy to build secure, reliable, transacted Web services. Most of the way we do this is by metadata, and metadata, and decorating your code with metadata so that you don’t have to write any code. We take advantage of the visual tools, of the design, of all the wizards, the property sheets, so that you don’t have to write thousands of lines of code to implement security, or reliable messaging and transactions, or anything like that.
We’ve had a good deal of success keeping the industry together around evolving the Web services standards. Toward the end of the year we actually got Coordination and Atomic Transaction published. December, usually kind of an off month, kind of a down month in the industry, but we still had tremendous progress. We had the Discovery Workshop, we had a feedback workshop around WS Management, it’s great to actually see us tackle the management problems now, and that’s both management of Web services, and management by Web services. So kind of using the technology itself to help manage the technology, and of course enumeration and transfer.
The way we do a lot of these interop workshops is just kind of old fashioned hard work. We bring in all the vendors, we write the names across the top, Microsoft, Intel, BEA, Oracle, then we write the names down the side, Microsoft, BEA, Intel, Oracle, and we just test implementations and fill out the matrix. And we don’t leave until we get 100-percent interoperability across the matrix. So it’s great to actually see other vendors committed to working on this.
We’ve seen not only the vendors work together, but we’ve seen good progress on the de jure side of the transactions as well. So W3C was actually able to standardize some of the optimization, the MTOM techniques around Web services, and I think that in the next several months you’ll see progress on reliable messaging, continued progress on management as those implementations come to bear metadata exchange and devices, as well.
I’m really pleased with the success. I think the industry has done a fantastic job. Any time I try and give a keynote, I really do try and thank my partners in the ecosystem, because again, the core value proposition of Web services, of “Indigo,” is interoperability, is connecting all these things together. And we can’t do it without the help of the industry. So I want to thank partners like Sun, like IBM, like BEA, like Fujitsu, and everyone else you see on the list. So thank you for the progress with Web services.
I still hear a lot of questions from customers, though, you know, this Web services stuff is great, I read about it, I know it’s coming, but what exactly do I do today to make my application service oriented. I know I need to start factoring, but I don’t have this “Indigo” thing, or I haven’t looked at the CTP, but I don’t want to two years from now have to completely rewrite all the stuff I’m working on now.
I have some reliable messaging standards in my shop. I’m using MSMQ today, I’m using the MQ series today. How do I make this messaging stuff work with my other messaging stuff. Hey, I’ve got some security standards, we’ve got some weirdness, my CIO wants to use some security standard here, but we’re doing some trading partners, they use different standards, I’m not sure if I want to use the same security technologies on the Internet that I use on my intranet, what should I do. Then finally you know, there’s the classic, oh, my God, there’s all these APIs, Microsoft, when should I use messaging, when should I use system transactions, when should I use “Indigo.” And so my keynote today will talk a little bit about that, we’ll get some help from Ari actually showing you some of that.
And then I encourage you to attend the breakouts. We’ll go into much more detail really answering the question, and that’s really what today is designed to do. It’s designed to give you an early look at thinking what should you do today to get ready for Web services tomorrow, when should you start coding, how should you factor these situations into your plans. And the core foundation, of course, is “Indigo.” And what is “Indigo”, it’s a unified programming model for building these secure, reliable, service-oriented transactions.
So, I talked about the scenarios that people want to build. We’ve talked about with many customers getting early looks at alphas, and early CTPs. And the set of scenarios that people want to build is overwhelming. It is all the scenarios I talked about on the key areas, it is the line of business applications, it is the peer-to-peer application. People are using Web services now to manage devices, you actually see implementations of Web services inside of printers, and other things that sit on the network directly. We’ll actually see some interesting retail POS applications. So, how can we possibly unify all these scenarios in one model?
Well, the solution is “Indigo.” And what we’ve really done is focused on three key areas. One is productivity, and we’re going to show you some of the improvements we’ve made there. It’s a unification around many of today’s distributed technologies. We’ve really used attributes heavily to help you save lines of code, and we’ve done a great job integrating with Visual Studio. Of course, we’ve got broad support in the industry, so it’s compatible with other implementations, but we’ve also made sure it’s compatible with our own technologies. So, for people using WSE today who kind of want to get a head start on your applications, or people using MSMQ, people using other Microsoft technologies, we’ve made sure that there’s a good road map forward with that as well. And I’ll talk a little bit about how that fits in with products like BizTalk, or SQL, towards the end of my talk as well.
And, of course, it continues the inexorable trend towards services-oriented development. So, it enables you to build loosely coupled services, and we’ve done a good job unifying a lot of the configuration and administrations. So this is another set of config files that need to sit outside, that need a separate management tool, they need their own separate management console. Again, unification of both the development side and the IT system operation side coming together.
I think the real shift to service orientation is kind of moving from these systems that we worked on for many, many years, you know, we kind of planned for years, they were these built-to-last systems, to systems that are much more agile, much more adaptable, and built for change. I think the types of development we do now are much more incremental. I think the Web has kind of changed that and gotten us certainly to ship on a more frequent cycle. They’re incrementally built. They’re incrementally deployed. People need to rollout new chunks of things without breaking old chunks of things. Certainly we see this in Microsoft as we have some key large ERP systems, or large CRP systems, and we want to rollout new functionality, but nobody wants to upgrade their SAP system every week, or every month, or every year, and yet we want to deliver incremental benefit from those systems, and really service orientation allows you to do that. And it’s because we moved from these tightly coupled, kind of all wrapped up situations to more loosely coupled connected systems.
The way we’ve built “Indigo” is as a natural extension to the .NET Framework. So, in some ways, you know, there’s nothing new to learn. You build services in Visual Studio. Again, you use any .NET language, you want to use C#, you want to use VB.net, you want to use J#, you use your favorite .NET language. All the “Indigo” stuff that you expect to work, the IntelliSense, the debugging, the deployment tools, it all works. It’s very natural. And you’ll see us continue to evolve the Visual Studio environment as we involve kind of the “Indigo” model moving forward.
If we look at really where we’ve extended the framework, it really is around the communication area. Clearly on the presentation side, you know, that innovation area is going to be covered by Avalon, on the data side that will be covered by WinFS, and communication is “Indigo.” But, again, it all fits in naturally with Visual Studio, and everything we’re doing.
So, here’s kind of the base that we started from. We started talking about Web services a couple of years ago. We actually wrote some Web services applications internally at Microsoft around our CRM system that we use actually to track developers, to see what they are up to, what conferences they were coming, how we were communicating. And we wrote some good sample applications as well. And we were kind of pleased with, you know, hey, this model is good, it yields the loose coupling that we want. It is adaptable, it is agile. We can make changes. We can sit on top. We get great integration with Office. But, wow, it was a lot of work. But kind of in our prototypical hello-world application, it was about 56,000 lines of code. That’s a lot of code for one guy or a team of guys to churn out. And that’s really when we made the commitment to do WSE.
And I think the main thing we focused on with the first version of WSE was really getting security right for a couple of reasons. One, we heard loud and clear from customers that the main pain point for them deploying in their application was security. There was no way they were going to deploy Web services for mission critical applications unless we got security right, unless security was flexible to fit in with all the different models that they had, and nobody wants to code security multiple times across the company, across the ecosystem. It’s one of the hardest things to get right. And so we kind of took a whack at it, and gave some good incremental value around WSE. And we made good progress. We kind of reduced it by about half, and so now we had kind of our prototypical hello world application down to about 27,000 lines of code. Good, nice improvement from kind of the early Visual Studio days to WSE.
But we knew we had much more. And with “Indigo,” the goal, again, was to get security okay, you can applaud (applause) was to get security done right. We already had that work done with WSE. Was to get reliable messaging done and integrated, and we’ve done that. And to get the transaction space and transactions coordinated as well. And so, really, I think people are going to see phenomenal gains. And I’ll actually show you some code samples before and after, and you can kind of judge for yourselves.
I think most important and more kind of convincing than PowerPoint slides is to actually see the product itself. I’ve been talking long enough. Let me bring up Ari Bixhorn, and he’s going to give us kind of a lap around “Indigo,” and show us all these productivity enhancements. Welcome, Ari.
ARI BIXHORN: Hey, Eric, right over here. Thanks, Eric, how are you?
ERIC RUDDER: Good.
ARI BIXHORN: Well, good morning, ladies and gentlemen. It is great to be here this morning, great to give you a very early look at just a few of the features that we’re going to be delivering in the first release of “Indigo.”
Now, in this demo, what we’re going to see is how developers at a hospital use “Indigo” to augment an existing patient monitoring solution. Throughout the demo you’re going to see three things. First, you’re going to see interoperability. You’re going to see how by default “Indigo” speeds Web services protocols on the wire. Second, you’ll see productivity, you’ll see the same type of drastic reductions in code for building secure, reliable Web services. Third, you’ll see extensibility. You’ll see how we can customize the “Indigo” framework to fit the specific needs of the hospital.
Now, the scenario is patient monitoring. For the purposes of this demo Eric is going to be playing the role of Dr. Rudder, and if you hadn’t already guessed, I will be the patient. We can see a bird’s eye view of our solution here. This is running inside of Visual Studio 2005; now, where is “Indigo”? “Indigo” is under the covers. Like Eric was saying, it’s an extension to the .NET Framework. So we can within the context of the language and the tool that we already know.
Let’s do a quick tour of the solution as it exists today. Essentially what this solution allows is for Dr. Rudder to be anywhere inside of the hospital and still be able to view vital sign information for any of the patients in the intensive care unit. So the solution begins in the intensive care unit, or in the ICU itself. We’ve got a number of monitoring devices up on stage here with me. We’ve got an Aspect EEG, which is essentially a brainwave monitoring device. We have a Nellcor pulse oximeter, which is going to monitor my heart rate up here, so you can see just how fast someone’s heart beats when they’re up on stage in front of 2000 people. And form there what we do is we take the information from these devices and we pump them through to an “Indigo” service.
This “Indigo” service is going to use MSMQ to send the information and store it durably into a SQL Server 2005 database. From there we’re going to pump it out to one more “Indigo” service that then blasts out the information to two different clients. First we have an ASP.NET Web app, and second we have a Tablet PC application.
Now, for the purposes of this demo we’re going to focus on this service, and this client application here. Now, before we bring those up, let’s extend the solution inside of Visual Studio. We want to add some additional functionality here. We want Dr. Rudder to be able to monitor not only my vital signs, but also to see what prescriptions I’m on. The only issue is this prescription Web service isn’t an “Indigo” service; in fact, it’s not even built on ASP.NET. It’s running on BEA’s Web Logic. But, because “Indigo” supports Web services protocols by default, to add this service to our solution we’re just going to reference its WSL, and add a reference to it. Once we’ve done that, I’m going to drag and drop it to bind it to my client application. Pretty easy, right?
OK. So once we’ve done that, let’s go ahead and actually run the app, and see this Web Service in action. So we’re going to start up the “Indigo” service up on the server. It appears to be listening, and now let’s start up the client application. As we do this I’m going to hook myself up
ERIC RUDDER: Just for the purposes of the demo, people should know that the brain monitor isn’t for the medical application, it’s the next version of IntelliSense.
ARI BIXHORN: OK. So let’s see it looks like we are getting my heart rate of 155 beats per minute, folks. The adrenaline is pumping up here. Now, let’s see, when I blink my eyes, you can see that’s getting picked up by the brainwave monitor. And when we want to go ahead and call that Web Logic Web service, I’m just going to click on view prescriptions, we’re going to make a call out to that Web service, bring back that information, and painlessly integrate it into our Windows forms application. To verify that, let’s go back over to our Web Logic machine, we can see the schema for the service, and we can see that we’re receiving the get prescription call. So pretty easy interoperability, not just between “Indigo” services, but even across other platforms.
Now, let’s take a look at the client application. It’s running in a fairly controlled environment right now. It’s running within the four walls of the hospital. What if Dr. Rudder, though, wants to leave the hospital, and view this information while he’s at home on call? Well, today what we’re doing is we’re sending information over plain old TCP. So if we want to send that out across the Internet we’d have to punch a hole in our firewall. IT folks aren’t going to like that. So ideally what we want to do is change the way this app communicates, so that we’re using port 80, and sending the information over HTTP. Today that would take a lot of code. Let’s see how we would do it in “Indigo.”
So I’m going to stop the client, we’ll stop the server, and we’re just going to make one little change to our code here. I’ve got an app config file on the client. We’re going to change the value from TCP to HTTP. Okay. Well, we’ve got app config files today, right. This is nothing new. But, what is new is the way we handle this in code.
Scroll down in our client application here, and based on the value that we read in from the app config file, either TCP or HTTP, we’re going to create one of two end points that is used to call an “Indigo” service. If we read in TCP, we’re going to bind to that service using a TCP binding, the same applies for HTTP, but these bindings are defined just a little bit higher up in our code, where we’ve got our TCP transport bindings, and one for HTTP going over port 80.
The same thing applies to the server. So if we go up to the server we’ve got our TCP transport, our HTTP transport, and if we scroll down into our code we can see the actual “Indigo” service that’s simply exposing two different end points. One to allow calls to come in from TCP, and one from HTTP.
So with that, we’ll go ahead and restart the service. We’ll go back to our client. We’ll restart the client, and now we should be essentially fundamentally changing the way this app communicates sending information over HTTP. And as we can see down in our status bar, as soon as it appears, we are now successfully sending information over HTTP. Pretty cool, huh? All right.
ERIC RUDDER: The thing about that, no business logic changes, just configuration.
ARI BIXHORN: Just the app config.
ERIC RUDDER: Into a programming model that fits across any transport, TCP, UDP, HTTP, MSMQ, MQ Series. Whatever transport technology you want to use underneath will actually unify the program model at the top.
ARI BIXHORN: That’s right, Eric. There looks to be some gaps, though. There are some gaps here in the information coming across the wire. Is this a sign that my brain is getting ready to conk out? Quite possibly. Quite possibly. What we’re actually seeing here is what might happen if we’re sending Web services data over multiple intermediaries, or in this case multiple SOAP routers. It’s possible that packets will start to be dropped as they’re sent across these multiple intermediaries. So what we need is some sort of a reliable messaging assurance. As Eric showed in the slide, today that takes a lot of code. Let’s see what we would do in “Indigo” to have reliable messaging.
We’ll stop the client, we’ll stop the server, and now let’s go back to that HTTP binding. We’ve got an interface here, and to add reliable messaging all I’m going to do is drag and drop one attribute out into my code. It’s a reliability binding that specifies a couple of things. First, it specifies that each and every packet that comes across the wire needs to be received once and only once. Second, we want to make sure that those packets are being received in the order they’re sent. And if we do start to drop any packets. We’ll retry it up to 100 times. So we’ve got reliability in just one line of code.
Well, what else do we need? We need security, right? We need to make sure that the information we’re sending across the Internet now is going to be signed and encrypted before doing so. So to do that we’re just going to add one more attribute to our interface here. We’ve got our business security binding that specifies that we want mutual X509 certificate authentication on the client and the server. So now that we’ve done that, we’ll add those same two attributes to our server binding, drag and drop those out.
Now let’s restart the server, F5, running the server. Let’s go back to the client. We’ll run the client, and now all those gaps should disappear. And there you have it, reliable messaging and security, two lines of code. (Applause.)
OK. So I claim that they’re secure. You can take my word for it. But, let’s actually see what’s going across the wire. Let’s go ahead and do that. One of the things that “Indigo” is going to be shipping with in version one is a message tracing application. So I’ll stop the client here, and let’s go up to the server and actually see what’s being sent across the wire. We’ll stop the server and I’m going to launch my message viewer.
When we launch the message viewer we can see that early on the information being sent across the wire is in clear text, because the text is kind of small let me just bring up the magnifier so you can see what I’m talking about. We can see information on the patient’s IV, everything is in plain text, and you can see that at the top of the screen. Now, let’s go down to the bottom and see one of the encrypted messages being sent across the wire. We scroll down here in the message, we’ve got a lot of additional security information. The bottom line is that this is the information being sent across the wire. Cipher value, it’s been signed and encrypted, no malicious hackers can get access to this.
All right, so we’ve added security, reliable messaging, we’ve added an interoperable service, we’ve changed the way the application communicates; what else might we want to do? Well, ideally we would be taking advantage of the power of the smart client, right, that’s why we build smart client applications.
Now, Dr. Rudder here has a Tablet PC and on that Tablet is a biometric fingerprint reader. What we want to do is map Dr. Rudder’s fingerprint to the X509 certificate that’s being used to sign and encrypt the information being sent.
What we’ve done in order to do that is we’ve actually extended the business security binding. Let me go ahead and remove the heart rate monitor just for a second so that I can type here. And we’ve extended this with a custom attribute parameter. So I’m going to type in certificatesource.fingerprint. Now the way we’ve customized this, when we run the application it should challenge us asking us for Dr. Rudder’s fingerprint.
So I’m going to minimize, let’s go back up to the server, we’ll start up the server, we’re listening on the server, back to the client, run the client and hopefully we’ll get challenged for fingerprint authentication.
Now, what if I try to run my finger? It’s going to say thanks but no thanks. Eric, do you want to do the honor of running your fingerprint just down the fingerprint scanner at the top? Beautiful, recognizes Eric. What picture was that that they used there? Was that an old high school picture?
So with one change of code we’ve customized the way the “Indigo” security model works, allowing us to authenticate Eric before he even gets access to the application.
So what have we seen here today? Well, we’ve seen three things. We’ve seen interoperability, we’ve seen how “Indigo” can communicate using Web services protocols to not only speak to other “Indigo” services but to speak to any platform that also supports Web services. We’ve seen productivity, so we added security and reliability in just a couple of code. And finally, we saw extensibility, we saw how we can customize the “Indigo” security model to fit the specific needs of our application.
These are just a few of the features we’re going to be shipping in “Indigo” v1. For more information, room 2008 has “Indigo” sessions all day today, check them out. Thank you. Thanks, Dr. Rudder. (Applause.)
ERIC RUDDER: So I think Ari did an amazing job kind of showing off some of the productivity that we’re going to see.
We got a chance within those 15 minutes to show a couple of the key models. We showed some of the ASMX stuff, I kind of alluded to WSE but there’s lots of other things that we need to make sure we do a good job unifying throughout Indigo, right, enterprise services, the messaging and then how does this fit in with .NET remoting as well.
So most of the day we’re going to see this in detail in 2008 but I wanted to spend just a few minutes talking about how “Indigo” fits with the other technologies.
We’ve known we’re going to move to Web services for a long time and we’ve encouraged all of you to write ASMX services, I hope you’re doing so and the change from ASMX to “Indigo” is relatively straightforward, as I’ll show you in a minute.
But before I change my code to show what I need to do before and after, the first question people should always ask is, do I need to change my code? And the answer is no. We will release “Indigo,” but all these other programming models will continue to work. So nobody has to panic the day “Indigo” comes out, your old stuff doesn’t break, we can continue to run stuff side by side, you can have one server that listens to old AMS responses and “Indigo” or it listens to .NET remoting and old ASMX responses and Indigo, you can have an MSMQ implementation that handles legacy MSMQ and Indigo, so there’s no imperative that you must move to “Indigo.” We, of course, believe people want to move to Indigo, we think people are actually going to save code, we think things will run a little bit faster, smoother, better management tools but nobody has to panic that they need to go home and immediately change everything all at once.
The second thing is, is it going to be protocol compatible with what I have. I’ve been using WSE, you guys promised me WSE with Web services, is it going to interoperate with “Indigo” and the answer is yes, any SOAP Web service, any WSE implementation, if you’re using MSMQ and then decide to use MSMQ with Indigo, those things work, we interoperate with ourselves and, of course, if you use it with other products as well, those semantics work equally as well.
So again old things continue to run, there are ways to interoperate with legacy implementations of Web services — it seems odd to be calling first generation Web services legacy, but clearly you can move forward.
From ASMX the transition is the simplest. We’re going to change some of the namespaces that we use since we’ve got some new part of the class library, we’ll change some of the attributes, you saw Ari in his demo change some of the attributes, and your business logic for the most part remains the same. So we just switch the service model part of the namespace, we set the service contract, we move forward. So ASMX to Indigo, pretty good news there.
Enterprise services to “Indigo,” what happens there? Well, it’s a pretty similar transition. We’re going to change the declaration of what namespace we’re using and we’re going to change the metadata.
Now, the fun part about enterprise services as we move to “Indigo” is we also pick up some optional features that people have been asking us for a long time. People have said, you know, hey, enterprise services, they’re great, but having to set my security information, my transaction information on a class basis is kind of a pain. If you pick up “Indigo,” we’ve actually enhanced the transaction support now and you can actually set transaction semantics and security semantics on a per method basis, which should be very nice for people using enterprise services today. So again, similar transition, ease of code, more functionality in this case.
Moving WSE to “Indigo,” again protocol compatible from the last version of WSE, life is good, we’ll actually see again similar changes, move to the namespace. Here actually though you notice I actually did change some of the business logic. You can see kind of some of the security message here where I had some of the principle checking going on in logic. That’s actually now declarative in “Indigo” so that’s something where we took four lines of code and made it one attribute. So here’s an example where you’ll actually remove code from your application and use an “Indigo” attribute instead.
On system.messaging it’s actually a very similar example to the one I showed before. We’ll actually see again the change of the namespace, we’ll see the service contract information here but “Indigo” will do a lot of the queuing for you automatically. So you see all this logic here that actually did all the SML message processing and got stuff into the queue and got stuff into the dataset. We actually get that back automatically from “Indigo.”
So your business logic still is the same, right, whatever process order does with that dataset it’s still going to continue to do but all the code that you had to kind of write manually to suck things up and kind of massage things between queues and datasets, that will all be done for you automatically, so again more features going forward.
The story with remoting is a little bit different and remoting was really designed for a different case than Web services were designed for. Remoting is to be used only when you the developer or you the company know that you’re going to control both ends of the conversation: you know if somebody upgrades the client you can force a server upgrade, you know if somebody upgrades a server you can force a client upgrade, you know all the end points in between, you can set everything up. If you really can control the end-to-end base from the client to the server, then remoting is probably a candidate for you.
For the most part we usually don’t have that flexibility, which is why Web services is great. But there are times when you do have that flexibility and you can do some optimization and you can do net remoting.
For the most part I actually don’t expect people to move .NET-remoting applications to “Indigo” because you kind of made a different architectural decision up front not to be Web-service-based, but there are people that may have decided to use .NET remoting and still may decide to move to “Indigo,” and it’s possible. You’ll have work to do if you’ve done custom adaptors or channels for .NET remoting, those things don’t match perfectly well on the “Indigo” side, so you’ll have to think about what patterns you’ll use. You’ll change the service model, you can add some of the contracts. We do support the serializable attribute in the “Indigo” model, which is kind of nice.
So again this is a little bit trickier. I don’t think most developers will take the leap, but if you do need to take the leap we’ll have prescriptive guidance on how to move from .NET remoting to “Indigo” as well.
So overall I think we’re pretty good on the .NET Framework side; I hope you guys would agree.
People also ask, hey, in addition to the framework, how does some of the “Indigo” work fit in with what you’re doing with BizTalk or what you’re doing in SQL Server around Service Broker? BizTalk is really our platform for application-to-application and B2B integration, we’ve got a business-process engine, we have a business-rules engine and composer, we’ve got great adaptors for both vertical solutions, HIPAA, HL7 and key enterprise software like SAP, like Siebel, MQSeries. It’s got business activity monitoring, it’s got great integration with the Office applications, publish and subscribe, content based and document routing.
So the need for BizTalk won’t go away. BizTalk is still going to orchestrate all these services we build using “Indigo.”
What will change on both the BizTalk and SQL Server side is some of the protocols that they use to collaborate. So BizTalk came out in 2004, it had the BizTalk protocol and we built an adaptor for WSE so people that want to run BizTalk and hook up Web services can do that.
Of course, when “Indigo” ships and BizTalk Server 2006 is on track, we’ll also have an adaptor for “Indigo” as well, so people can take their BizTalk applications, install the adaptor and talk to “Indigo” as well.
The version of BizTalk beyond that, after everything kind of lines up, we’ll actually switch the native protocol of BizTalk to use Indigo, so it will be kind of our default architectural assumption that you’re using Web services and we use “Indigo” itself.
Of course, BizTalk Server will continue to support all the other adaptors, we’ll continue to talk BizTalk 2006 protocol and BizTalk the next so people don’t have that transition but again I do expect people to move to use BizTalk for orchestration and just use “Indigo” kind of as the transport layer.
SQL Broker is a little bit different story. We did SQL Broker as a separate program for people that like the database programming model and just want to think about queues as databases and want to think about sucking things out of queues as kind of hanging queries and result sets, and the Service Broker just for timing reasons actually wound up with being a slightly different protocol.
And so we’ll do that work and adapt both ways the set. We’ll take the Service Broker implementation and protocol and we’ll put the “Indigo” programming model on top. So, just as you saw “Indigo” run on top of TCP and HTTP and UDP and MSMQ, it will run on top of Service Broker.
And then beyond that we’ll also do the inverse and so we’ll actually have Service Broker the model use “Indigo” as the transport, so again people who like that type of database programming and using the database as a queue and looking at the attributes and selecting over and doing all that fancy stuff with messages. For people who need that but want to run on top of the “Indigo” transport, we’ll do that in a future version of SQL Server as well.
So it’s kind of clear that the long-term bet really is Web services everywhere. And if you look at the Windows Server System roadmap and all the protocols, we will do Web-service protocols everywhere. We’ll continue to support all the classic protocols that we have.
So you look at how people are doing identity things today, you know, clearly we’ll support ADSI, we’ll support LDAP but I think increasingly the directory and identity types of services are going to be done via Web services. You look at how we do collaboration today and kind of the SMB-based protocol and some of the file-based stuff, we’re going to move towards WSS SharePoint actually using Web services and having Web services infrastructure running on top of “Indigo.”
So you’ll see Microsoft’s WSS, Windows Server System roadmap move to have a consistent Web-service-based programming model so you don’t have to learn a different API to send a mail message or a different API to actually do collaboration scenarios or do workflow or do mail scenarios or do identity scenarios; we’ll have a set of Web services that will work the same way in Visual Studio, you’ll get to model it the same way in Visual Studio, you’ll get to monitor it the same way using our management tools and so really Web services creates this great architectural foundation to really reduce complexity for both developers and the number of paradigms that they need to learn and the IT pros and what they need to configure.
Well, no matter how much work we do ourselves in Visual Studio, in “Indigo,” in all of our management products, in Windows Server, in Windows Server System, it’s clearly not complete without the support of our partners. And the support we’ve had from VSIP has been fantastic. We’ve actually doubled the number of partners in VSIP since last year. We have more than 225 premier and alliance partners, including some very big names now, we’re very excited.
We introduced last year a new affiliate level program, we now have about 20,000 people doing VSIP time implementations in their company, doing little plug-ins, or on their own, kind of sharing with the community, getting that information back, so we have 20,000 affiliates and I think we’ve got great integration tools and I’ve seen some in the next generation implementations that people are doing with Visual Studio 2005 and I think we’re going to have a great ecosystem, by far the best tools ecosystem in the industry.
I think we also have a greater variety of partners and that’s partly the big database companies; IBM, Oracle are joining VSIP, the big database companies are there but, of course, the large enterprise software companies are there, SAP, Siebel, those types of applications, and, of course, some of the smaller guys doing great innovative work in tools.
And I think we’ll continue to see not only a greater variety of partners but we’ll continue to see people doing great support for “Indigo” as well. And today I’m happy to announce that AmberPoint are amongst the first who have actually committed to build tools in VSIP supporting “Indigo” as well, and hopefully those guys will follow our milestones and we’ll get some great tools to help people write “Indigo” applications going forward. I expect that number to increase quite substantially going forward as well.
So, of course, your appetite is now ready, you know you need to build service applications, how do I get it? As many of you know, we’ve been moving towards these CTPs, helping you understand our roadmap, being transparent about where we’re going. “Avalon” shipped a CTP towards the end of the year in November.
Our next CTP will be a WinFX CTP and we’ll finally bring everything together. So we’ll have a version of Visual Studio that works with the same version of “Indigo” and the same version of “Avalon” so people can try out all-in-one system with out bits and pieces, what that’s going to look like.
And our plan is to deliver that in March; even if it’s March 38th or 43rd, we will deliver it in March. (Laughter.)
And, of course, the feedback that we get from all of you around the CTP and around the beta is incredibly helpful and you guys know that we’re quality driven and you’re doing a great job on the implementation, the security audits, security review, but things look very good now. We are code-complete, we’re just kind of tracking down those final bugs. And I expect the next pack of WinFX to be incredibly compelling. And, of course, we’ll make that broadly available on MSDN. It really is time now to start to take a look at WinFX, start to take a look at Visual Studio and think about how you plan.
We know that delivering just bits isn’t always enough, not that these great three-line samples don’t put you on your way and seeing one attribute in one one-line code example should be enough to learn the entire framework. We know we need to do better than that, so we’re actually going to take some of our biggest samples and make those available as well.
So you guys know we have a huge investment in prescriptive architecture guidance, we brand that patterns and practices, it’s our proven authoritative, accurate relevant information, this is how Microsoft says to design a big application. It’s based on many interviews with partners, with customers, a broad based field. It’s been technically validated, other people have built applications using these patterns and they’re designed for real world scenarios. So if people have looked at the global bank application that we shipped today as part of the pack of solution, we’ll actually take that application and port it to “Indigo” and deliver that as well.
So when you get the CTP, and you kind of want to get started and you want to look at those patterns, people will have that information as well.
We’ll share it obviously on MSDN. I hope you guys are enjoying the improvements we’re making to MSDN and really getting connected, kind of using the feedback center on MSDN to really share that information. Every time you post something in the feedback center, it’s linked directly into the product team database so I will get little reports and if you guys file a bug my bug count increases on “Indigo” so, I don’t know, maybe don’t post anything till March 53rd.
But I think increasingly we will continue to invest in MSDN, giving people a more personalized experience. We’ve talked about that as MyMSDN. Making sure we have dev centers around key areas of competence, obviously we’ll have one around Web services. And, of course, federating with the community at large, there are lots of partners beyond MSDN providing great samples, providing great prescriptive information around code zone and we’ll continue to include them in the broader community as well.
I hope you guys are checking out our other properties beyond MSDN, gotdotnet, channel 9, our blogs, newsgroups, chats and user groups, and you’ll see a lot of great support for Visual Studio 2005 and for “Indigo” around community.
And it’s our community, it’s as good as we make it, it’s as much time as we spend on it together and I think it’s a tremendous asset for all of us in the ecosystem when we have a healthy community, so I really encourage you to participate there.
So I want to close with a quick call to action. Obviously you’re all building applications today using Visual Studio. Start to really think hard about building services using ASMX; that’s really your easiest way forward, it’s good prescriptive guidance anyway to start thinking about service-oriented architecture and keeping components implemented within service boundaries. I think it will lead to greater agility in terms of how you run your business, even if you don’t use “Indigo,” heaven forbid.
If you need WS support today and Web services protocol support today, by all means use WSE, WSE is supported, you can call PSS if, heaven forbid, you have a problem; it’s a real product, it’s not one of these random things we throw on the Web. We are committed to keeping the protocol compatible between WSE and “Indigo” as we move forward.
If you need asynch message patterns, by all means continue to use system.messaging. That will move forward very nicely to the model as we move towards “Indigo.”
And continue to use enterprise services for transaction support. We worried about what to do there, we figured out how to take enterprise services, meld it into that unification quite nicely and I think people get some nice benefits on the method-based support as well.
So overall I hope I’ve at least whetted your appetite a little bit for “Indigo” moving forward, there are lots of great breakouts today. I want to thank you for inviting me to San Francisco. I enjoyed spending some time with you. If you’re ever in Paris, give me a call, certainly in the next six months, and enjoy the rest of the show.
Thank you very much. (Applause.)