This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: Distributed .NET Computing: Longhorn Indigo on The .NET Show
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
Just in time before I write Part 3 of Distributed .NET Computing and the move to loosely-coupled SOA type architectures, there is a new episode of The .NET Show: Longhorn Indigo which is where this is all going so I will point you at that while I listen to it.
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.
Interestingly, the genesis of the name is revealed which is prety anti-climatic:
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.
I plan to post my thoughts on how this relates to the direction Distributed .NET computing is going but this is what I like: “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. “
Previous Topic
