Guest Opinion

Bixhorn Paints Indigo Picture

Ari Bixhorn discusses Microsoft's plan to create a unified programming model (code-named Indigo) for building distributed, interconnected apps in an interview with VSM Editor in Chief Patrick Meader.

• By Patrick Meader
• 03/01/2005

Ari Bixhorn, lead product manager of Web Services Strategy in the Developer and Platform Division at Microsoft, discusses Microsoft's plan to create a unified programming model (code-named Indigo) for building distributed, interconnected apps in an interview with VSM Editor in Chief Patrick Meader. Ari will help Eric Rudder, Microsoft senior vice president of Servers and Tools, present the Indigo keynote that anchors Indigo Day at VSLive! San Francisco on February 8.

PM: I've heard people from Microsoft describe Indigo as everything from a new paradigm for building service-oriented architecture (SOA) applications to a tool for implementing advanced messaging, with rich support for intermediaries and end-to-end security. On a basic level, what is Indigo?

AB: Indigo is a unified programming model that enables developers to build connected systems in a productive manner.

The world we live in today is more connected than ever before, and only getting more so. Five years ago, Microsoft made a big bet on connected systems with .NET and its emphasis on Web services. Web services provide us with a basic level of interoperability, but developers face a lot of connectivity challenges that aren't addressed by the current state of Web services.

For example, how do you implement these interoperable apps in a way that provides end-to-end security? How do you take into account the fact that some networks have high latency or might fail in some cases? How do you make them span organizational trust boundaries? These challenges all drove the design goals of Indigo.

PM: How does this tie back into service-oriented development?

AB: Indigo provides a unified programming model that enables developers to build service-oriented applications explicitly—loosely coupled, autonomous services that provide end-to-end security and reliable messaging assurances.

Developers have been asking us questions about which are the right programming model(s) to use for building interconnected systems for distributed applications. Today, there are a variety of programming models for building distributed apps—ASMX, Web Services Enhancements (WSE), .NET Enterprise Services, and so on—and people today have to ask themselves, which one of these do I need to use to create the functionality I want?

Our desire is to simplify this process with a unified programming model that enables developers to build connected systems in a productive manner.

PM: When you say a unified programming model, what do you mean by that?

AB: We take the functionalities that are provided in our existing distributed application programming models, and we expose them to the developer through a single namespace within the .NET Framework. Whereas today, developers have to use separate programming models provided by WSE, ASMX, System.Messaging, System.EnterpriseServices, and .NET Remoting, Indigo will bring the best aspects of these together. If you're a VB.NET or C# programmer, you simply reference the System.ServiceModel assembly, then import that into your code. This gives you access to all the functionality that exists in today's disparate technologies and more through a consistent, productive programming model.

PM: There is the perception that Microsoft is a Johnny-come-lately in the SOA world. Tell me about the breadth of Microsoft's commitment and some of its key products in this space.

AB: Web services are at the center of our SOA strategy. Product support for Web services today spans our entire platform, including clients, servers, services, and developer tools. As we move toward the Longhorn timeframe, this commitment will only expand and in many cases become an even deeper part of our products. Key products include BizTalk Server, Indigo, MapPoint, Microsoft Business Solutions (Microsoft CRM, Great Plains), Microsoft Office, SharePoint, SQL Server, Visual Studio, Web Services Enhancements (WSE), and Windows Server 2003.

PM: None of these different programming models are going away, as far as I know. How does Microsoft prevent Indigo from being perceived as just one more item on the technology stack?

AB: Looking ahead, we see Indigo as being the single way of building distributed applications for interconnected systems. We're already porting our existing technology stack to it, but moving forward, we'll be driving developers to use Indigo as the unified way of building these apps.

PM: Many developers seem skeptical/wary of Indigo. Why should they be excited by it? What do you see as the key advantages of creating SOA apps in the first place?

AB: Developers were already building GUI applications when Microsoft introduced version 1 of Visual Basic some 15 years ago. What VB did was make it significantly easier to create GUI applications, increasing developer productivity even as it decreased application complexity. The unified model of Indigo is intended to do the same for building distributed, interconnected apps. Indigo reduces the complexity of creating these apps. People are already providing these kinds of solutions, but they take a lot of work; Microsoft is providing a tool that will help them do this faster, more easily, and with greater productivity. Indigo reduces the amount of code developers have to write and the number of programming models that have to know to implement the functionality they need.

PM: You touched earlier on the technologies that Indigo replaces. What does Indigo do that these technologies don't?

AB: If you look across the technology stack for building distributed applications with Microsoft tools today, each technology provides a powerful way of building a distinct type of application. For example, WSE provides you with support for the WS-* protocols for interoperability. .NET Remoting has a great extensibility model, provides location transparency, and so on. But what many developers want is a way to have access to these different elements together within a single application or technology space. They want to combine the interoperability you get with ASMX or WSE with the transaction support you get with Enterprise Services. Today, there is an impedance mismatch across all these existing stacks that makes it difficult to combine all this functionality.

Our early adopters tell us one of Indigo's biggest benefits is the unified model to combine that functionality within a single application. You get all the benefits of interoperability, you get end-to-end Web services-based security, and you can still do things like reliable messaging.

PM: At the 2004 VSLive! Orlando keynote, Dave Mendlen mentioned that you had a 60,000-line app that had been reduced to a handful of lines by Indigo, but I don't recall hearing about this later. Do you have any more information on that? Do you have a reference to that online?

AB: The app he was referring to is one we built internally. We wanted to build the canonical Hello World Web service, but also add end-to-end security, end-to-end reliable messaging, and distributed transaction support to it. So we built that Hello World Web service using Visual Studio 2003, rolling our own security, reliable messaging, and transaction support. When we built this application as a service with Indigo and Visual Studio 2005, it required only three attributes, or three lines of code. This app demonstrates just how much Indigo does for you, as well as how much Indigo reduces the complexity of writing distributed, interconnected applications.

PM: Do you have a reference to this application online anywhere? If so, does it include the source of the original app, so it can be compared?

AB: Not at this time, but I'm working with the product team to get this posted. We will be posting both the original and final versions of the complete source.

PM: How does Indigo fit into the larger Longhorn picture?

AB: Indigo will provide additional class libraries for VS 2005 developers to incorporate into their applications. In that sense, it is an extension to the .NET Framework 2.0. In terms of operating system support, Indigo will ship as a core subsystem of Windows code-name Longhorn and will also run on Windows XP and Windows Server 2003.

PM: How will Indigo affect the everyday life of your typical IT administrator?

AB: Indigo will provide two significant benefits to the everyday IT pro experience. First, just as Indigo unifies our programming models for developers building distributed applications, it also unifies the way IT pros deploy, discover, configure, monitor, and troubleshoot these distributed applications. Second, Indigo will provide deep support for service instrumentation and configuration, enabling IT pros to monitor detailed information about service health, traffic, and other key characteristics.

PM: We've touched on the end-to-end security features of Indigo. What does Indigo bring to the table overall, especially in light of the fact that security has long been a concern when implementing service-oriented applications?

AB: Indigo provides support for security, reliable messaging, and transactions through support of the WS-* specifications. We're not only providing end-to-end security for messages sent from one service to another, but we're doing so in a way that is interoperable. Security in Indigo relies on a token-based model. When an Indigo message comes into a service, it has a token attached to it, and that token asserts various things about the message. For example, in a simple authentication scenario, a token might help you determine the identity of a message—in other words, where it came from. The Indigo authentication system will look at that message and go, "You claim you were sent by Ari Bixhorn. How can I verify that?"

In a simple scenario, you might have two Indigo services running on a Windows domain. The domain controller would be the trusted authority for those two services. So, my Indigo service would check with the domain controller to verify the authenticity of that message. We also have an extensive authorization model—the same authorization model that is used for ASP.NET—so it supports integration with the Windows Authorization Manager, as well as a config-based authorization model, where you can have a config file that specifies your access control list.

PM: Will Indigo be supported on the Compact Framework?

AB: We're not planning on providing Indigo support for the Compact Framework for version 1, but we've heard from quite a few customers who would like such support, so we're looking at that carefully for future versions of the technology.

PM: If a developer is writing a new application today, how can he set himself up to make the transition to Indigo more readily?

AB: Microsoft will continue to support today's technologies for building distributed applications after Indigo launches. It is also doing work with Indigo to ensure that Indigo services can communicate with apps built using these technologies. That said, developers can take a number of steps to ready themselves for programming with Indigo, and we'll be posting several white papers on MSDN that will detail some of the strategies developers can take in the near future.