Longhorn Indigo

"Indigo" is the codename for a set of .NET technologies that enable applications to communicate with each other using secure, reliable, transacted messaging. This technology is based on the Web services architecture, which means it not only works on a broad range of network topographies, but it also interacts with systems running on other platforms.

In this episode of the .NET Show John Shewchuk discusses how "Indigo" applies to the architecture of the applications you are designing today, and how it will become a core component of the applications you are planning on developing for Longhorn. Steve Swartz then walks us through some code examples to illustrate the programming model for "Indigo", and how easy it is to add support for its various features into your applications.

Jump to #1 INTRODUCTION
Robert Hess, Group Manager for Microsoft Corporation and Show Host.

ROBERT HESS: Welcome to another episode of the .NET Show. Here we're going to take and start diving into Longhorn. In the last episode we gave you an overview; now we're going to take and hit the pillars one at a time. In this first episode we're going to talk about Indigo: what it is, why it's important to you, and most importantly, how we're going to program it. But first, let's check in with Erica and the news.

Jump to #2 MSDN NEWS UPDATE
Hosted by Erica Wiechers, Program Manager.

ERICA WIECHERS: Hello, I'm Erica Wiechers. Welcome to the MSDN News Update.

Jump to #3 MSDN Launches Haven for Microsoft Bloggers In early January, MSDN launched its own blogging site at blogs.msdn.com. Here you can keep up with the latest happenings and get a candid look inside the minds of Microsofties. The site uses the same blogging infrastructure that powers weblogs.asp.net, so you'll see Microsoft bloggers listed in both places.

Jump to #4 Bill Gates to Receive Honorary Knighthood Also in January, Britain announced that it will award an honorary knighthood to Microsoft Chairman Bill Gates in recognition of his contribution to enterprise in Britain. Because he is not a British citizen, Gates won't be able to use "Sir" in front of his name, but he can put the letters KBE after his name. The initials stand for Knight Commander of the British Empire.

Jump to #5 DevDays 2004 This March, DevDays 2004 will be held in 32 US cities. The event will focus on building secure smart client and Web applications using Microsoft Visual Studio .NET, and will help developers add power and security to their applications. Several tracks will be available where developers can see a local expert build a real-world application, see the application in action, and leave with the code at the end of the day.

Jump to #6 Microsoft Tech·Ed 2004 This year's Tech·Ed will be held from May 23-28 in San Diego, CA. This event will feature 400-plus technical sessions for IT professionals, network and system administrators, messaging and security specialists, architects, and developers. Microsoft technical gurus and some of industry's top experts will bring you up to date on the latest Microsoft products, tips and tricks, best practices, and hands-on demos. Those who register by April 16 will save $300 US off the regular price.

And this has been the MSDN News Update. I'm Erica Wiechers.

For more information on the above news items please refer to the following:
Bill Gates to Receive Honorary Knighthood
Read the eWEEK article:
http://www.eweek.com/article2/0,4149,1460012,00.asp
MSDN Launches Haven for Microsoft Bloggers
Check out the new MSDN blogging site:
http://blogs.msdn.com/
DevDays 2004
Sign up for DevDays 2004:
http://msdn.microsoft.com/events/devdays/
Microsoft Tech·Ed 2004
Sign up for Tech·Ed 2004:
http://www.microsoft.com/seminar/teched2004/default.mspx



Jump to #7 TECHNOBABBLE
Robert Hess meets with John Shewchuk to discuss Indigo and how it's architecture has evolved to address the communication needs of advanced applications.

ROBERT HESS: Welcome back. As I mentioned, we're going to focus on Indigo and how it relates to Longhorn technologies in this episode. In future episodes we'll deal with other aspects of Longhorn, but let's start off with something like Indigo which I think a lot of people have some pretty big questions about. To discuss these issues with us I have John Shewchuk. John, thanks for joining us.

JOHN SHEWCHUK: Thanks Robert.

Jump to #8 ROBERT HESS: Now what exactly is the role you play in Indigo?

JOHN SHEWCHUK: Well, way back when when we were finishing up Visual Studio .NET and the .NET Framework, Brad Lovering, me and a couple of other architects had noticed that while we had the beginnings of a service-oriented architecture, we needed to do more. We knew that we needed to take this notion of Web Services and really make it reliable, make it secure, make it transacted and really flesh out the architecture so that we could send messages around asynchronously. So Brad and I and Robert Wahbe founded the Indigo Team, and I've played the role all along of identifying those areas that we need to work on, helping flesh out the technologies, negotiate with other organizations like IBM and BEA on the Web Service specifications. So I've played a pretty broad set of roles throughout the lifetime of the Indigo project.

Jump to #9 ROBERT HESS: So what were some of those key things originally that sparked your mind in thinking that this service-oriented architecture could actually make a go of things?

JOHN SHEWCHUK: Well, if you think back to where we kind of started the whole Visual Studio .NET and the .NET Framework project, for a long time Microsoft had been building distributed object technologies. We had DCOM, and that was really the basis for the way systems communicated. Microsoft had made a huge investment in these technologies, and while we were doing that, and many other people were building similar kinds of technologies such as CORBA, the Web came along. And the Web really represented a kind of different way to do things. In the Web we used messages, http requests that contained well-defined formats like HTML, and the thing that characterized that model was just this enormous scalability and interoperability between systems. So if you look at the browser, we define this HTML format, and that could be viewed by Netscape browsers, Opera browsers, IE, and it could be served up from many different kinds of servers. And everyone could play in the game because we understood the schema, the format of those messages. Not only that, but there was a super interesting aspect of the way messages could be transmitted through the system. For example a router could look at that incoming message and decide that it should load balance serving up the answer to the request across a bunch of different machines. And so we could do things like content-based routing; we could do things like load balancing; we could do things like the kinds of things that Akami does, where they distribute information around the system. All because of this central notion of a message-oriented, well-structured communication pattern.

Jump to #10So we noticed that those things were going on. We had DCOM, on the other hand, which had a great rich infrastructure with things like reliability, with things like security, transaction support, full asynchronous communication, and on the other hand we had this new way of doing things with the Web being very message-oriented. The big question was, could we pull it all together? And that's really what Web Services represents is kind of the merger of those two big ways of doing things. And the service-oriented architecture represents kind of the culmination of bringing those technologies together. So the service-oriented architecture, with its notion of services that have well-defined interfaces, that we communicate to with messages, the messages are described by XSD, the message patterns are described by things like WSDL, gives us a really great architecture for building distributed applications and it also gives us a way to make sure that those applications can work across systems built by IBM WebSphere based solutions or BEA solutions or Microsoft solutions. So it really gives people a way to put together things that they've never been able to put together before.

Jump to #11 ROBERT HESS: And how long have you been working on this?

JOHN SHEWCHUK: Well, let's see. I left right after the PDC that we did in Orlando, which would have been 2000 I think, and a couple of us spun off and we started ramping up the Indigo Team, and we've been working on it ever since.

Jump to #12 ROBERT HESS: And where'd you come up with the name Indigo?

JOHN SHEWCHUK: Ah, well that's a good question. We were down in California, and we were driving along, thinking about how we should put together our solutions. We were in the car with Robert Wahbe and we had been off talking to a bunch of companies down in California, and we kept trying to think of a code name, and we wanted a code name that gave us some flexibility. We didn't know exactly how the project would turn out. So we decided that we needed something neutral; we kept bantering around names; colors kind of showed up as one of the things that we ended up thinking about, and just the name Indigo seemed to fit and that's what we went with.

ROBERT HESS: No one was wearing an indigo shirt or driving an indigo car at the time?

JOHN SHEWCHUK: No.

Jump to #13 ROBERT HESS: Now I understand we've actually come out with some technologies kind of along the way to Indigo, some of the Web Services architecture where they, also known as GXA stuff. How does that fit into the whole vision of what Indigo is?

JOHN SHEWCHUK: So when we started out, we wanted to have this notion of Web Services that kind of took that next step, bringing in the security, the reliability, the transactions, the asynchronous patterns. We started down the process of writing down how those things would work, and a very interesting argument came to the fore which was well, we could go do this stuff, we could build it into Microsoft products, but the thing we kept hearing over and over from customers is, we want to be able to use your technologies but we have to exist in this environment where we have lots of different systems. Not only systems that are built on other platforms, be it Java or Apple technologies or whatever, but we have legacy systems, and we have different versions, and the older distributed object-based approach really relies on a fairly tight coupling with the underlying runtime. So the discussion that ensued kind of boiled down to well, if we're going to go do this, we need to make sure that we talk to other platforms, so we're going to have to go work with companies to standardize this stuff.

Jump to #14So one of the things that came out of the argument was that I had done work at IBM; I had worked on the XWindows system at Project Athena and working for IBM at the time. And I knew that IBM was one of the other companies that really deeply cared about a service-oriented architecture. And so I argued that what we should do is we should go talk to IBM, which is something we really hadn't done before. And the first project was a project I had been working on which was the security aspects, we said, let's go talk to them about our ideas around security. And so we brought together a bunch of folks from IBM -- managers and technical people and folks like Maryann Hondo, who I had been talking with from IBM, Tony Nadalin and others -- we all sat in a room, and we kind of sketched out what it would take to build a really scalable distributed security system. And the interesting thing is they loved it. We kind of sketched out some basic ideas; they responded; they brought their ideas to the table; we brought some specs that we had each been working on independently; we brought those things together, and the result was the WS Security Spec.

Jump to #15And that's really been the basis for what has become, I think, one of the most interesting collaborations that's gone on in the industry. We've got two companies that have a deep history in building distributed systems. In each case we've kind of talked about the ideas, we've brought in people with expertise in the area -- like VeriSign in the security area, folks like Tibco in the just announced eventing specs -- and by working with experts in these areas, we've been able to put together a set of specs that we think will be the basis for a distributed service-oriented architecture that's going to last us for hopefully the next ten to fifteen years.

Jump to #16 ROBERT HESS: Now since a big part of this is communicating with other infrastructures and stuff like that, and that means you have to work with an awful lot of these other companies doing that sort of thing, I know how hard it is just inside of Microsoft to take and come to a common decision amongst our groups. It sounds like it's a really big problem to take and be dealing with other companies, whether they're companies that are traditionally friendly with us or not. How has that been playing through?

JOHN SHEWCHUK: Well, when we work with other companies, obviously people have different ideas about how the system should work. And early on it was a pretty significant challenge. We had pretty radically different ideas about the way, for example, security should work or the way we should address endpoints, whether it should be with URLs or other kinds of things. And the only way to really get through those things was to sit down, identify what we wanted out of the service-oriented architecture, work through the details, and as we did that and as we got more and more of this core architecture together, it actually started to become easier because we're not just working on each piece in isolation. So one of the great things about the specifications we've created is although each spec in and of itself is very simple, easy to implement and pretty small, there is an underlying gestalt if you will, a set of guiding principles that we've grown aware of as we've started to build systems that way that is really helping drive all the new pieces as we bring it together. So the exciting thing is that we really now have a core architecture that most of the major application server vendors and others in the industry agree on, and from that it's been easier to build higher level pieces based on that core piece.

Jump to #17 ROBERT HESS: How many specs do you have so far?

JOHN SHEWCHUK: Well I don't know the exact number, and we continue to identify areas where people want new kinds of functionality, but at the core it's probably worth just kind of running through what the basic pieces are. The basis for all this stuff are a set of specifications that most people are pretty familiar with: WSDL for the description of the message exchange patterns; the messages are transmitted using the SOAP technologies; and based on those things, with WSDL and SOAP, we really get the basis for communication. One of the things that was a challenge, that we learned as we were building some more sophisticated systems, is that SOAP in its earliest incarnations was pretty tightly coupled to http. And as you know, http has a very request/response oriented pattern. Moreover, one of the key pieces of information that you need to know about a SOAP message is what action you're supposed to perform. Well that was kind of embedded in the http header, and we had this kind of request/response model. So the next piece up is the notion of WS addressing, where WS addressing provides the infrastructure necessary to make messages that can travel without piggybacking on that http request/response model. So it allows us to send one-way messages, things that might come one way back to you, which we often call an event or a notification. It also gave us a way to take the information that was typically in an http header -- the to, the from and the action -- and move that into the SOAP body proper where it could be secured and so on.

Jump to #18 ROBERT HESS: So it's kind of like on a standard Web style request, I've got the HTML of the document, and then I've got this header thing outside of that that is describing the path and processes like that, which makes these two totally diametrically opposed things. You're talking about pulling that together, so it's almost like the HTML had all that inside of it.

JOHN SHEWCHUK: Yeah, we took it out of the HTTP part and we put it into the body -- well not into the body, into the SOAP message itself, into the headers -- and then the body goes along. And so what we ended up with is now this completely self-contained piece of information consistent with the SOAP info set that could be transmitted through the network, and when you received it you had everything you needed to know about how to process it, who it was from, where it was destined for -- if it wasn't for you, you might need to forward it on. So it really kind of packaged the things together. So that's really one of the key pieces of the architecture, and interestingly it came a little bit later in the game.

Jump to #19Now above that basis where we've got now the ability to send these messages around and we have the metadata for describing these things, the WSDL, the big things that we needed above that were the security, the reliability and the transactions. And so in each case we worked through those things. Security came first, then we started fleshing out the transaction space. Ttransactions and in particular the coordination specification was really one of the things that drove that WS addressing piece that we were just talking about. And then the reliable messaging piece came built on those. Throughout all this we needed a way to describe the various options that a service can support, and that's where WS policy came from. So those were really kind of the key pieces. Addressing, WS security and related specs, WS transaction and coordination, the related specs there, and then the WS RM specification all tied together with WSDL and policy.

Jump to #20 ROBERT HESS: Let's spend a couple seconds where we talk about each one of the security, transactions and reliability just so people understand kind of what that's providing and how it's being implemented. So when you talk about security, security can mean all sorts of different things. It can mean security against viruses, it can be security against people reading messages that shouldn't be reading it, it can be security about knowing the information is getting some place, but I'm assuming that's what reliable messaging is happening. So when you say security, what is that encompassing, how is it implemented?

JOHN SHEWCHUK: Well security in a distributed, service-oriented architecture is a pretty interesting thing. If you looked at a distributed object system, what people have traditionally built, it's not always the case but kind of the assumption that was made was this notion that the other objects were, once I had connected up to them I was kind of secure and able to communicate with them. When we move into the really distributed world where everything's potentially out on the Internet, well, security requirements become a little bit heavier. We need to make sure that every communication that comes into a service is checked and has the appropriate credentials. But one of the challenges in such an environment is how do you do that kind of security processing quickly enough? And most of our existing systems have been built around the notion of an Access Control List, where we take someone's identity, we then go look up their identity in a table, and then if they have the right permissions then we allow that operation to go on.

Jump to #21But now imagine you're in this distributed world and you're seeing tens of thousands, hundreds of thousands of messages per second. Well, it would be unfortunate if every time a message came in you had to go through that entire process each time. Verify that the message is from so and so, that they have the right permissions, that it hasn't been modified, taking off any encryption so that nobody could see the message in transit. Well wouldn't it be great if we had a way to associate things like the actual permission to do something, a capability, directly with a message? And wouldn't it be great if there was a universal way that we could both encrypt the message or sign the message that everybody agreed on? So that's really what WS security allows you to do, and that's that core building block of the security system.

Jump to #22 ROBERT HESS: So it's basically like attaching a certificate into the message?

JOHN SHEWCHUK: Yeah, so imagine a certificate's like a driver's license or a credit card. I can attach that to the header of the SOAP message in such a way that if you tried to pull it off, you could tell that the message had been modified. If you tried to change the body, you would be able to tell that the body had been changed and it doesn't match the signature that you've put on this. The other thing you need to be able to do is encrypt it so you can ensure the confidentiality. Now people have had ways to do this before. We have https, which is a great way to transmit information around. One of the challenges with https, though, is that is has the same kind of characteristic that http had, which is it kind of bound it to the http transport and not to the message.

Jump to #23So imagine the following scenario, which happens all the time in large companies. They get a message in from one of their suppliers, and they get it on the edge of their network where their Web server is. They look through it and they decide, oh, you know what? One of our sister companies, one of our partners, is actually going to end up processing this, and they'd like to forward that message on. Well, if they were to go forward it and that security information was not associated with a message but instead was associated with a transport, the http in this case, well when it got to the other side you wouldn't really know that it came from the original sender; it would seem to come from my company, which, if we had the right kinds of trust relationships, is fine. But it kind of limits the scenarios that we can use for WS security.

Jump to #24 ROBERT HESS: That kind of gets into the whole thing we were talking about earlier about taking the information from the transport headers and bringing it into the actual message body exactly.

JOHN SHEWCHUK: Exactly. Now, so this has all been going on, we've been working on these specifications, we've been trying to build this interoperable service-oriented architecture. So in parallel we were building a software suite, we were building Indigo. What Indigo was designed to do was be an extremely high performance message processing system. And it's very flexible with regard to the transports and the way messages are encoded and the kinds of message exchange patterns you have. So one of the things that was going on as we were building this is we were making sure that we had a good way to process these messages and also that we had a programming environment built on top of that processing engine that made it incredibly easy for developers to do these kind of things like WS security. So you can imagine if you were to take those specs that we've been talking about and read through them, you'd see all this gobbeldy gook about XSDs and WSDLs, and this is the way the packet headers have to look, and this is the way you need to do the XML encryption and the canonicalization, and that's a lot of code to write. In fact, we once did a little experiment with IBM where we built a managed supply chain using those specifications, and we just counted up the number of lines of code, and it runs about 60,000 lines of some of the trickiest code you've ever seen. We brought in experts in security and transactions and reliable messaging, and it's a lot of work.

Jump to #25So the key with Indigo is that we've taken all that expertise and we've built it into a set of libraries to make it almost -- our goal was to make it falling-off-a-log easy to implement those kind of capabilities. So as an example, you can pick up the .NET Framework today and you can build WS security with it. You do it all manually. You'd have to write some security code and a bunch of other things, and we've made it a little easier because we have a toolkit that my team does called WSE, the Web Service Extensions for .NET, and it provides some great libraries for security and really cuts down on the security code and makes it much easier. But what Indigo does is it not only provides that runtime message processing environment, but it also provides a really great programming environment that builds on the work we had done with Enterprise Services and attribute-based programming, so that we can go up to an entry point in our code and we can just decorate it with an attribute that says, I would like confidentiality on this. And the directive described by that attribute will describe to the Indigo message processing engine how it should associate the appropriate credentials with the message, how it should sign the message, and then it will get that out over the wire in a way that's compatible and interoperable with other folks.

Jump to #26 ROBERT HESS: It's kind of the same way that if you wanted to write a Web Service, you stick a Web method as a decorator. now you're sticking decorators. And we'll be seeing actual code examples of that later in this episode.

JOHN SHEWCHUK: Yes, Steve's going to walk us through that. And that's actually been, I mean Steve was one of the key drivers. Really, he did an amazing thing. He took the low level message-oriented world that we have and that model that we've had around Enterprise Services and they brought it together into a really seamless consistent whole built around a couple very simple ideas: the notion of a port, a message, a channel, and a service as building blocks for this very rich environment for people to go build applications that have the characteristics of Web Services.

Jump to #27 ROBERT HESS: Okay, so we touched upon the security aspect and a bunch of other stuff associated. Let's maybe touch briefly on the transactions and reliable messaging and how that fits into what people are actually needing to accomplish in their applications.

JOHN SHEWCHUK: Great. So, you know, think about a Web today. If I were building a Web site and I wanted to go do something like ordering pizza off the Web, I don't know what it would happen to be, there's a bunch of tricky issues. If I go up to the Web site and I enter my credit card and I say I want to order the pizza and I hit Order, well, it might not come back right away. So what are people tempted to do?

ROBERT HESS: Hit order again.

JOHN SHEWCHUK: They're tempted to hit Order again. So now we've sent two messages up to the server.

Jump to #28 ROBERT HESS: And I just had an order I did the other day, and I hit it, and I knew, like, you don't want to hit it again. I waited and waited and waited, finally I gave the guy a call on the other end to say, did you take my order or not?

JOHN SHEWCHUK: No.

ROBERT HESS: Yeah.

Jump to #29 JOHN SHEWCHUK: Yeah. So what developers are forced to do today is they're forced to build in some logic around these kind of scenarios, and it's pretty straightforward to do. You get some kind of an agreement on say a sequence number or some unique ID that you use to transfer these things around so that you can do correlation on that, and you write that code. You're also going to need to get these things into databases so you have some sort of database synchronization, and then you're going to go make the order and you're going to move money around and often that involves some sort of transaction. And we see these kind of things going on all over the place. So we looked at what people were asking for in the area of transactions, let's start there, and really we heard kinds of two things. One thing we heard was that well, you know, I have existing systems. I might have an IBM mainframe that I use to handle financial operations inside our organization, and I might have some Windows boxes that are used for manufacturing on a manufacturing floor. And I'd like to make sure that I don't update the financial databases until I've actually ensured that the order gets down to the manufacturing system. So I'd like to do a distributed transaction across these things. And that's not an uncommon thing for our customers to ask us for, particularly inside the enterprise. So we wrote a spec called WS transactions, and a key part of that spec was a kind of sub-specification which has now been broken out called WS atomic transactions. And it's a way to do the traditional two-phase commit style transactions in an interoperable way. The other thing that we know is that if you're in a distributed environment and you're trying to do transactions across organizations, nobody does an atomic transaction across organizations. What they do is they build business logic that understands how to do compensation. So if I send you an order and then I later decide to cancel the order, I don't say undo the order in a transaction, what I do is I send a different message, which is the cancel my order message, and we go through a process for canceling the order and that might involved a bunch of different steps. So we have a specification called WS business activity, which describes how to do some of these compensation oriented systems.

Jump to #30So we think that in the transaction space, we've got some of the basic plumbing that people need for interop with existing systems, particularly systems that do two-phase commit. And we've got a good framework to be able to start building these kind of compensating transactions. Now when you look at compensating transactions, one of the keys to being able to do these things effectively is the notion of getting a message there reliably. If you can believe that when I send a message to you it's going to get there and I don't have to hit this thing or I'll get notified, that would really help businesses put things together, and so we have a specification called WS reliable messaging and it describes how to send out messages, to put sequence numbers on them, it walks through the kind of state transitions that the endpoints will be in in order to understand that the messages got there. And that specifications, again, nice, simple, small specifications like all these WS specifications, and we've had companies out there interoping already on almost all of these pieces. So we just finished up a workshop where we brought a bunch of companies together and we had very good results interoping on that. And again our job with Indigo is to take all those specifications, build it into that message processing engine, and provide a great, rich easy to use programming environment that Steve will walk us through to see how to put that thing together. So that's been the general game plan around Web Services and with Indigo.

Jump to #31 ROBERT HESS: Now you're constantly referring to Indigo as kind of a, I suppose engine, for lack of a better word. So the specifications really aren't Indigo; Indigo is this engine that is implementing the specifications?

JOHN SHEWCHUK: That's right. These specifications can be implemented on lots of different platforms in a lot of different ways.

ROBERT HESS: Which is kind of the whole benefit of them.

JOHN SHEWCHUK: Yeah, exactly right. So IBM is building them into WebSphere; BEA is building them into their application server; and we work with all kinds of different companies. SAP is doing it; they're building support for these protocols into their environments. What we do is we also build software in conjunction with working on those specifications just like everybody else, and our hope is that the particular software that we build, the message processing engine, will be very fast and very capable and very flexible. More importantly, we think that the key thing is that it's very simple and very well factored and very well thought out so that when developers sit down and they want to use our system, not only does it give them the kind of performance and the capabilities, but they find it very easy to use. So from the ground up, we really built that engine and a programming environment -- Steve's one of the experts and one of the key drivers in that programming environment -- that's the combination that we think could be pretty killer.

Jump to #32We're excited about the fact that people have been out there playing with this stuff. We released our first round of bits at the PDC and the feedback's just been phenomenal. People love building these things. I mean just to put it in a little perspective, if you were to try and put together a distributed system that consisted of an application in your company talking to somebody else's company or maybe a couple of other companies, and you wanted to use a service-oriented architecture to do this, traditionally what people have done is they've had a lot of work. They've had to go write down some protocols, they bought very expensive products like MSMQ or MQ Series from IBM, if they wanted an event distribution system they bought a product like Tibco, they bought a transaction monitor, and so we're talking potentially many millions of dollars for a bunch of nodes here just for the software. Then you've got to integrate all this stuff. And even after you're done, well now you've got a custom solution. And so really getting these things to work was a major undertaking that only the largest companies could really engage in. And even when they did that, the likelihood that all of their suppliers and their partners would be able to interact with the system was very low. So I think the exciting thing about the service-oriented architecture and Web Services is that we're taking all that technology, we're putting it together, and we're platformizing it. This will be in Longhorn, this will be running on top of Windows XP as part of the Service Pack, it'll be running as part of Windows Server 2003 with a Service Pack. But you know when you have Windows you're going to have that engine. You're going to have all of the technologies that you need in order to build one of these systems, and it's not just that the software is there, but it's going to work with all of those other partners. That's just an enormous leap forward in the kinds of applications you can write just using the platform. So we're pretty excited about this, and our customers -- the thing I hear over and over is, when are you going to get this thing out? Let's get this thing out as soon as possible.

Jump to #33 ROBERT HESS: So you mentioned the programming ease of use you're adding to it. Now you're talking about the programming not just for programming the server-side component, but also the client components. And the benefit there would be that let's say some company's doing a Web based server architecture, something like that, and I don't know what they're working it on but they're using the specifications. I can now take and easily write a client application that calls into their server that might be running on a Web server, might be running on a Linux machine or something like that, I don't need to know what they're doing. As long as they're following the protocol and the specifications, I now can program against that real easily.

JOHN SHEWCHUK: Yep. Now the other thing, you used two words that we're a little sensitive about; you used client and server.

Jump to #34 ROBERT HESS: Okay. I though that's how you always talk about it; you've got clients on your desktops and servers back in the back room.

JOHN SHEWCHUK: Yeah, but we don't think that these kind of technologies are just limited to clients and servers. So we use the terminology services, and we think services should be everywhere. So our cell phones should be services, which people traditionally think of as clients. So services can run in a wide variety of environments, so peer to peer kinds of topologies, the traditional client-server kinds of topologies, topologies where our clients get richer and more capable, so home environments -- all of those things are environments that we think of as service environments. Moreover we think that there's this very interesting thing going on in the industry. We've been working with a UP&P forum, and people have been doing things like taking routers or disk drives and they've been adding Web Services to those things. So even your base computer system is starting to pick up the notion of services, so that your individual machine, some of the pieces within there you might start to communicate using the same kind of architecture. So it's not just limited to my client to some big thing in the sky. Think of it as a general way to communicate.

Jump to #35 ROBERT HESS: With things.

JOHN SHEWCHUK: With any kind of thing. So any time your application wants to communicate, we think we've got some great new abstractions to make that possible. So Don Box at the PDC during the keynote did a pretty interesting thing.

ROBERT HESS: He always does interesting things.

JOHN SHEWCHUK: Yeah, well that's Don. So he went over to the sidebar and he put up a little widget on the sidebar that was an Indigo service. So what you might normally think of as something on your client -- and you could imagine if you're in a bank where you need to do notifications to tellers or your stock trader, you might need to get information to the people looking at the screen -- so we've got a little object up on the sidebar where it can get some attention, and that's an Indigo service. So it speaks Web Services. Then what Don did is he wrote an app on the desktop and that app sent a message using the cross process transport from the client over to that system. So when we use the cross proc transport, we didn't need to go all the way down that network stack, we didn't need to go down to http, we just did a very high performance movement of the message from this process over to that process. And the great thing about Indigo is that that...

Jump to #36 ROBERT HESS: I believe that's the same demo he actually did on the previous episode as well. I know he did something in the sidebar and he was doing a proc, and it was the sort of thing you'd have normally done with Winsocks or something like that.

JOHN SHEWCHUK: Exactly. Well, today the way you would typically do that is you'd actually use something like a local RPC mechanism or named pipes. Here's the amazing thing that Indigo does is it takes all of those different ways that we've had to communicate -- sockets, named pipes, system.messaging, so our MSMQ technologies, ASP.NET style Web method technologies, remoting, enterprise services -- and it brings that whole package together in a way that is interoperable, simple, easy to use, and it completes the matrix. And by that I mean it does security, it does reliability, it does the transaction pieces, so things that were in Enterprise Services, like transaction support, are now part of that model. Things like the higher performance of remoting are brought into the model. So it really gives you a single package where you can go and you can get your job done. And you'll learn a couple simple ideas: the port, the message, the notion of a channel to process these things, and your service, and you've got everything you need to communicate with anything.

Jump to #37 ROBERT HESS: So if you know how to talk from your app to the sidebar component, you also know what you need to do to talk to your app, to another application across the hallway or across the world.

JOHN SHEWCHUK: Exactly.

Jump to #38 ROBERT HESS: Well that's kind of exciting. So now in the Longhorn timeframe, is anything coming into this, or is Indigo just simply evolving into Longhorn? Or what does Longhorn actually bring to the table?

JOHN SHEWCHUK: So what Longhorn brings to the table is our next rev of the operating system. And Indigo is a key piece of the operating system. It's built in in a way that we can use the lowest level pieces of the system to enable message processing in a way that people really haven't spent too much time doing in these higher level systems. So as an example, if I'm using a transport and that message comes into my network card, in Longhorn, because of some new work that we've done inside the device drivers, we're able to actually move the bits off that network card buffer directly up into the user mode where the code waiting for that message exists, and process that message without lots of extra buffer copies. So traditionally when people have built these network stacks, they've gone from a socket layer up to an RPC layer up to an application level messaging...

Jump to #39 ROBERT HESS: Taking one step at a time, the longer route.

JOHN SHEWCHUK: Yeah, and they'd be pulling the bits across each of those layers, and so you'd have lots of buffer copies, you'd have lots of message transformations going on. And so by building it in as part of the operating system, we're able to put in the kinds of shortcuts that enable higher performance and more robust processing. We can do things at a lower level than you'd be able to do up in user mode. So we're able to take advantage of some key features in Longhorn for both performance and we've added some new capabilities in for things like processing recycling, port sharing on transports other than http, so those are the kinds of things that Longhorn brings to the table. Now this operating system code that we're providing, we're going to take that technology and we're going to put it into our existing operating systems -- XP and Server 2003 through a Service Pack -- so that you'll get those technologies, but you won't be able to get some of those advanced features that I've been talking about, things like the multiple transport sharing that we have in Longhorn.

ROBERT HESS: The things that take an awful big change in the operating system itself in order to enable.

JOHN SHEWCHUK: Yup.

Jump to #40 ROBERT HESS: Yeah. Now when we talk about Longhorn to people out there, they always kind of say well gee, you know, Longhorn's still a ways off. And they want to know how they can actually be prepared for the Longhorn technologies today so that the code they're writing right now isn't outdated by the time Longhorn comes around. What's the best process of thinking through of writing code that is evolving towards this Indigo model?

JOHN SHEWCHUK: Well there's a couple things folks can do. The first thing you can do is you can go get the bits for Indigo today. They're in the PDC build; we'll have another release out this year; we expect to be in much better shape. I mean, just to put a little perspective on where we are in the development cycle, and I'm not making a prediction or anything here, just to help people understand, we're in our last milestone of coding for features. That should finish up by the end of the summer. That being done we're finished. But we think that there's a couple big challenges in this piece of software, so we're giving ourselves plenty of room, we're going to get a couple of betas out, make sure that this thing is solid. But I don't think we're very far away from having what really is kind of a final look at all the abstractions that are in Indigo. So you can certainly do that and that'll give you a good way to see where things are going.

Jump to #41The other thing that people have wanted to do is they've wanted to implement Web Service technologies in a service-oriented architecture today. And you can do that. You can take the .NET Framework, which is a fantastic way to go build Web Services, it has great support for WSDL and SOAP and putting these systems together, and you can do that right off the bat. Now if you want some of these more advanced capabilities we, as I mentioned before, have a toolkit, the Web Service Extensions for the .NET Framework, that adds in support for things like WS security, for WS policy and so on. Now to put a little perspective on that, we offer WSE as a way to help people who would normally be coding these things by hand. So when you sit down with WSE you're kind of getting a head start on the model. Now we don't claim that WSE is going to look exactly like Indigo. The other thing is WSE is designed to help people track those latest specifications, so as the specifications evolve, we change WSE pretty regularly to track those latest versions of the spec. So it's designed for people that are really out there tracking the specifications, trying to build those leading-edge technologies. Now what we've done is we've said, if you continue to upgrade your software using WSE, we'll make sure that the last version of WSE and Indigo can interoperate, and that's a good way to get some code out there, get it set up as a Web Service, and then as Indigo comes along you'll be able to integrate those pieces together. And that's actually kind of the way we think the world should work with a service-oriented architecture. It shouldn't matter that you're on exactly the same code base. It really should matter are you conforming to the right ways to do the application. So if you can break your application into some pieces, you can get started on it now, you can get those things running on wizzy, and there's nothing that says you have to go change the code. If you're content on wizzy, keep running on wizzy.

Jump to #42 ROBERT HESS: And that's where the specifications become really important because everybody's following the specification, and that's what's going across the wire.

JOHN SHEWCHUK: That's right. So in that regard again think back to HTML and http. As long as we got the right format on the wire, we're pretty sure that you can look at it with the browser.

Jump to #43 ROBERT HESS: And things still work on it. Now we've talked about kind of some of the existing application models and how you can use reliable messages, transaction messages and secure messages. Do you see the types of programs coming out that use Indigo just simply being the same programs you've always had just now easier to program? Or do you maybe even see a new type of application that is enabled because of Indigo?

JOHN SHEWCHUK: Well, if you really step back and you think about this service-oriented architecture that people have been building, people have been building applications like this for many years. It's just been really hard. Again, you'd buy a lot of software, you'd get a whole bunch of PhDs in a room and a whole bunch of consultants, you spend a couple years working on it and you could build an application like this. Our goal is to really reduce the barrier to entry for everybody creating applications like this. So I don't think this necessarily enables new kinds of applications, if you will, but it just makes it possible to create these kind of applications that have been to date so expensive to produce that we're going to see more of those applications. Now what categorizes those applications? Well almost anyone who works in a large organization does things where they take information from this system, they combine it with information from this system, they process it, they send it off to other systems, they connect up their partners, so that kind of processing has gone on inside of large corporations for a long time and we think Indigo is going to make building those kind of systems much much easier.

Jump to #44But for other kinds of developers, folks who might have been building Web sites today or people who might be hobbyists, those kind of applications have just been out of reach; it's just been too hard. So imagine you're putting together a Web site, your own personal Web site, and you might want to have a blog, and you might want to connect together with your friends, and you might want to do a game or something like that. Well it's a lot of work if you want to do all that communications technology by hand. So guys like Sam Ruby and Don Box and others have been thinking about how we can take the blog technologies and put it onto a Web Services interface. And if you do that then you get the interoperability and you can take something like Indigo, point it at your friend's blog, say there's a channel to their blog, now let's start exchanging messages to see what postings they have, you can put them down the sidebar. So we're going to make it much much easier to build applications that are not just about UI or just touching local resources, but really connecting together people, connecting together other systems, data. So the world of applications is really about to change, I think, in the way that communication becomes a much more central piece of the traditional application.

Jump to #45 ROBERT HESS: It's almost like suddenly applications that might have wanted to use communication in the past but just because of the high leap it took to get there didn't. Now suddenly they can do it. Suddenly, you know, calculator will be using Indigo to communicate across systems and to send my numbers that I'm calculating on my calculator to some other system.

JOHN SHEWCHUK: Well but -- so let's take the calculator as a great example. Suppose that, you might write the calculator and it does a lot of local functions, but couldn't the calculator be a lot richer if for example it could pick up currency information? Or if it could do things like use location services, so that on your mobile phone not only could I look up the currency from a bank, but if I knew where my current location was, I could call out to a service, find my current location, use that to determine the currency, and provide additional kinds of capabilities inside the calculator. I think that there's many opportunities, but people haven't done those kind of things in calculators just because it's a lot of work to do that. And if we could make the plumbing part of that work go away -- because obviously you're still going to have to do the work to integrate the applications -- but if we can remove a lot of that infrastructure work, I think people would be more inclined to put those kind of integration features into their applications.

Jump to #46So another great example of this kind of thing is games technology or streaming music technology. When people went and thought about building our streaming media technologies here at Microsoft, originally the design was centered on let's use TCP, because TCP gave you a bunch of the infrastructure. But you know what? TCP doesn't do exactly what you want for media. TCP has the characteristics that if you miss a packet, then you stall the pipeline asking for that packet to get retransmitted, and that's not a good music experience. So what do you do? Well you switch into using UDP and then you've got a lot of work, right? You've got to go do all your own kind of sequencing so that you can determine what packets have been missed and so on. Well once again, by using a technology like Indigo and using predefined specifications like reliable messaging, we're able to produce a protocol like the streaming media protocol that might be more appropriate for your application without you having to do all that low level networking work.

Jump to #47 ROBERT HESS: Because for the most part the same sort of reliable messaging that a streaming media application's going to need, other applications need that same sort of thing as well. They're not playing media back, but they might also need to take and make sure they're getting packets in a timely fashion, in the right order, not stalling the channel and stuff like that.

JOHN SHEWCHUK: Exactly. Another thing that Indigo does which I think will be pretty interesting for folks is it allows communication patterns that are a little more than the request/response that we were talking about with http. So a great example of this kind of thing is the typical publish and subscribe style model. I might want to subscribe to a new service and I'd like to be notified proactively to my cell phone for example if news on -- I don't know, let's say I was interested in soccer or fencing or some other kind of sport that here in the United States might not have as much popularity -- well if I could create my own kind of notifications of those things integrated into my application, I could produce new kinds of applications that today I might now even think about doing because of the expense and effort required to put that together.

Jump to #48 ROBERT HESS: And today I know we have the .NET Alerts and stuff like that, which kind of supports that same sort of thing, but there that's requiring an outside channel to be the middleman between those things. You're actually talking about Indigo supporting it from let's say client to server or service...

JOHN SHEWCHUK: Exactly.

ROBERT HESS: ...whatever is creating that eventing sub structure that they're not relying upon some third party to support it for them.

JOHN SHEWCHUK: Yup. So many big enterprise applications rely on an event-based message-oriented solution. Tibco is a very popular product for distributing stock information inside of companies and so on. So that same model, that same service-oriented model where I can say, I'm interested in this kind of information and this kind of information, and the person producing that information doesn't even really know who might be getting that information. We can do that. So it gives you a much looser coupling to your apps and able to integrate those things. That's why we call it the message bus.

Jump to #49 ROBERT HESS: Get on the bus.

JOHN SHEWCHUK: Yeah, get on the bus, right, you got all this way to send messages in there, hook into it. So really what Indigo gives you is that bus connector. So you hook up a port, which Steve will talk about, it gives you an address in network space, you then get and receive messages through that port, through these channels, which give you different kinds of communication patterns, whether it be pub/sub or request/response or one-way messages, whether you want it to be durable, whether you want it to be secure, channels give you that level of control and then they get delivered up to your service. And your service can describe itself to other services through things like policy. So it's a pretty great way to string things together.

Jump to #50 ROBERT HESS: Well thanks. I really enjoyed talking to you about what Indigo is and cleared up some of the issues and explained these things. If you could maybe encapsulate what you think, being the Indigo god that you are, if you were to talk to the audience, give them one short sentence of this is what Indigo is and this is why you should pay attention to it, what would that be?

JOHN SHEWCHUK: Oh, I don't know. I mean there's a lot of ways we could talk about it, but if you really wanted something succinct, kind of think of it as the universal communicator. It's the one little tool that you've got in your toolkit that'll connect you into anything, and we think connectivity is going to be a much bigger deal moving forward.

ROBERT HESS: Okay. Well thanks for joining us, John. I appreciate talking with you and hopefully you answered some questions people had about what Indigo is.

JOHN SHEWCHUK: Thanks very much, Robert.

Jump to #51 ROBERT HESS: Well hopefully that allowed you to understand what Indigo is and how it takes and plays a role in the communications infrastructure of applications. Now in the next segment we're going to actually be seeing some application programming and how Indigo develops applications that allow you to communicate with other apps regardless of what platform they might be on. But stay tuned; after the short break we'll talk about programming.

Jump to #52 DIVERSIONARY TACTICS
Ever wonder what the "man on the street" knows about firewall security?

Jump to #53 ENTER THE PROGRAMMER
Robert Hess meets with Steve Swartz to look at how you will be able to easily add support for secure, transacted, reliable messaging with "Indigo" to your .NET applications

ROBERT HESS: Welcome back. Now you've heard already about what Indigo is from the architectural standpoint, and it's probably about time we dive in and actually show some programming and what actual coding looks like, because as you know if you can't code to something you can't use it. Here to talk with us about what it means to program with Indigo is Steve Swartz. Hey Steve. Thanks for joining us.

STEVE SWARTZ: Hi, how are you?

Jump to #54 ROBERT HESS: Pretty good. Now I understand you're kind of responsible for some of the programming architecture associated with Indigo.

STEVE SWARTZ: Yeah, my team owns the top level programming model for Indigo. So there's teams that own the infrastructure, how to get a message from point A to point B, writing all the transports. My team builds a programming model on top of that to make it very straightforward to build applications, so I'm the high level guy.

Jump to #55 ROBERT HESS: So what does it mean to think about the programming model? I mean John talked about the specs for Indigo and thinking through the packets and the transports and stuff like that. But now you've actually got to think okay, when the pedal comes to the metal, what goes on the screen in the code for me to actually get to those Indigo messages?

STEVE SWARTZ: Exactly, so my job is to figure out how to make the whole thing approachable without having to know anything about the specs and stuff that John is talking about. It's great to know that that stuff's there, but in fact what you want to do is just build a transacted app or build a secure app. So our goals look like this. First off we have a variety of products in this space right now. We have ASP.NET web methods, .NET remoting, Enterprise Services. One of my design goals is to make a programmer familiar with any one of those products look at Indigo and say ah, that's the next step in my product, mine was the winner. So I'd like a .NET remoting guy to be able to walk up here and say ah, this looks very familiar. Similarly with the Enterprise Services and ASP.NET people.

Jump to #56 ROBERT HESS: So it would be unlike the model of a Win 32 programmer having to learn how to do Ole programming.

STEVE SWARTZ: Absolutely. We're trying to avoid that as much as possible. Quite the contrary, we sort of think that each of those products has things that are really useful about it. So what we're trying to do is to bring all those useful things together in one model, but you avoid buying six different books, one for each thing you have to use. We want to have one product that does everything.

Jump to #57 ROBERT HESS: Aren't the book publishers going to complain about that, though?

STEVE SWARTZ: Well, I'm not a book publisher, so. Some of my best friends. The second goal we had is that in most of the other programming models there's a big leap between programming at the high level and dropping down into the infrastructure. It's pretty straightforward to code .NET remoting, but if you want to start learning about adding your own transports there's a big leap in the level of complexity. And what we're looking for with Indigo is a very smooth transition between somebody that wants to program at the very high level and look at just simple method calls with integers going far away in a standard mode, but at the same time if someone to get down and see the messages or they know that there's a SOAP event message down there, they want to add their own headers, we want to make that very simple so that each step you take towards the infrastructure is a simple step. You don't have to leave the rest of our high level programming model behind, you can get these things one feature at a time.

ROBERT HESS: That sounds like a pretty difficult chore to me.

STEVE SWARTZ:It's fun.

Jump to #58 ROBERT HESS: Now are we working within the .NET Framework and the CLR and stuff that like still, or is this a different model?

STEVE SWARTZ: Oh no, absolutely, this is a .NET programming model. It has its own namespace; the names are changing all the time. Right now we're calling it service model. So this is the model you use to build service-oriented architectures. And it's based on building CLR types that map to WSDL types. So in WSDL you have a service which is an implementation of a program that's addressable and does work. And that service implements one or more port types, which are a group of actions that can be sent to it, and then a bunch of operations, which is the specification of the individual action. So we have service, port type and action. That's a very similar idea to the CLR where we have classes, interfaces and methods. And so what we do in the CLR is we let you build a class, and if you want it to be a service you just decorate it with a service attribute. You identify the port types by decorating them with a service interface attribute, and you identify the operations by using a service method attribute. So we use the attribute model that's already in the CRL to map between CLR ideas that we're really familiar with and the corresponding service ideas that are in the WSDL standard.

Jump to #59 ROBERT HESS: And a benefit of this is that since it's all using the CLR, that means any of the .NET languages, whether it's C#, C++, VB, Cobol, whatever, can use Indigo in the same fashion.

STEVE SWARTZ: Exactly. You can be a very modern programmer in terms of adapting the new service-oriented architecture using your favorite language.

Jump to #60 ROBERT HESS: Well let's take a look at some of the code.

STEVE SWARTZ: Okay. This first example is -- what I have here is three or four examples. And I have the code for the client side and the server side. And what I'll do is show the server side first in each case because the server side is usually the side that defines the contract we're speaking, and then I'll show the client that's talking to it.

ROBERT HESS: You know, John made it clear to me that it's kind of an issue with client/server and there's then this services we're talking about here, so we're going to be showing services interacting here.

STEVE SWARTZ: Right. I'm an old-fashioned guy, and so when I use the word server I'm talking about the piece of code that's sitting around and waiting for work to come its way.

Jump to #61 ROBERT HESS: The responder.

STEVE SWARTZ: Right, the passive waiting responsive guy. And the client is the person who up and initiates contact. And there is an asymmetry in the service-oriented architecture between the initiator and the initiated if you will. In WSDL there's a notion of an in message that goes from me the initiator to you, an out message that goes from you the initiated to me. So the direction of in is from the initiated to the initiator and I use the old-fashioned words of client and server.

Jump to #62 ROBERT HESS: That works for me.

STEVE SWARTZ: There we go. So what happens is that if I look at this class to start off, I've got a normal class, it has a single method, the method is place, meaning that's what I use to place an order, and the class is an order processor. And I've left out the implementation because it's kind of...

ROBERT HESS: It's just code.

STEVE SWARTZ: It's just code. The fun part. So if I want to make this into a service, what do I do? I add a service attribute, just a simple service attribute, and what that announces to the system is this class is now something that I can register with it as a service. If I go ahead and just put that attribute and nothing else, it will be an empty service and we have the philosophical conundrum of a service without a method, was it ever really run. So what I do in order to make some of the methods available on the service is I use the service method attribute, put it on this method. So what I've done here is define a CLR construct of a service with a single implicit port type and one method. So you see I had this class already, I wanted to make it into a service. All I've had to do is add these two attributes.
[Service]
public class OrderProcessor
{
	[ServiceMethod]
	public void Place (string CustomerName, string  ProductName, int Quantity);
	{
		// Process Order
	}
}


Jump to #63 ROBERT HESS: So when you said a port type, is a port type is an order processor, is that where the port type's coming in?

STEVE SWARTZ: Well what happens is is that in order to make this easy in the very simplest case, when you haven't explicitly defined a port type, we'll make one for you which is all the service methods on your service. So I'll show you an example later where we're explicitly defining this, but in the simplest world we're saying a service that only implements one port type, there's no need for you to write that interface in too, you can just build a class and get going. This is the kind of mode that you would operate in when you were just starting with a product and not really doing something too complicated. So down below I look at the hosting class; this is a class that implements main that will host this particular service. So when I run the executable that this class turns into, all it will do is come up and start the service. Now Indigo also works within the ASP.NET hosting model, and it uses the same syntax, a little angle bracket line at the first line to tell ASP.NET to do its compilation and loading trick. Here I'm showing you how you can also host Indigo in any process you like. So this process could be a Windows Service, it can be a console app, it could be anything. And now we're going to start seeing some of the things John was talking about. The first thing I do when I'm starting up an Indigo app is I create a port. So here I've created a new port, and I've created that port with an address, and I'm just having it available at myServer, so there's the port that we've talked about.
public class Host
{
	public static void Main(string[] args)
	{
		Port port = new Port(new PortAddress("http://myServer"));
		port.Services.Add(new ServiceAddress("/OrderProcessor"), typeof(OrderProcessor));
	}
}


Jump to #64 ROBERT HESS: So we've got an http address there, myServer. Now is that actually a physical name that's being DNS associated with this machine, or is this just a name you picked out of the blue?

STEVE SWARTZ: Well, in this particular case I picked this name out of the blue. It's a virtual root on this machine. Obviously the Web host mechanism, the thing that's doing the job that IIS does now, has to know about that as a vroot and publish it out into DNS for it to be available off machine. So these are just the same as any other URL in terms of the security mechanisms I have to keep them from being accessible or to turn them on. It's being managed by that infrastructure.

Jump to #65 ROBERT HESS: So it's not like a named pipe where I just think up a name and as long as the other app knows the same name we're talking with , this actually is a physical accessible address.

STEVE SWARTZ: Right. Within the bounds of trying to keep these things secure, which is obviously important since they involve communication off machine, the ASP.NET and IIS teams are working very hard to make it almost as easy as named pipes. So when I install this system I can automatically add the vroot, so I get the simple XCOPY installation that I get with ASP.NET, but this automatically comes up. But if I'm doing it manually like this, you're right, I've had to establish that address as something that's available on my system to be able to see if off machine. So then what I do is I walk up to the port, well the port has a lot of collections. It has collections and methods I can use for all sort of things. In order to host a service, what I do is I go and get the services collection and add the service type to the port. So I go and create an address here, so this particular service is going to be on myServer, which is the address of the port, and under myServer at OrderProcessor. So here I've taken a service address and the type of my order processor class and I've added them to the port. So it's very simple. I create a port which is the named location in network space, here, myServer. Then I've added a service to it at its own special address. The moment I do that, this class is now sitting here ready for messages to come, and it will process them and answer them. So what I've done is I've written a class, put the attribute on it, then I've created a port and added that class. So this is the basic mechanism for building services.

Jump to #66 ROBERT HESS: And then I assume then all you do, you do a port.place and that would then call the place object in the order processor?

STEVE SWARTZ: I'll show you that in a second when we look at the client side.

ROBERT HESS: Okay.

STEVE SWARTZ: But it's one more thing that's interesting to think about. If I go up here to this service and I want to make it secure, what I do is I just add an attribute called ServiceSecurity and now the mechanism is secure. And if I wanted to go, there's all sorts of properties on that attribute that let me do confidentiality or integrity, encryption of various sorts, all those things are just properties on that attribute. So making this secure or reliable or transacted is merely a matter of adding the appropriate attributes at the appropriate place. So if I want to make my whole service secure, I put the ServiceSecurity attribute. If I wanted to go down here and add transactions to a particular method, I can go and use the TransactedCoupling attribute and that lets me go ahead and put attributes here that would say I want to flow transactions from one service to another, which I can do if I'm local. Or I can say I don't want to flow if I'm going to talk to someone far away. So all the business of doing the things John was talking about in terms of adding the protocols and all these headers that apply to various standards, all you have to do to use that feature in this system is just add an attribute to the appropriate place.
[ServiceSecurity()]
[Service]
public class OrderProcessor
{
	[TransactionCoupling()]
	[ServiceMethod]
	public void Place (string CustomerName, string  ProductName, int Quantity);
	{
		// Process Order
	}
}


Jump to #67 ROBERT HESS: And then the business logic is actually using those ports and services doesn't have to change at all; because you've done the decoration there, it just is, everything's flowing in the exact same fashion as before.

STEVE SWARTZ: Right, so this is the Enterprise Services strategy to adding these kinds of behaviors. Enterprise Services had a model where there's a set of things that your app actually cares about which is the business logic, what it actually does when the place order comes in. There's a whole bunch of other things that you need to build in order to have a robust application, things like reliable messaging and a security system, a transaction system, instance pooling and the like. Those things are all implemented in Indigo as these attributes so the developer doesn't have to think too much about how those are built; they can just use the attributes to get those features. Now let's answer your question about how I go about using this from the client side. Again the client is a pretty straightforward thing. Now on the server side, the initiated, I actually have to have an implementation of that service so that I can process orders when they arrive. On this side when I'm initiating, all I need is the interface, because I'm going to take that interface and make method calls and a message is going to go and cause the work to be done on the other side. So what happens is that we have a tool very much like the WSDL tool in ASP.NET. It's called WSDL.gen and what it does is look at the contract information, the policy and the WSDL on the server, and generate an interface corresponding to that service. That's not the only way you can get over; we'll show you later that in fact you can use all manner of different interfaces on the client. You can carry this interface with you from the server if you're in a place where you're deploying the server and the client at the same time. But the important thing is that you just have an interface on this side that represents the methods that are on that place, so here's the Place method. It's again a service method. But what I'm using here is an interface called IOrderProcessor that I can use to send messages to the service and get responses back.
[ServiceInterface]
public class IOrderProcessor
{
	[ServiceMethod]
	public void Place (string CustomerName, string ProductName, int Quantity);
	{
		// Process Order
	}
}


Jump to #68Now what happens is is that you can also, in addition to understanding interfaces like this that just have the methods that can be run on the other side, I can also build an interface called, in this case, IOrderProcessorChannel, that implements the application methods on IOrderProcessor and also the infrastructure methods on IChannel. IChannel is an interface that you use to talk to channels. On the server side we had services and ports, which are two of the big actors in Indigo. Here now we see channel, which is the third.
public interface IOrderProcessorChannel : IOrderProcessor, IChannel
{
}
And the nice convenient thing about that is when I'm using a channel, I want to call my own application methods to say place this order, but I also need to close that channel down when I'm done, so the resources used in the operating system for that transport mechanism can be released. So I can merge those two interfaces into one so long as I have the right methods on IOrderProcessor; in fact I could use any interface and it's convenient to use this one because I avoid casting. So here's my application on the initiating side, the client side, and I have a Main, and here I am going and creating a new port. I'm just creating the default port, so there's a configuration, it's going to tell me what address that port's at. I don't really care in this case, because I'm not accepting messages. This is running on my machine at home that I don't want anyone to send a message to initiate work, I'm talking to somebody else. Then I go ahead and create an IOrderProcessorChannel. That's an interface that I just showed you up above that has methods on it that I can use to talk to the service and methods that I can use to deal with the channel directly. And I walk up to the port and say CreateChannel. I describe the channel to the port using this generic. Indigo runs on Whidbey, so I can use generics here, and so I have a CreateChannel that's specific to that interface and I pass it the address, remember myServer/OrderProcessor, that that service is living at. So I create a port, I go ahead and create the channel, then I just call methods, and you see those method calls look just like they would in any other CLR context. When I'm done with the service I close it. So create the port, create the channel, use the channel, close the channel.
public class Buyer
{
	public static void Main(string[] args)
	{
		Port port = new Port();
		IOrderProcessorChannel service =
			port.CreateChannel("http://myServer/OrderProcessor");
		service.Place("Ryan", "Laptop", 1);
		service.Close();
	}
}


Jump to #69 ROBERT HESS: And then when you're actually using the channel there, what that actually is doing behind the scenes is wrapping up those things into potentially an XML message packet, calling standard Web Services, sending that packet across the wire, calling the interface on the other side, and if any sort of a response comes back and dealing with the response that comes back from that side.

STEVE SWARTZ: Absolutely. In the simplest case, where I have no security or transactions or reliability going on, this method call is turned into a standard XML SOAP body and put in there, and we have all sort of ways you can control whether you're doing DOC or RPC, all the things that different systems use, we need that for interop. But I'm just taking the call there and turning it into an XML body, sticking it in a SOAP message. The headers that are placed in there are just typical headers the system always uses, and off the message goes. If I had transactions or security on the other side, those things would show up in the metadata as policy saying oh, I've got to have a transaction flowed to me or oh, you better give me an identity of this sort, because I need security. And so what happens there is those attributes would show up on this interface too, the system would generate them for you, and those attributes would cause the system to add headers according to the standards that do those features. So if I have a transaction attribute on the method, before I made a call that transaction attribute would cause code to run that would put the header onto the message. So it's all about messages at the bottom, but as you see, you mostly don't care about that. You have the high level concepts of port, channel and service, and then all the other features are just declarative attributes that translate into these complex XML things. As a programming model guy, I'm happy that I don't ever have to see those angle brackets, I just like writing code.

Jump to #70So let's go to the next example, which is a bit more complicated, and it'll show a few other things. The first thing this shows is that when I'm using simple structures like ints or hash tables that are CLR types, the system knows how to turn those into XML on the wire automatically. But if I'm building my own type, I need it instructed as to how it translates my type from the CLR form into the wire form, into the XML. So coming along with Indigo is an innovation in our serialization mechanism, and as you see here there's a DataContract that I put on that class in order to use it. So the class itself has a DataContract attribute. Every member I'm using that I want to show up on the wire and on the other side has a DataMember.
[DataContract]
public class OrderInfo
{
	[DataMember]
	public string CustomerName;

	[DataMember]
	public string ProductName;

	[DataMember]
	public int Quantity;
}
Now it turns out that the only thing Indigo cares about as these types move from one side of the wire to another is that the DataContract matches. On the other side I could use a type that contained these three properties plus all sort of other things. The system wouldn't mind so long as it could take on the one side the class and turn it into a wire representation, and then on the other side turn it back into a class. The thing that has to match is the DataContract. So if we want we can do the CLR thing that .NET remoting did, where on two sides of a call we shared the same type. Alternatively we can do what ASP.NET did, it will always create types for you so as the two sides of your communication are decoupled and can be versioned. These are all options in the system rather than baking in the choices.

Jump to #71 ROBERT HESS: So either one will happen.

STEVE SWARTZ: You can pick. When you run WSDL.gen and set up your service, you can either tell it to run in a very decoupled way, in which case we'll do the ASP.NET tricks of hiding you from the faraway types, or if you like you can do the .NET remoting thing where you're using the exact same types on both sides. It's just a matter of how coupled you already are, whether it's convenient to share types or whether it's costly.

Jump to #72So now on the server side I've gone ahead and declared my interface explicitly. Remember in the first example I just had a service and I figured out what the interface was. Well here I'm saying this is an interface that is being used as a contract between the two sides. This is a thing called IOrderStatus. And the interesting thing that's different about this service method call from the last one is this attribute is instructing this to be OneWay. So see I have a OneWay = true property. A normal service method is an RPC method where it's a request/response pattern. When I use OneWay = true those methods are Fire and Forget.
[ServiceInterface]
public interface IOrderStatus
{
	[ServiceMethod(OneWay = true)]
	void Accepted();

	[ServiceMethod(OneWay = true)]
	void Rejected();
}
On the client side the method is call, the message takes off and we're done. The service later gets the message, it might take seconds if it's on a near wire; if there's a queue there it could take days. It processes the message perhaps long after the client is gone. So it's true asynchronous, not the request/response asynchronous of the CLR but true OneWay methods. So as you see here I actually have two of these interfaces, because the interesting thing about asynchronous programming is that if I'm doing true Fire and Forget it's real rare that I want to send you a bunch of information and never want anything back. So what this does is set up a service interface here called IOrderProcessor, and it takes the incoming place requests that we've seen before, but it's a OneWay request. And so what it does is it says when I want to talk back to you I'll talk on this IOrderStatus. So my DuplexContract, meaning my return contract, is IOrderStatus. The IncomingContract is IOrderProcessor. So see here this is very different than you can do on our existing products. Our existing products are all RPC-based, where here it's very easy to set up things where I can send you three messages, you send me two messages; we're in a very peer to peer situation. I still had to initiate you, but once we started talking the messaging pattern is much more flexible, because we're doing true messaging.
[ServiceInterface]
public interface IOrderProcessor : IDuplexContract
{
	[ServiceMethod(OneWay = true)]
	void Place(OrderInfo order);
}


Jump to #73 ROBERT HESS: Mm hm.

STEVE SWARTZ: So what we've done here by using OneWay = true is we've moved from an RPC mode to a messaging mode. This is an example of what I was talking to you about, the fact that I can just add an attribute with the property to switch from RPC to messaging is one of our goals. We don't want to have to move to a different programming model or a whole different strategy to get these features. Just simple changes in the attribute. So now we've implemented a slightly more complicated interface. The first Place that we had was just a simple request/response. In this place I send you a message to place the order, you send me back either an Accepted or a Rejected method. So what happens here, my service is a little more complex. The way I use these things is I have a Callback property that I implement, which is part of IDuplexContract, and when I start the service running I will poke the Callback interface in for each call that is sufficient for me to be able to send a message back. So when I start up as the listener, the guy who's accepting things, a message arrives, I get called like normal on the method that corresponds to that, my Place method, but I can go grab the Callback property, turn around and call a method on it to talk back to the person talking to me. There's no need for me to make a connection back to the person who woke me up. I get that connection automatically. There's one two-way communication pattern with arbitrary messaging patterns going on as defined by this contract.

Jump to #74 ROBERT HESS: And that's coming embedded within the packet that you get originally.

STEVE SWARTZ: Exactly. That packet comes along and it tells the infrastructure how to get back in touch. And the underlying Indigo transport is tricky enough to say oh, if you're using http I know how to slide messages back to you; if you're using TCP it's easy to send messages both ways. It does the right thing based on the transport being used. So that Callback property is available to my infrastructure to make messages calls back to the person who initiated me. Think of how I'd have to do that in .NET remoting. I'd have to pass an interface to you that you would call back to me. So it's much more of a clunky mechanism; this is very straightforward. So what happens is in my Place structure this Place call, as I said, could be sent on a queue or any sort of mechanism; the client could be long gone. What happens is that I go ahead and do my processing just as I did before, but now instead of just doing a request/response I actually send a message back on that Callback to tell them I've either accepted their order or rejected it. And of course the hosting is the same; it's all a very simple hosting model where I'm still running my order processor.
[Service]
public class OrderProcessor : IOrderProcessor
{
	private IOrderStatus _Callback;
	public IOrderStatus Callback
	{
		get { return _Callback; }
		set { _Callback = Callback; }
	}

	public void Place(OrderInfo order)
	{
		bool OrderStatus = true;

		//Process order

		if (OrderStatus)
		{
			_Callback.Accepted();
		}
		else
		{
			_Callback.Rejected();
		}
	}
}


Jump to #75 ROBERT HESS: Mm hm. It has the same code we saw before.

STEVE SWARTZ: Yes, exactly. And again this could also be done in ASP.NET if I wanted automatic hosting. So now what happens here on the client side is is that I still have the same information, again what would happen is the WSDL.gen tool would build you, instead of building a class as it does in ASP.NET it would build you the DataContracts and the DataDefinitions that were necessary to talk to the service. And the ServiceInterfaces that were necessary. So the code at the beginning of this, here is the definition of that data object that's part of my contract, with the three DataMembers just as before. Here's the code that's associated with the interface that's being used to send messages back to me. And here again I have two OneWay messages, Accepted and Rejected, and now I'm going to get those. And finally here is the code for the interface that is used by me to send messages to someone else. So now what I do is I create the OrderProcessor, or just like before the OrderProcessorChannel interface. But instead of having a request/response implementation in place as I did before, I now have a OneWay Place and a Callback interface that I can use to send the messages back. So now what I have to do on the client is I have to implement Accepted and Rejected. So I have to give the system an implementation of that interface so that when messages come back I can catch them and process them.

Jump to #76So my Buyer object's a little more complicated, too. In the Main of my Buyer object I go to the port and I create a service just like before, but now I have to give it a new version of me that has the code that will handle these messages that are coming back. So I go to the Callback property and assign a new Buyer service. After that I use the service just like before, I fill up this laptop object and make the call. The difference being that now my instance that I've created here needs to stick around and wait so that it can catch the messages. So what happens is that when Accept or Reject is called, the method is called here and I go ahead and close the service and I'm finished. So what happens here is that I go and create the interface just like I did in the RPC mode, but I have to also create an instance that will be around to catch the messages coming back and then I'm processing the return. This isn't that interesting an example in that I'm doing nothing more than I could do with request/response, but if you start thinking about more complicated messaging patterns you can see the power of this.
public static void Main(string[] args)
{
	Port port = new Port();
	IOrderProcessorChannel service =
		port.CreateChannel("http://myServer/OrderProcessor");
	service.Callback = (IOrderStatus) new Buyer(service);

	OrderInfo laptop = new OrderInfo();
	laptop.CustomerName = "Ryan";
	laptop.ProductName = "Laptop";
	laptop.Quantity = 1;

	service.Place(laptop);
}

public void Accepted()
{
	// Process successful order
	_service.Close();
}

public void Rejected()
{
	// Process failed order
	_service.Close();
}


Jump to #77 ROBERT HESS: Mm hm. This is definitely something that I'm writing the code for something like this to do this Accept and Reject model. I've got to slightly rethink how I'm doing my application, but not tremendously.

STEVE SWARTZ: Absolutely. If you think about it, whenever you're building a distributed application you always have to think about the contract that is being used between you and I. So in older technologies I might have to think about the DCOM interfaces that I was using when I was coding in Ole, the type libs and the ITL. In this world I'm specifying the contract by adding these attributes to the code. I have a tool that can turn this code into WSDL. WSDL is the real contract language. The nice thing is that I have to think that through but it's more explicit. So any time you're building a distributed app you have to think about the contract first. The only way in which this is more complex than the existing models is that there's richer contract support. In ASP.NET I have request/response; here I can have any messaging pattern, and it's a matter of if I dive into wanting more complex messaging patterns I better think through what that means.

Jump to #78It's kind of like being a VB coder where you're getting a lot of events and random orders from the system. And you need to be able to think about what happens if one event comes and the other event comes, so you typically do this message processing by having a small piece of code that's kind of independent from all the other code handle particular messages. It can become a very complicated thing if you don't think clearly about the state machine involved, the order in which you expect things. And again it's important to remember that if I wanted to make this application secure or transacted or reliable, I'd use the same attributes that I used in the RPC example. I'd put them on the methods that declared the interface on the server, and those would flow with my WSDL.gen tool across to the client. And without doing anything other than adding those attributes, I would add all these behaviors -- secure, reliable, transacted messaging -- just in that simple way.

Jump to #79 ROBERT HESS: Now what happens if, let's say you design your interfaces on one end and someone is consuming those interfaces, and then you decide I want to change my interfaces to make them secure and transacted reliable stuff like that, is it required that the other guy recompile or regenerate his instance on his end as well?

STEVE SWARTZ: Well the answer to this question is maybe. And so we need to think about what we're talking about. In a case where I can make a change to a behavior locally that you don't have to know about, for instance I want to start using a different transport as an option, the system negotiates transport use down below where the actual code is not aware of it. As a result I can add that kind of behavior to the system on the server side without causing the client to change at all, but there are other sorts of behaviors that are added with attributes that actually define a kind of coupling between you and I. So for instance if I need you to flow a transaction to me, you have to know that you're creating a transaction and that all your other errors that are in that transaction's domain need to be coordinated with my transaction. So you needed to know that when you wrote your application. So you can't just walk up and add transactions to a system without thinking about it. That's something you need to know at development time.

Jump to #80That's why the answer to your question was yes or no. There are some features of Indigo that don't involve additional coupling; they just involve using the data that's in the contract in a different way. But there are other features of Indigo like the signature of a method, whereas if I added something to the signature of a method you would need to know that so you could send me a valid message. And things like security are in the first camp. As long as you're sending me an identity you don't care what I'm doing with it and so I could add impersonation on my side. If you're already sending me an identity, we're fine. But things like transaction are in the second camp, because if you're dealing with a transacted system you need to plan for that in your development.

Jump to #81 ROBERT HESS: Because it's a different process you need to know how to unroll the transactions and stuff like that.

STEVE SWARTZ: Exactly. So we can look at this third example. It's an example that's going to show some of the different kind of signatures we can use. So far we've been looking at pretty simple signatures where the types of the things we're passing are pretty much the same as CLR types. And so this example gets a little crazier in that direction. So here in the class that I'm building this time I'm implementing a little router. So the class that I'm implementing is a Route class, and what I've done is I've made this an XML serializable thing using the serializer from the ASP.NET product. The reason I would choose to use this serializer instead of the standard CLR serializer is the standard CLR serializer that we are implementing with DataContract is really aimed at getting things from one CLR to another or talking about types that are like that. If you're really type and programming model oriented that's the serializer you want to use. On the other hand, if you have to code to a particular contract that's pre-existing, some industry consortium has defined how you place an order for a shoe and there's a specific XML contract that's hard to represent, you can use the XML serializer to create data that will give the schema to our system for that particular method and it will serialize things from the object to the schema in the exact way. So if you're dealing with unusual contracts this is the system you'd use.
[XmlTypeAttribute(Namespace = "http://schemas.Routing.com")]
[XmlRootAttribute("Route", Namespace = "http://schemas.Routing.com")]
public class Route
{
	[XMLAttribute]
	publid string Name;

	[XMLAttribute]
	public string Action;
}

[CLSCompliant(false)]
[Service]
public class Router
{
	[ServiceMethod(Format = ServiceFormatter.XmlSerializer)]
	public void AddRoute(Route route)
	{
		//Add Route to Router Table
	}

	[ServiceMethod(OneWay = true, unmachedMessagehandler = true, Format = ServiceFormatter.Message)]
	public void AllOtherMessages(Message message)
	{
		//Route Messages
	}


Jump to #82So now I have a Router class, and this Router class is kind of interesting. The way I want my Router class to work is there's an AddRoute method that you can call in it, and of course when you call that I add one of these routes. So I take the route by name and then I have a rule that I use to decide where to send messages. But this system can take any other message you could consider sending, any method call in the world, it treats it like an Indigo message and goes ahead and routes it. So the first kind of method looks pretty much the same as it did in the earlier example. I have an XML serializer property on the ServiceMethod call that says that's the thing I'm using in my route. I'm using a different serializer because I have to think about translating this signature into a message differently. I have to be aware of the fact that it's doing its own serialization. So if this class gets a message called AddRoute it goes to this method and that route is added to my routing table.

Jump to #83The second method's a little more interesting; it's a OneWay method and look, it says UnmatchedMessageHandler. What that means is that any message that comes to this service that isn't AddRoute, in more general case, any message that comes that I don't know about beforehand will go to this method. So you can send this service anything you like and it'll go to this method. And if you see the third thing it says is that the message format is a message. And what this is saying is instead of taking this message as a CLR bunch of types, three ints and a string, I'm just going to get the raw Indigo message. So when this method is called down here the signature is just a simple call with one argument, which is a message, and that's the full bore Indigo message. It has an XML reader for a body and you can get at any of the data you like using XML programming tools. It has the SOAP message headers on it which contain information about security. So if I'm programming at that level I'm doing a lot of stuff myself. I have friends that love this kind of programming but it's very complicated. You write lots of code and you know it's sort of the extreme programming kind of thing. You would want to see this on MTV, people flying in the air with their crazy programs. But the nice thing about it is that I can set up this router so it doesn't care; any message sent to it will simply be sent on to somebody else who knows what to do with it.

Jump to #84And so the signature on the client can be very different than this, and that's part of this example. So if I go ahead and look at the client I'm going to use this router in a very different way than I've used the other things. In the first two examples my signature that I was using to use this is more or less the same as the signature that the service implemented, whereas here I have an application that still knows how to do routes, but in addition it has a few methods that are part of its own way of using the router. So I still have this Route class, which I could use something else that had the same DataContract but I've just copied it for this example. And now I'm building an interface that I'm going to talk, with and I know that on the router the port type is called IRouter and so I have to use that same port type here. But I'm going to use a completely different interface. My interface still implements the AddRoute method, because if I want to talk to this router one of the things I have to do is stick Routes in there. But then in addition I'm not going to have a handle all other messages method, I'm going to just have Greetings and Salutations. The Greeting method sends one greeting to somebody and the Salutation method sends many. So this signature is very very different. I'm more or less completely decoupled from the service I'm using.
[SeriviceInterface(ActionBaseUri = "IRouter")]
public interface ISendGreetings
{
	[ServiceMethod(Format = ServiceFormatter.XmlSerializer)]
	void AddRoute(Route route);

	[ServiceMethod(OneWay = true)]
	void Greeting(string greeting);

	[ServiceMethod(OneWay = true)]
	void Salutations(int count, string greeting);
But it turns out using this is the exact same thing as using any other Indigo interface. I go into the port, I create the channel, when I'm coding these routes -- I'm adding two routes here in this example -- that's the same kind of code that I would use in the normal case. But look, I can call with the Greeting or Salutation signature; the service knows nothing of that. But it is dealing with those as raw messages.
Port port = new Port();
ISendGreetingsChannel service =
	port.CreateChannel("http://myServer/SendGreetings");

Route route = new Route();
route.Name = "Greeting";
route.Action = "action*=Greeting,route=NewEngland";
channel.AddRoute(route);
			
route.Name = "Salute";
route.Action = "action*=Salutations,route=SouteEast";
service.AddRoute(route);


Jump to #85This trick could be used for processing unstructured data, so if I wanted to send a Word document to you I could send it on a SendWordDocument, the guy on the other side could greet it as an Indigo message and parse through it using normal XML tools. So this is an example of how decoupled the client and the server can be in an Indigo application. We're not in a situation like we are in ASP.NET where the WSDL tool creates a proxy that exactly matches the WSDL that was published. Or in .NET remoting where I literally have to have the same type on the two sides to use it. If I choose I can still share types here as I said, but I can have signatures that don't even match on the two sides so long as I've thought through the underlying contract and made sure there's code on the service that can handle my requests that are generated here on the program. Now here's an example of the difference between the CLR's notion of asynchronous and Indigo's notion of asynchronous. So I've got up here some of the stuff that I need to use the CLR. I have one of these asynch result classes. I don't think that's too interesting; you've seen it before. But I have a Service class and the Service class has three methods. This first method is a request/response standard method called ServiceMethod and it's going to process an order by name and return 42.
[Service]    
public class OrderProcessor
{
	[ServiceMethod]
	public void PlaceOrderByName(string CustomerName, string ProductName, int Quantity)
	{            
		// Process order
		return 42;
	}
It always answers every question with 42. Now the second method is set up with the asynch pattern, and so I've got two methods here, BeginPlaceOrderByNumber and EndPlaceOrderByNumber, and what happens is that because I'm using the asynch pattern this is going to look in the contract and to the client as though it was a synchronous call, a request/response call, but on the server I can process it asynchronously.
[ServiceMethod(AsyncPattern = true)]
public IAsyncResult BeginPlaceOrderByNumber(string CustomerName, 
	int ProductNumber, 
	int Quantity,
	AsyncCallback callback,
	object state)
{
	OrderAsyncResult orderResult = new OrderAsyncResult(...);

	return orderResult;
}

[ServiceMethod]
public void EndPlaceOrderByNumber(IAsyncResult result)
{
	OrderAsyncResult asyncResult = (OrderAsyncResult)result;
	asyncResult.AsyncWaitHandle.WaitOne();
}
I can return the thread that it's called on, put the process in a queue, work on it for awhile and later wake up and call back to the caller with the response. Meanwhile the poor guy who called is sitting there waiting during all this queuing process, but the point is that I've implemented myself asynchronously, but I present to the world as a synchronous method.

Jump to #86And that's different than the third method on this contract, which is like we showed before, a service method that is OneWay.
[ServiceMethod(OneWay = true)]
public void EmailStatus(string CustomerName, string EmailAddress)
{
	// Queue request to email the customer their status at some point
}
And so in this example what we're seeing is that if I want you to email me something, I can send you a message called email me my status, you might process that tomorrow, that's okay, it's an Amazon thing. I don't need the thing right away. I return immediately, you put that request in a queue, there's never going to be a time when you're going to give a response to me. You're just sending me email. So the difference between this kind of asynchronousness and the CLR asynch pattern is the CLR pattern allows the server to use another thread to do the work, but the client is sitting there hanging, whereas in the Indigo asynch it's Fire and Forget. And so I can send you a message, forget about it, you can do the work later, and you need some out of band mechanism to respond to me. Both of these implementation strategies can be used depending on your circumstances. So this service looks like two request/response and one OneWay call on the outside, but on the inside two of the three methods are being implemented asynchronously.

Jump to #87And again on the client it's the opposite pattern. Just to be cute here what I did was remember how there was a purely request/response method? Well the client can choose to use the client side asynchronous model on any of these request/response. So for instance I can have on the server side two request/response methods, the client finds that the one that's hanging is taking forever, it can use the client side asynch, too. So we can still use request/response to correlate requests with answers. I can ask you a question, go about my business, later check on the response and get that message back and know it matched the request I made, or I can use pure asynchronous messaging and figure that out myself. But the use here of the asynch pattern on the client side works the same way as it does on the server. I set it up on the interface. See here PlaceOrderByName can be used either synchronously or using the asynch pattern.
[ServiceMethod]
int PlaceOrderByName(string CustomerName,
	string ProductName,
	int Quantity);
		
[ServiceMethod(AsyncPattern = true)]
IAsyncResult BeginPlaceOrderByName(string CustomerName, 
	string ProductName, 
	int Quantity,
	AsyncCallback callback,
	object asyncState) ;
But down here, because that's the way I've set it up, the thing which is implemented as a server side asynch is a client side synchronous.
[ServiceMethod]
int PlaceOrderByNumber(string CustomerName,
	int ProductNumber,
	int Quantity);
So there's no correlation here between how the client decides to use the synchronous pattern and how the server uses it. So when you're programming Indigo you have all the standard patterns for asynchronous behavior that are available in the current CLR plus the pure messaging model that you only get in system.messaging.

Jump to #88 ROBERT HESS: So one of the benefits of this is that if I'm the client code or the client programmer and I'm wanting to interact with some service being written like this, I'm not having to set my business logic to rely upon how they set up their service. I can actually look at what their service is offering and determine myself what the right way for my own business logic is rather than thinking oh, this guy knows what's best for me; no, I know what's best for me, I'm going to do it my way.

STEVE SWARTZ: Absolutely. And the other interesting thing that's different here in pretty much all the programming models in the world is if I'm a Java programmer the request/response model is kind of different than the messaging model. If I'm a CLR programmer, system.messaging is kind of different than ASP.NET. But in Indigo you get both the messaging and the RPC programming model in the same package. There's nothing different you need to learn except a very small number of things. If you don't want to ever do messaging because it's too complicated, it makes your head hurt, you don't even have to go there. Purely a choice.

Jump to #89 ROBERT HESS: Mm hm. Now I suppose from a programming aspect we're no longer looking at the standard specifications. I mean nothing in here did I really see anything that spoke about the standards and specifications, even the notion I'm talking to a system other than my own type of client system. I don't know that I'm not talking to a Unix system. As far as I know he's another system exactly like me, running on Indigo and I'm talking to him calling the same functions on. Now for a programmer, that sounds like that's going to be extremely powerful for what they can do. However how does that match up to what a programmer's experience is going to be like on those other systems?

STEVE SWARTZ: One of the interesting things about this strategy versus say a standard strategy that was API focused is by standardizing on wire formats what we're saying is that we know that programming models are going to evolve in the future, and in fact we like -- here in the developer division we love -- competing with people to make the best programming models in the world. But we don't want customers to be necessarily locked into our programming environment because they've made a decision in the past to use our programming environment on that other one; we want every day to regain their desire to use our tools because they're simply the best. So if I'm talking to you and you're an IBM system and I'm a Microsoft system, you can write your side or your application in IBM, I can write my side in Microsoft. So long as we're using all these standards, my code will look however it looks in the CLR programming model Indigo and your code will look the way it does in whatever programming model you're using in the IBM world. Your code could be completely different. Your code could be a different language, right, we talked about that earlier. So there's no guarantee that the programming models look the same on both sides. That's actually good because you can later make a decision looking over my shoulder, hey, he's got a good thing in that .NET; I'm going to build my next app in .NET. It will still talk to all of your old IBM apps, they'll still talk to the Microsoft apps. So it's actually a very good thing that there's not a constraint here that all of our programs have to look the same. I've been coding for a long time and I can recall standard efforts for Fortran 77 and C and C++.

Jump to #90 ROBERT HESS: Ada.

STEVE SWARTZ: And it never works. Because we never get to the place where we have the last programming model. There's always room for improvement and competition. And so the goal here is to say, we'll evolve over time, we'll come up with different programming models that do different things. So long as we stick to the standards, we'll all talk to each other. So that's part of the excellent thing about Indigo.

Jump to #91 ROBERT HESS: So we're building that capability of evolution into Indigo.

STEVE SWARTZ: Right. And the other key thing to think about is I showed you relatively simple examples to show the ways that you don't have to learn all those horrible angle brackets in order to do WS security and WS transactions and the like. But you might be the kind of guy who loves that sort of thing. It turns out that the programming model supports the ability to add your own headers. You can actually write these attributes that we're showing you yourself. You could write an attribute that would put your own private standard on the wire, and as long as that same standard was being used on IBM and they had an extensibility mechanism that allowed you to easily do it on that side, you could add your own transaction standard and implement it in our programming model the exact same way we did.

Jump to #92 ROBERT HESS: So if I knew that there was a new specification coming out and I knew that the IBM systems had built that into their systems and they were supporting that and we hadn't yet in Indigo...

STEVE SWARTZ: That's very implausible, by the way.

ROBERT HESS: Implausible, but just imagining, the twilight zone, I could actually take and write support for that emerging standard into Indigo without having Indigo Team have to rev it up and me download a new version or something like that.

STEVE SWARTZ: Absolutely. Or you could imagine specific industries building standards of their own that involve things that were not general enough that they would ever make it into any of our platforms.

Jump to #93 ROBERT HESS: Like private standards.

STEVE SWARTZ: Exactly. Standards within the shoe industry or the banking industry where we're exchanging special kinds of security information that normal apps wouldn't build. Another use for this is that I'm a big shop and I'm trying to make the programmers in my shop use these attributes in standard ways. I can write an attribute that says, this is Steve's company, and I write that above the top and it causes the behavior of all the rest of the program to be hard-wired so that users aren't using the security attribute and the transaction attribute. I have a friend named Pat Helen who believes in fiefdoms, I want to write a Pat Helen attribute that does exactly what a fiefdom should do in Indigo.

ROBERT HESS: Fiefdoms and emissaries.

STEVE SWARTZ: Exactly.

Jump to #94 ROBERT HESS: So in looking at this code I'm not seeing an awful lot different in it than what standard .NET programming is going to be like, just some new attributes sitting on top of it. Now as someone that's in charge of basically designing this new programming model sort of thing for Indigo, it's almost like you're not really putting your footprint onto the programming model at all. You're not even visible. I mean, in a sense of pride, wouldn't you want to take and actually make a change so the programmer has to think about you when they're writing the code?

STEVE SWARTZ: No, no, no. There have been a lot of changes in the last few years as we've moved from native code to managed code, and so now the beauty of the managed environment is that I don't have to change the way a programmer thinks except in the fact that they want to use my new features. But they should be able to use managed code just the way they did. I don't want them to have to take a new class and so on. And in fact I think we're doing a great service because we're taking a variety of programming models and bringing them to one. So in the future they'll have to learn less than they did now, and the less they notice all the work I've done the better I'm doing.

Jump to #95 ROBERT HESS: Now I know that most of what you showed me today actually isn't functional on anything that the users and the audience out there is actually going to have. What do you recommend for their path getting prepared for when Indigo is capable of being programmed against?

STEVE SWARTZ: At PDC one of the talks we gave was given by Joe Long, who is a Manager in the Indigo Team. He spoke at great length about the prescriptive guidance that we give to customers using the existing products today. And there's two halves of that guidance. One half is forget about Indigo; how do we recommend that you use ASP.NET, .NET remoting, Enterprise Services, System.messaging, each in their place so that a) you're getting the most out of each of those products, and then b) you'll be ready for Indigo. And so we actually have that talk available on MSDN and you can download it and watch it. That talk will tell you how to think about programming with the existing models in a service-oriented way which reaps immediate benefits and provides you with a clean migration pack. The simple story is if you avoid the extensibility mechanisms and just write business logic, you're going to be very fine when you migrate. And to the extent you're using the extensibility mechanisms, you're going to want to make sure that you've written your code so as that you can pull it out and stick it into ours, because while we intend to be very much like the existing products when you're actually writing code, the infrastructure of Indigo is very different. It's message based rather than RPC based, and so the extensibility mechanisms are just different.

Jump to #96 ROBERT HESS: Now are we going to be tied directly to Longhorn so the first time we'll be able to actually do this sort of code is in a Longhorn programming environment?

STEVE SWARTZ: I've been working at Microsoft long enough to not trust anybody who comes and forecasts dates and ship vehicles too far ahead. Our team is on our own schedule. Indigo is being built; we're not hooked to the Longhorn schedule or the Whidbey schedule or any other schedule. And I think the way I think of our schedule is we're on the big fish schedule. As John said, I think we're going to be done with our coding and gone through our initial hardening by summer's end, and there'll be a beta of Indigo at that time. And as we get to the place where we're ready to ship, rather than being linked to somebody, we'll start watching for the next big fish and we'll be stuck onto the side as they go out the door. And so if that big fish is Whidbey or a feature pack on an OS or Longhorn, so be it. Certainly we'll be in Longhorn, but we might ship ahead of time. I just have no way of knowing that because all of these schedules are so variable. So I enjoy not having an opinion on that. You can talk to our marketing guys.

Jump to #97 ROBERT HESS: I'd rather not. If someone is interested in more information about Indigo and the programming model and the attributes and stuff like that, where do you recommend they go?

STEVE SWARTZ: Well, now I'm not going to be able to memorize these things, but there's a whole set of Indigo newsgroups that are up and running and people can go. You can get the PDC bits through MSDN and any time you get a refreshed version of Longhorn you'll have the latest Indigo bits as part of that. We're working with a lot of people to start writing books. There's talks going on right now in Europe. There's a set of people going around giving the greatest hits of PDC and there's talks being given there about Indigo. There are a lot of people blogging about Indigo, you can go to the bloggers of the Indigo Team, including myself, and read about it. A variety of things. I imagine there will be more and more information as the product starts stabilizing. We're in the last milestone; we do our milestones in parts, so we're starting coding of part 2 of 4 Monday, and I'm thinking that we'll be doing coding for the last version of V1 by May or June.

ROBERT HESS: Mm hm. Okay, I'll take and I'll make sure in the transcript I stick some of the links to some of the blogs and other information they can get to. Any other information you think they might want to have, just go ahead and send those to me in email and I can add those to the transcript quite easily, because I don't memorize those links myself either.

STEVE SWARTZ: Great.

Jump to #98 ROBERT HESS: Well is there any final words of wisdom you want to take and impart upon our audience?

STEVE SWARTZ: I think it's going to be worth your while to look at our prescriptive guidance talk that I told you about, because it's important to think about Indigo not as a big change or something new and completely different, but rather as a replacement of infrastructure which you only have to look at if you're the kind of person who likes it, but an evolution of the programming model, a simplification and a unification. We think we're going to be in a place where there's this one distributed programming model that can work at very close range, in the ways we used to use DCOM inside of Word, or at an incredible distance. And so it's very exciting to think about being able to simplify all that and move forward, and it's interesting to think about using the products now with good architectural principles which by definition will make them well-suited for the future.

ROBERT HESS: Well thank you very much, Steve.

STEVE SWARTZ: Thank you.

Jump to #99 ROBERT HESS: Thank you. Well there hopefully you saw some of the insights of what the programming model is going to look like for Indigo and how you can take and benefit by adding this to your applications in a relatively straightforward and simple fashion as soon as Longhorn or the appropriate programming models can become available in the operating systems. Well thanks for joining me, Steve, I appreciate the time you spent with us talking about the programming model for Indigo.

STEVE SWARTZ: Thanks for having me.

Jump to #100 ROBERT HESS: Well now hopefully that provides you with insight you need to understanding the programming model for Indigo and how it can affect your programming. If you're using the .NET Framework and managed code today you're already most of the way there. Now in future episodes we'll cover additional technologies out of Longhorn, and stay tuned, we'll catch you later.

Jump to #101 Somebody @ Microsoft.com
Erica Wiechers, Program Manager, Microsoft Corporation interviews Kevin Gjerstad, Lead Program Manager

ERICA WIECHERS: In keeping with the Longhorn theme, today with me is Kevin Gjerstad, he is a Lead Program Manager with the Avalon Group. Kevin, welcome.

KEVIN GJERSTAD: Thank you. Thank you very much.

Jump to #102 ERICA WIECHERS: So why don't you start by telling us what the Avalon Team in general works on and what you do in that position.

KEVIN GJERSTAD: Okay. Avalon is one of the four what we call pillars of the Longhorn project. Avalon is responsible for the new presentation subsystem, there are other things like WIN FS for data storage, Indigo for communication and Fundamentals for app model and security and that kind of thing. And so Avalon is our effort to rebuild the presentation sub-system from the ground up.

ERICA WIECHERS: Okay. And so what do you do as Lead PM?

KEVIN GJERSTAD: So I manage a team of six PMs responsible for the UI framework in Avalon. So things like component model, editing, input, layout, that kind of thing. And as well I manage a team of designers and developers working on demos and prototypes.

Jump to #103 ERICA WIECHERS: Okay, so they're basically building the whole new UI presentation layer for Longhorn.

KEVIN GJERSTAD: Yes.

ERICA WIECHERS: So now is your team responsible for designing the UI? Do you take ideas from customer feedback or usability tests or how does that work?

KEVIN GJERSTAD: My team actually doesn't design the UI per se. That work is mainly done by the Shell Team. We're actually the presentation framework, the things that you build a UI out of.

Jump to #104 ERICA WIECHERS: Okay, so you're building functionalities or features for developers who are building...

KEVIN GJERSTAD: And components and UI libraries and that sort of thing.

Jump to #105 ERICA WIECHERS: Okay. Can you talk about some of the current things you're working on?

KEVIN GJERSTAD: Well, actually right now we're just closing down an internal development milestone, so we're doing a lot of stability work and bug fixing and that sort of thing, as well as planning spec reviews and so forth for the next internal development milestone.

Jump to #106 ERICA WIECHERS: So what can you say -- what do you think is the coolest thing about Avalon?

KEVIN GJERSTAD: Well I think it's cool because we're actually getting a chance to rewrite from the ground up as opposed to doing incremental changes. So it's something that we've been wanting to do for a long time, so we're able to incorporate some features and technologies that take advantage of the great PC hardware that's out there today as one example.

Jump to #107 ERICA WIECHERS: And so where were you before the Avalon Team at Microsoft? Were you anywhere else?

KEVIN GJERSTAD: Well I've actually been -- before Microsoft?

ERICA WIECHERS: Or within Microsoft.

KEVIN GJERSTAD: Okay, so I started at Microsoft in 1994 with the Windows 95 team, where I worked on the international versions, primarily the Japanese version of Windows, and then I went on to work on Internet Explorer 3, 4 and 5, and then I was a Lead Program Manager on New Input Framework, which shipped in XP, that the Tablet and Speech Teams use.

Jump to #108 ERICA WIECHERS: So ten years, you've seen quite the progression.

KEVIN GJERSTAD: Oh yeah. A lot of changes.

ERICA WIECHERS: A lot of products.

KEVIN GJERSTAD: Mm hm.

Jump to #109 ERICA WIECHERS: That's great. Now did you come into high tech straight from school, or did you work anywhere else before Microsoft?

KEVIN GJERSTAD: No, actually right after college I went straight to Japan, where I spent two years studying and working there. And actually spent a lot of time learning the language and I originally only intended to go there for a year and then get kind of caught up in the thing and stayed for two years. And then after that actually I went to Russia, where I spent two years there working and teaching at an institute in the far east.

ERICA WIECHERS: Wow.

KEVIN GJERSTAD: Right as Russia was opening, so...

Jump to #110 ERICA WIECHERS: So do you still speak Japanese and Russian?

KEVIN GJERSTAD: Yeah, I do. My Japanese has gotten quite rusty in the last few years, but my Russian, I've actually tried to maintain that.

ERICA WIECHERS: That's great. So it helped you with your international jobs at Microsoft.

KEVIN GJERSTAD: Oh yeah, yeah.

ERICA WIECHERS: That's great. That's fascinating. Do you get the chance to travel at all with this current job?

KEVIN GJERSTAD: Not so much. I've been to Japan a few times on business, but that's about it so far.

Jump to #111 ERICA WIECHERS: So what kind of things do you like to do outside of work?

KEVIN GJERSTAD: Right now I spend a lot of time with my two-year-old son; he keeps me pretty busy. Outside of that I do a lot of mountain biking and skiing and jogging and that sort of thing.

ERICA WIECHERS: You're in the perfect space for that.

KEVIN GJERSTAD: Yeah, yeah.

Jump to #112 ERICA WIECHERS: Are you from the Northwest originally?

KEVIN GJERSTAD: I am. I've been here all my life except for that four years I spent abroad.

ERICA WIECHERS: Right. So you're one of the few natives, I think, in the company.

KEVIN GJERSTAD: Yeah. Becoming a more and more rare commodity here at Microsoft.

Jump to #113 ERICA WIECHERS: Have you had a chance to go out and do a lot of skiing this winter?

KEVIN GJERSTAD: Not so much. I've been kind of busy with this Longhorn thing this year.

ERICA WIECHERS: Yeah. There's a lot of good snow out there I hear.

KEVIN GJERSTAD: Yeah, I've got to get out there soon.

Jump to #114 ERICA WIECHERS: So where do you think you would like to go next in your career at Microsoft? Do you want to stay with the Longhorn Team as much as you can?

KEVIN GJERSTAD: You know, I haven't really given that a lot of thought. I tend to get really focused and passionate about what I'm doing at the moment, and this Longhorn thing has enough to keep me busy and focused that I haven't really thought beyond that. I'm sure that when we're done with this thing and ship it that I'll be on to that next thing, but I don't have any idea as to what that is right now.

ERICA WIECHERS: Right. You'll definitely be on this one for awhile.

KEVIN GJERSTAD: A little bit longer, yeah.

Jump to #115 ERICA WIECHERS: Well, Kevin, this is great, thanks for joining me.

KEVIN GJERSTAD: Thank you for having me.

KEVIN GJERSTAD: I lead a team of program managers responsible for the Avalon UI Framework including layout, component model, user interaction services and element/tree services. I also lead a small team of developers and designer developing prototype applications (like the legal app we showed during Bill Gates' PDC keynote) on the framework.

For the latest on Avalon in Longhorn:
PDC 2003 Avalon Overview:
http://msdn.microsoft.com/longhorn/pdcmaterials/pdctalksavalon/
Avalon Community Discussion:
http://msdn.microsoft.com/longhorn/community/newsgroups/default.aspx?dg=microsoft.public.windows.developer.winfx.avalon⟨=en&cr;=US
Longhorn Blogs:
http://www.longhornblogs.com/


Jump to #116 Closing Comments
ROBERT HESS: Well that brings us to the end of another episode of the .NET Show.

ERICA WIECHERS: And stay tuned for the next episode, which is on Win FS.

ROBERT HESS: And until then, we'll see you on the Web.

Links to Further Information
The Longhorn Developer Center: Indigo
http://msdn.microsoft.com/Longhorn/understanding/pillars/indigo/
"Indigo" is a set of .NET technologies for building and running connected systems. It is a new breed of communications infrastructure built around the Web services architecture. Advanced Web services support in Indigo provides secure, reliable, and transacted messaging along with interoperability. Indigo's service-oriented programming model is built on the Microsoft .NET Framework and simplifies development of connected systems. Indigo unifies a broad array of distributed systems capabilities in a composable and extensible architecture, spanning transports, security systems, messaging patterns, encodings, network topologies and hosting models. Indigo will be an integral capability of Windows "Longhorn" and will also be supported on Windows XP and Windows Server 2003.

Creating Indigo Applications with the PDC Release of Visual Studio .NET Whidbey
by Yasser Shohoud
http://msdn.microsoft.com/library/en-us/dnlingo/html/indigolingo01062004.asp
In the first installment of the Indigo Lingo column, Yasser Shohoud explores Visual Studio .NET project templates for creating Indigo applications

MSDN Magazine
A Guide to Developing and Running Connected Systems with Indigo
This article describes a collection of new programming frameworks that are part of "Longhorn," the upcoming version of Windows. "Indigo," the code name for this framework, provides rich support for service-oriented design that is complementary to traditional object-oriented approaches. Indigo marries the best features of .NET Remoting, ASMX, and .NET Enterprise Services into a unified programming and administration model. Indigo's deep support for standard protocols, including HTTP, XML, and SOAP, makes it easier to integrate applications and services without sacrificing security or reliability.

PDC Talks: Indigo
http://msdn.microsoft.com/longhorn/pdcmaterials/pdctalksindigo/
The Microsoft 2003 featured 6 technical tracks with more than 120 sessions. Find the PowerPoint slides for the WinFS-specific sessions you're interested in, along with streaming video and demo code from the sessions here.

Serviced, A blog by Steve Swartz
http://www.stevesw.com/blog/default.aspx

meta-douglasp, a blog by Doug Purdy
http://www.douglasp.com/default.aspx

Yasser Shohoud's blog
http://weblogs.asp.net/yassers/

Don Box's Spoutlet
http://www.gotdotnet.com/team/dbox/
Don Box is well known by many in developer world. He now works on the Indigo team helping define the architecture of this important technology for allowing systems to communicate deeply with each other.

IRhetoric - Karsten Januszewski's Web Log
http://blogs.msdn.com/karstenj/
Karsten is a Technical Evangelist on the Platform Strategy Team, and in his blog he covers a variety of interesting technology concepts that relate to Longhorn, often you will find him sharing various learnings regarding Indigo.