dcsimg
RealTime IT News

Microsoft Indigo Architect John Shewchuk

John Shewchuk

Much like the trend of Web services the last couple of years, service-oriented architectures are increasingly getting the (not undue) attention of their software ancestors.

In the last several weeks, IBM, BEA Systems, Oracle and smaller companies, such as Cape Clear and Systinet have been making announcements surrounding SOAs , which describe distributed methods of computing, often employing everyone favorite application-to-application communication model, Web services.

Microsoft has been a tad more discreet about its SOA plans, leading to confusion about its SOA and Web services package, dubbed Indigo. Analysts have questioned whether Indigo is an enterprise service bus, (messaging middleware), or an SOA platform.

Indigo Architect John Shewchuk took time out of his code crunching schedule to define Indigo and how it fits into the overall Longhorn plan.

Q: If it's not an SOA or an ESB, what is Indigo?

Let's take a step back and talk about service-oriented architecture. There are a couple core tenets that service-oriented architectures have. For example, one of the most significant is that it is a loosely coupled architecture where there is a contractual model for the interactions within the pieces.

An essential aspect of that interaction is that the pieces that are communicating are communicated in an autonomous manner so that there aren't tight couplings between the nodes in the system. When we look at the contracts for those communications that go on between the nodes, instead of those things being distributed object systems, which require common runtimes on either side, it's a message-oriented model. Probably the most well-known example of something that is built in a service-oriented architecture is the Web itself, right? There's all these things out there, all these client nodes and server nodes and they're identified by an address, a URL, and they all execute autonomously and it can be on all kinds of different systems.

They can be on Apple [computers], they can be on cell phones, IBM mainframes, Windows boxes. The point is that proper operation of the system does not require common implementations on either side of the wire. So, we have this contract called HTTP and another contract called HTML , and as long as you conform to that contract, you're able to participate in the Web. So that's a great example of service-oriented architecture.

Now, you can build service-oriented architectures on a wide variety of different technologies and with a wide variety of mechanisms for describing the interactions of the service-oriented architecture.

People have done this for a long time. I used to work at IBM; you can build a service-oriented architecture out of MQSeries. You can build them by hand. The challenge has been that the only people who can really construct them were people who wanted to go spend a couple 10 million dollars on software. You'd buy MQSeries, you'd buy TIBCO, you'd buy a transaction monitor, you'd buy a security manager, an identity management system, an audit system, you'd wire it all together with about 50 consultants with PhDs and at the end of the day you have a nice, one-off, service-oriented architecture. And maybe it worked with the one partner you're working with. But the guy down the street who is working with their partner? Your two service-oriented architectures don't interoperate. The economic barrier for people creating service-oriented architecture was just enormous. [Developers] were limited to very significant, large scale enterprise situations.

So then boom -- along comes the Web and along comes SOAP and we suddenly find ourselves in this interesting situation where much of the work that was necessary to build an SOA, we are in the process of putting into platforms and into app servers.

That's point No. 1.

Point No. 2 is that all of the major players have agreed that Web services is the way to build an interoperable service-oriented architecture. That's the key phrase that you want to put in front of SOA. You can build lots of SOAs but they're expensive as hell to build and no one can talk to you. But if you put that word interoperable in front, now you essentially add equals after that to Web services.

There's SOA, then there's interoperable SOA. The arrow coming off of interoperable SOA really points to Web services; and now we get to Indigo. Indigo is an implementation of the Web services, interoperable SOA.

Q: Now that you've explained how Indigo relates to SOAs and Web services, can you talk about the features of Indigo?

Indigo is a "platformization" -- that's kind of a funny word. You could build SOAs with lots of different technologies. In fact, if you just wanted to get a C++ compiler out, you could hand-code an SOA that talked at the Web service protocols and you'd have an interoperable SOA.

The challenge is that it would be a very expensive proposition for the developers to sit down and write one of these interoperable SOAs, because they'd have to go and implement all those Web service protocols. Not only that but it would probably be riddled with bugs.

It probably wouldn't be tested so that all of the interoperability that you'd want with the 30 other platforms that are out there, really wouldn't be great. As a developer, wouldn't it be awesome if you could just go buy an implementation of an SOA? What we do, and what we think we're great at doing at Microsoft, is taking some of these very complex technologies, like windowing systems, databases or whatever it happens to be, making them really cheap, getting broad distribution on them and turning them into things that developers can count on.

Q: Can we say the 'C' word? Commoditization?

Well, sure. We think Windows is a great commodity operating system. It isn't some big expensive thing that you need 500 consultants in order to figure out. And here's the amazing thing. We test it so that all the pieces work together. You can cobble together an SOA by using MQSeries, TIBCO and all those things, but it's going to be a one-off thing. It's certainly not going to be turnkey, install-it-off-a-disk and it's just going to run.

It's going to be this Rube Goldberg scary thing. We're taking what used to be a $10 million software proposition and we're putting it in this $50 piece of software called Windows and it means as a developer, when I want to go sit down and build this cross-enterprise solution, it's there. I just say 'I want to message, I want reliability, I want transactions, and that makes it super easy for developers to construct these things.

Q: How would you position Indigo against an enterprise service bus, which, by most counts, is a shared messaging layer for connecting applications and other services across the computing infrastructure of a business?

Indigo, as a set of capabilities, can do everything that an enterprise service bus does. An enterprise service bus people usually think about as something that supplies some of the fundamental services of a service-oriented architecture, in particular things like the security, the reliability and the transaction. Indigo does all of those things. What makes Indigo so different is that platformization I was talking about. By turning it into an operating system component, we're able to get a level of performance and capability out of this, which is uncharacteristic.

For example, probably one of the most exciting announcements I think in the industry occurred recently, where Intel, Microsoft, Canon and others announced what we call the Device Profile for Web Services. What that does is say 'The way I'm going to talk to a printer now looks exactly the way I'm going to talk to the enterprise, across geographic boundaries to distributed data centers.' I'm going to take Visual Studio and I'm going to talk to Amazon, and if I want to send a print job to a printer, they look the same.

People will start going 'I see, so what you're saying is everything is going to be a Web service and the way I'm going to talk to Amazon is to go up there, talk to a URL and get the WSDL file, and that's going to tell me what kind of messages I can send to Amazon?' Yes. The printer, the scanner, the camera and the projector look exactly the same. It's just one architecture, from the smallest, handheld cell phone all the way up to the largest, distributed data center scenario. That blows people away.

All of the investments we're making in ReliableMessaging at the enterprise level now apply when I'm walking with my laptop on a Wi-Fi LAN, and I'm trying to do a print job and I go between cells and I lose communication for a second. When I get back into communication, ReliableMessaging picks it up and I don't lose my print job. Indigo is the component that will be sitting in Windows to manage the communication to the printer when you're on your laptop walking between buildings.

We're at the cusp of a very important transition in the industry which is, we are bound to have a distributed architecture for everything.