February 9, 2005

Day 1 | Day 2

Indigo Day

In addition to the regular set of technical presentations that were part of the combined VSLive, C# Live, ASP Live, SQL Live, and Microsoft Windows Anywhere conference tracks, today was Indigo Day at VSLive. The keynote was delivered by Eric Rudder, Senior Vice President of Servers and Tools for Microsoft and started with an overview of the push towards connected systems in all of the server products and then going into an overview of the design and features of Indigo. The rest of the sessions in the Indigo Day track dived into some of the details of how to create services and clients with Indigo given by speakers like Don Box, Steve Swartz, Doug Purdy, and Rich Turner. The day ended (late) with the traditional Midnight Madness event featuring an Indigo Q&A, demos of new features in Whidbey, and tons of free stuff.

Keynote

Eric Rudder’s keynote began with a focus on connected systems and the server software features to create integrated service oriented architectures. Some of the products he mentioned were Virtual Server for its ability to aid developers in creating connected systems and Microsoft Operations Manager for its ability to manage connected systems.

Next up was some talk about interoperability and the recent advances in web services such as MTOM and soon to be released standards around reliable messaging building up to the future of web services in Windows, Indigo.

“We've had a good deal of success keeping the industry together around evolving the Web services standards. Toward the end of the year we actually got Coordination and Atomic Transaction published. December, usually kind of an off month, kind of a down month in the industry, but we still had tremendous progress. We had the Discovery Workshop, we had a feedback workshop around WS Management, it's great to actually see us tackle the management problems now, and that's both management of Web services, and management by Web services. So kind of using the technology itself to help manage the technology, and of course enumeration and transfer.”

To give a demo of Indigo, Eric was joined by Product Manager Ari Bixhorn. They demoed a patient monitoring application that pulls data from a brainwave monitor and pulse rate monitor and exposes the information as an Indigo service which is then accessed by two clients, and ASP.NET webpage and a Tablet PC application. They then show how easy it is to extend and interoperate within Indigo by adding another feed for current prescription information which is exposed in a web service running on BEA WebLogic. They further build out the demo by making the Indigo services previously built to operate over a TCP channel to use HTTP by simply changing the Indigo configuration settings in the configuration file. After the web service starts to show a loss of information caused by web service packets being lost over the network, they add reliable messaging and security using just two lines of code.

Eric then talks about the individual components that make up the Indigo unified model including ASMX, WSE, Enterprise Services, Messaging, and Remoting. The ASMX and Enterprise Services changes are mostly changes in namespaces and attributes but should require few code changes. WSE 2.0 does require some code changes (although WSE 3.0 is reported to be 100% compatible with Indigo). Messaging is also largely a namespace and attribute change but Remoting applications will require some significant changes to be compatible with Indigo (more on this later).

He wrapped up the keynote with guidelines for using current technologies in preparation for Indigo.

“So I want to close with a quick call to action. Obviously you're all building applications today using Visual Studio. Start to really think hard about building services using ASMX; that's really your easiest way forward, it's good prescriptive guidance anyway to start thinking about service-oriented architecture and keeping components implemented within service boundaries. I think it will lead to greater agility in terms of how you run your business, even if you don't use "Indigo," heaven forbid.

If you need WS support today and Web services protocol support today, by all means use WSE, WSE is supported, you can call PSS if, heaven forbid, you have a problem; it's a real product, it's not one of these random things we throw on the Web. We are committed to keeping the protocol compatible between WSE and "Indigo" as we move forward.

If you need asynch message patterns, by all means continue to use system.messaging. That will move forward very nicely to the model as we move towards "Indigo."

And continue to use enterprise services for transaction support. We worried about what to do there, we figured out how to take enterprise services, meld it into that unification quite nicely and I think people get some nice benefits on the method-based support as well.”

Programming Indigo

The first breakout session of the day was given by Steve Swartz, a PM Architect for Indigo and Don Box, one of Indigo’s chief architects. This presentation was demo heavy and gave a good overview of what the developer experience is for building Indigo services and clients. The talk started by talking about the ABCs of Indigo

A = Address. This is the end point that makes a service accessible.
B = Binding. Binding represents the transports, encoding, and protocols used by the service.
C = Contract. The contract consists of the operations and schemas for the messages sent and received by the service.

Because the binding and address portions of building an Indigo service are largely taken care of via configuration, the developer can concentrate on the contract and building services without regard for the bindings used. Indigo services at their least complex are very easy to implement. The code below shows a simple Indigo service implementation in VB.NET, which by the way is what Don Box himself used to build the service in his demos.

Imports System.ServiceModel

<ServiceContract(Name:="MyService", Namespace:=http://tempuri.org/MyService)>_
Public Class MyService

<OperationContract>
Function DoSomething(input as String) as String
	'Perform some logic returning a string
End Function

End Class

Module
Sub Main()
	Dim sh as ServiceHost(of MyService)
End Sub
End Module

An interesting item to note is that the object model and the service model are completely separate and so the function doesn’t have to be declared as public to be exposed as part of the Indigo service. Also note that ServiceHost is a new class used to host services accessible via HTTP without the use of IIS. The last thing to do is to add the configuration options to the app.config for the project. Here is the syntax to expose the service using the web service HTTP binding.

<system.servicemodel>
	<services>
		<service serviceType="Server.MyService, server">
			<endpoint address="http://localhost/MyService/"
				bindingType="wsHttpBinding"  <-- Dozen or so bindings in Indigo
				contractType="Server.MyService, server" />
		</service>
	</services>
</system.servicemodel>

The client code is quite simple and uses .NET Generics to access the service via a Channel.

//In any method
Mycontract channel = ChannelFactory.Createchannel<MyContract>
string s = channel.DoSomething("Hello World");
((IChannel)channel).Close();

Indigo doesn’t require that the contract or the code be written first, although they did recommend that developers build the contract first and mention that there will be tools in Indigo for generating types based on WSDL and XSDs. There are also several different types of contracts including Service Contracts which specify the message and port types, Message Contracts which are the SOAP envelopes, and the Data Contracts which are the XSD types used in the messages. Another important point is that a contract can be implemented by any number of different types with completely different logic being performed.

The talk also included some information about the extensibility of Indigo by showing how to control the instancing model used by Indigo.

Building Secure Services with Indigo

The next presentation was by Doug Purdy, Lead PM for Indigo. This presentation was about the security features of Indigo and was intentionally covered at a high level. Rather than show the extensibility features of the security model in Indigo, Doug chose to show how much security comes with Indigo by default. Not to be out acronymed, Doug talked about security using CIA as an abbreviation for the portions of security that are addressed by Indigo.

C = Confidentiality
I = Integrity and Identity
A = Authentication, Authorization, and Auditing

In Indigo, security is a function of Binding and therefore is controllable through the configuration files. There are several standard bindings available which offer different levels of security features.

The BasicProfile* bindings are implementations of the WS-Interoperability Basic Profile standards for interoperability.

During this talk Doug took a very interesting diversion and talked about Remoting in Whidbey and why it is not currently supported as a binding type in Indigo. It seems that the Remoting infrastructure has been rewritten to provide significant performance improvements for interprocess communications. Instead of the proxy models currently used, the .NET 2.0 Remoting stack uses unmanaged code to effectively blit the types in memory. As this is a brand new feature in .NET 2.0 they haven’t currently figured out quite how they are going to work it into the Indigo service model.

Midnight Madness

One of the traditions of VSLive is Midnight Madness, a culmination of three things that are sure to bring developers together; product demos, give-aways, and an open bar. The evening consisted of several different events including an Indigo Q&A, a WinForms demo by Billy Hollis, and Tablet PC demos. Interspersed among the demos were t-shirt and product give-aways that brought the crowd to their feet as the Indigo team chucked shirts and other items into the crowd. Billy Hollis’ demo of an extender provider was unimpeded by rowdy developers in the back shouting out “C#” as he built the demos in VB.NET. The evening ended a bit shy of its Midnight namesake with an extended set of give-aways that included books, software, and other items from Microsoft and other exhibitors.

Authors

Paul Ballard is a MCSD, MCAD, and MCSE certified consultant and the President of The Rochester Consulting Partnership, Inc. He has more than 15 years of experience designing and building client/server and web based distributed applications and is currently specializing in Microsoft's .NET technologies as a consultant, speaker, and trainer. Paul is also a volunteer with INETA and an editor for TheServerSide.NET.