Indigo and Distributed Applications
I've always thought Microsoft keynote speeches had to have been assembled using BizTalk, and Eric Rudder's Indigo talk at VSLive! was no different. BizTalk, of course, orchestrates application components into fulfilling a business process, and Microsoft's keynotes are always well-orchestrated affairs, with multiple speakers, supported by special hardware and software setups and comprehensive slideshows.
Eric outlined the benefits of and developer path to Indigo. The benefits were stated as productivity, interoperability, and Web services orientation. The Web services orientation was a given, so the most impressive thing about Indigo was productivity. A part of that was in net lines of code to implement specific Web service features. For example, Eric showed how Microsoft reduced the manual effort of implementing Web services security, reliable messaging, and transactions from more than 56,000 lines of code to just three.
But I was most impressed with how Microsoft product manager
Ari Bixhorn came on stage and assembled the services behind his demo. I've been in software development in one capacity or another since the 1980s, and the visual assembly of applications has always been a much sought-after goal. In the last 20 years, the graveyards have been littered with companies who promised the ability to develop applications visually, without coding. While Visual Basic was one of the early successes in at least assembling user interfaces visually, Microsoft has generally not taken a leadership role here.
But Ari took some existing Web services, displayed as blocks on a form, and connected them by drawing lines to assemble an application. He even added a Java Web service running on BEA WebLogic, simply by selecting its WSDL to make it visible to his assembly form. He then drew a line from another Web service to it, to complete the application.
The combination of the ability to assemble Web services by diagram and the dramatic reduction in code needed to implement Web services features forms a message that resonates well with me. Both of these enable developers to produce higher-quality applications more quickly.
There is a downside, of course (see my previous blog post entitled "TANSTAAFL"). By abstracting the details away from the implementation, developers lack an understanding of the underlying mechanisms at work. That understanding is necessary when it comes time to enhance applications over their lifecycle, and to debug problems as they arise. While I cheer the work Microsoft is doing, I fear that we are creating a class of developers who lack even a superficial knowledge of the applications they create.
Posted by Peter Varhol on 02/08/2005