Steve Swartz, a PM Architect for Indigo, and Don Box, one of Indigo's chief architects, presented the first breakout session of the day. The presentation was demo heavy and gave a good overview of what developers experience when building Indigo services and clients. They first started by talking about the ABCs of Indigo:
A = Address -- is the endpoint that makes a service accessible.
B = Binding -- represents the transports, encoding and protocols used by the service.
C = 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 is what Box 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
string s = channel.DoSomething("Hello World");
((IChannel)channel).Close();
Indigo doesn't require that the contract or the code be written first, although it did recommend that developers build the contract first and then 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 that specify the message and port types, message contracts that are the SOAP envelopes and the data contracts that 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.
Paul Ballard is the Editor of TheServerSide.NET Enterprise .NET Community. Paul is an MCSD, MCAD, and MCSE certified consultant with more than 15 years of experience designing and building Windows- 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 the founder of the Central Pennsylvania .NET User Group.
