B# .NET Blog : Avalon, Indigo, WinFX, XAML

WinFX November CTP

bart — Tue, 22 Nov 2005 08:17:00 GMT

Woohoo, finally it's there: a build of WinFX compatible with .NET Framework v2.0 RTM. You can find the bits over here: http://www.microsoft.com/downloads/details.aspx?FamilyId=E5376297-DA10-4FC3-967D-38C96F767FC4&displaylang=en. It includes the runtime components of WCF, WPF and WWF. Of course real developers also want the SDK, which is available right now on http://www.microsoft.com/downloads/details.aspx?FamilyId=0A118D5F-21E7-4A3E-82D9-F30C6CE3F63D&displaylang=en. Take a look around on those pages for links to the VS2005 extensions for WCF, WPF and WWF as well as CTP installation notes. Enjoy!

Arrived at the PDC - LA

bart — Wed, 14 Sep 2005 04:55:00 GMT

Okay, pretty late notice due to internet connectivity problems at the hotel, but I arrived at the PDC in LA a couple of days ago after a 11:40 hours flight from Amsterdam to LAX airport. Luckily, I'm not suffering from a jetlag, but I guess that has to do with my lack of biorithm :d.

On Sunday I took the EMEA@PDC odd city tour, yesterday I went to the beach (Venice Beach) with EMEA@PDC to read some stuff, including documents on the C# 3.0, LINQ, DLINQ and XLINQ stuff that was announced in today's keynote by Bill Gates and Jim Allchin which was pretty cool, covering Windows Vista pre-beta 2, Office 12 (it's sooo exciting, believe me ;-)), *LINQ, Atlas and a lot of fun demos by Anders Heijlsberg, Don Box, Chris Anderson and Scott Guthrie. Also check out Microsoft Max, a sample app running on WCF and WPF.

Going to find some food now (12:51 PM).

Introducing Indigo

bart — Fri, 02 Sep 2005 02:36:00 GMT

Introduction

The ~~Indigo~~ Windows Communication Foundation wave is around for a couple of years now, so I thought it was about time to dedicate some blog posts to this technology. In this first technical development-related post on the Indigo technology (I'll use the code-name further on instead of the new WCF name) we'll cover the basis of the technology and service orientation and will go through some simple low-level samples.

Service Orientation

Indigo is all about services. Not web services or Windows services but services. With the advent of the internet several decades ago, the need to have more distributed software is growing day by day. Service Orientation (abbreviated as - originally - SO) is a methodology for software design and development that puts connectivity of software components in the center of the universe, building software on top of services that interact with each other to fulfill business-related needs. An SO solution consists of a series of service that serve as building blocks for an application. Indigo is Microsoft's translation of this Service Oriented software design/development wave, enabling developers to write and build services also concentrating on the communication aspect for services and clients.

Note: You should not think of SO as a replacement for other development paradigms such as object-orientation (OO) or aspect orientation (AOP). Services is about creating facades that encapsulate the inner implementation of a service and expose the functionality of the service to the outside world. The way these services themselves are created can be OO or whatever paradigm you like to use.

SO (or SOA = Software Oriented Architecture) is based on a total of four tenets as proposed by Don Box:

Explicitness of boundaries meaning that messages are sent between services across formal and explicit boundaries. Look at these boundaries as a kind of interfaces, hiding what's behind the boundary itself. Because of the explicitness, crossing a boundary is explicitly visible in code and saves you from boobytraps that are present in technologies such as DCOM, .NET Remoting, RMI, CORBA that make remote objects look as local objects.
Autonomy of services makes it possible to update services independently from each other, without having to redeploy the entire solution as a whole. Loosely coupling is the keyword that makes this possible.
Services share schemas and contracts. Services are not sharing types and classes but schemas and contracts instead. A schema defines data that is sent between endpoints, whileas a contract defines behavior of the service. In web services parlance, a schema can be built in XSD and a contract in WSDL. The use of schemas and contracts ensures more stability (= remain unchanged over time) than their types and classes equivalents in the distributed world.
Compatibility based upon policy states that services agree on how they interact based on policies, describing the capabilities and requirements of the service (e.g. for communication with the service, encryption of data is required). Because of this, the operations (behavior, contract) is separated from contraints that should be enforced on these operations.

Mike Gilbert has a nice post on SOA over here. In the end, services can be seen as "super web services", meaning that limitations of web services are removed in the SO world. Samples include the strong binding to the HTTP protocol and the request/response model but also the removal of limitations on the field of reliability, transactions, policy expression, etc.

Indigo from a 10,000 foot view

Simply stated: SO is the specification, Indigo is Microsoft's implementation of SO. To kick off, we'll jump into some marketing talk on Indigo:

Indigo is a .NET-based technology to build service-oriented solutions. Exactly what we've been describing above.
Indigo provides unification of both the programming model and the runtime. In the past, several technologies existed to create distributed applications. An overview:
- DCOM and .NET Remoting concentrate on remote objects and suffer from the "remote objects are transparent to the client" boobytrap. .NET Remoting is all about communication across application domains and is very extensible (channels, sinks, etc). The technology is fully object-oriented and works with various transport mechnanisms and protocols (e.g. binary of TCP, SOAP over HTTP, etc).
- ASP.NET XML Web Services (.asmx) is Microsoft's first implementation of webservices on the .NET platform. As part of .NET's message, XML Web Services provide interoperability with other platforms and offers a service-oriented design. However, it lacks built-in support for new WS-* standards and can only work with HTTP.
- Web Service Enhancements (WSE) extend the .asmx model and provide support for WS-* standards and other protocols and communication patterns than the plain vanilla HTTP response/request model. WSE is fully .NET-based and uses the power of managed code to deliver its functionality (e.g. attribute-based development). However, it lacks support for transactions, reliable messaging, etc.
- MSMQ and System.Messaging concentrate on reliable messaging with queues as the communication mechanism. System.Messaging makes the use of MSMQ easier in the managed world. However, MSMQ is not available to services directly and is only usable in .NET-to-.NET scenarios.
- COM+ Enterprise Services and System.EnterpriseServices are based on the notion of components that are decorated with .NET attributes to provide several services such as security and transactions. COM+ is component-based and built on the OO paradigm. However, it's a .NET-only story and lacks interoperability.
Indigo is scale-invariant. In more detail:
- Scales down to devices such as printers, cameras, etc with support for WS protocols. On longer term, you can expect to see Indigo support on smart devices using the Compact Framework.
- Scales in meaning that inter-process (or inter-appdomain) communication is damn fast (greater than or equal to .NET Remoting and/or Enterprise Services).
- Scales up on large systems with high throughput and scalability which is mission-critical to systems with high workload and tons of consumers. Compared to existing technologies, Indigo wants to be superior.
- Scales out by adding machines, e.g. in farms or on the routing-level (cf. WS-Routing and WS-Addressing). Information on these protocols applied to WSE 2.0 can be found on MSDN.
- Scales away across organizations and geographies, referring to the use of interoperable protocols, reliable messaging and transmission fault tolerance and federation of security (cf. the former "TrustBridge" project and ADFS).
Indigo puts interoperability in the spotlight. Examples include:
- On the field of transport, there's support for the well-known omnipresent HTTP protocol.
- The central communication and messaging format is in XML and associated technologies such as XSD and XPath.
- For messaging, SOAP and WS-Addressing are used.
- Metadata is described by WSDL, WS-Policy and WS-Metadata Exchange standards.
- Security is based on WS-Security, WS-Trust and WS-Federation standards.
- Reliability is realized through WS-Reliable Messaging.
- Transactions between services can be established using WS-Transactions and WS-Coordination.

Note: Also search on MSDN for more information about all of the aforementioned technologies and specifications.

Basic architecture of Indigo

Time for some illustrations. The picture below shows the basic layered architecture of Indigo.

Let's go through this picture from top to bottom:

At the uppermost layer, we have our application (a service) that's using the Indigo stack below.
Next, we have a series of messaging services that provide functionality to the application above. Samples include queuing, routing, eventing and discovery of services.
The service model provides the basic service-related functionality. This layer is all about behavior, such as error behavior, instance behavior, activation behavior, concurrency and transactions, etc.
The messaging layer delivers all functionality to the service model to create channels and to transport the messages between services. It also provides "side-services" such as security, reliability, policy and encoding. For transport channels such as HTTP, TCP, MSMQ, cross-process are supported.
Last but not least, the Indigo application is hosted in e.g. IIS, Avalon, an executable, a Windows Service or COM+.

I'll dive deeper into these in more detail further on and in upcoming posts on Indigo.

Some crucial concepts

Right, we know what Indigo does and we know the basic layered architecture. Time for some concepts that will be crucial for further understanding of Indigo stuff. Concentrate on the following simple sentence:

Services interact by exchanging messages.

This simple statement implies a lot of questions. Some samples: How are messages exchanged physically? Who send and who recieves messages? How does such a message look like? Are there different interaction patterns possible? Now the answers:

The key players in messaging are clients that initiate communication, the services that accept these messages and respond to them and possible intermediaries that route messages to their destination and inspect/manipulate the messages optionally. Notice that services themselves can also act as clients, resulting in a chain of services that are linked to each other.
The message structure in Indigo is based on SOAP, which is on its turn XML-based. From a macroscopic point of view, a message contains a series of headers as well as a body. Together, this forms a so-called SOAP Envelope. However, the encoding of the message and the transport protocols are configurable.
Channels are the pipelines over which information flows. The function of channels is twofold. First, channels are used for physical delivery of messages over various transport protocols such as HTTP, TCP, MSMQ and cross-proc, also providing reliability and/or session services if desired. Second, messages are manipulated by channels for encoding (binary, MTOM, etc) and decoration of messages to provide security features (e.g. Windows authentication).
Various interaction patterns exist in the world of Indigo. Starting with one-way simplex communication, over two-way duplex communication to request/reply based patterns.

Now look at a service as a black box. What should the service expose? Two seconds left for the answer :-). Right, first of all we need a description of the service because of the loosely coupling. This means it should be possible to discover information about what the service provides (behavior, operations, policy) and how to interact with it (message contracts). The discovery and description aspect of services is accomplished by WSDL, XSD, WS-Policy and WS-Metadata Exchange. Getting to know each other is one thing, working with each other is another thing. So, we also need endpoints for communication (as described by the obtained description) using SOAP.

Apart from the service's logic there should be other things inside a service as well. First, it needs to be able to provide its metadata to describe itself and the message contracts. That's the service description part of the inside story. Next, the consumer of the service needs to be able to get in through an endpoint. Therefore, we need a description of the way the service interacts with the outside world, which is called a binding. Such a binding encapsulates the transport mechanism (e.g. HTTP, TCP, named pipe, MSMQ), encoding (text, binary, MTOM) and requirements on the field of security, sessions, reliablity and transactions as well as available messaging patterns. The endpoint on the other hand is all about where the service is (an address) associated to a service contract and a binding. This brings is us the missing piece of the puzzle, being the contracts. Indigo knows three kinds of contracts:

Service contracts define the operations the service provides and its behavior. Compare such a contract with an interface from the OO world and you should have a pretty good understanding of such a contract. Of course, the service needs to implement the control to be useful (a class).
Data contracts specify data structures that are used to pass data to/from the service. The big idea of data contracts is to decouple internal class representations from the messaging format, which can be described in XSD for interoperability reasons and loose coupling.
Message contracts allow to manipulate the message structure and format of messages that are sent between services and consumers.

A little illustration can make things more clear I believe. Assume you have a service contract called IWeatherService that allows to report the weather using an operation that accepts a location (postal code, state, country in a data contract) and returns a weather report (temperature, air pressure in another data contract). The functionality of the service can be exposed through an endpoint consisting of an address (http://blabla/WeatherService or net.tcp://blabla:port/WeatherService or net.pipe://blabla/WeatherService or net.msmq://localhost/queue/WeatherService) and a binding mapping the address to the contract and enriching it with e.g. security. Thus, as a little rule of the Indigo thumb, remember the following:

endpoint = address + binding + contract

Services expose functionality but also have intrinsic runtime behavior. Indigo provides support for the following:

Concurrency - If multiple consumers use your service, how does it work with threading? Possible answers are: one single thread can access the service instance, multiple threads can access the service instance or reentrancy support meaning that threads can call into one another.
Error handling - Who will handle errors in the service? The developer himself, the Indigo framework or the client of the service (i.e. sending a fault to the client).
Instancing - People who've been working with .NET Remoting will know concepts such as singleton and singlecall. Indigo supports four mode: singleton (one instance serving all consumers), per call (used in stateless scenarios, such as classic web services), private session (each client session has its own service instance) and shared session (groups of clients can share a single session).
Lifetime - When using stateful sessions (e.g. a private session), there needs to be a session start en session end 'event'. The service itself can control the lifetime of the session if operations on the service are marked as session initiators and/or session terminators.
Metadata - This answers the question: "how can the service present itself to (possible) consumers?". By enabling metadata to be requested on demand through a request, a service is made self-describing using WSDL, WS-Policy, WS-Metadata Exchange.
Security - Service security is composed of various aspects, including message integrity and confidentiality, user authentication and authorization, DoS and replay (attack) detection, auditing. Indigo has support for PKI using X.509 but also supports Kerberos, plain old username/password mechanisms and more recent standards such as SAML.
Throttling - Used to limit the total number of service instances, concurrent threads, exchanged or accepted messages, etc. Using throttling, one can control resource consumption of the service, aiding with scalability measurement and planning.
Transactions - Indigo has support for transactions across services using WS-Atomic Transaction and other WS-* standards. This allows clients to start a transaction and flow it to one or more services that can then participate in that transaction. The service behavior for transactions is used to indicate whether the service will accept a transaction, requires a (new) transaction, etc.

Getting started

Enough theory for now, let's jump onto the Indigo wagon with a little sample. But first, some information on how to set up the stuff needed to bring our sample to a good end.

Download each of the following on either Windows XP (+ SP2) or Windows Server 2003 (+ SP1):

.NET Framework Version 2.0 Redistributable Package Beta 2 (x86) - the .NET runtime on which Indigo is built
Visual Studio 2005 Beta 2 - can be obtained via beta programmes (e.g. Microsoft EMEA's TheBetaExperience) or on MSDN Subscriptions
"Indigo" Beta 1 MSMQ Support Package - needed for MSMQ support for queued channels (only needed for beta 1 currently)
COM+ Hotfix for "Indigo" - contains WS-AtomicTransaction support for MSDTC and allows COM+ apps to be exposed using Indigo
Microsoft Pre-Release Software WinFX Runtime Components Beta 1 - package with beta 1 of both Indigo (Windows Communication Foundation) and Avalon (Windows Presentation Foundation)
Microsoft WinFX Software Development Kit for Microsoft Pre-Release Windows Operating System Code-Named "Longhorn", Beta 1 Web Setup - WinFX SDK with documentation and samples for Indigo and Avalon development (despite the naming of the download also supported on Windows XP and Windows Server 2003)
Microsoft Visual Studio Extensions for WinFX Beta 1 - Visual Studio 2005 Beta 2 support for WinFX components and the WinFX SDK documentation

and install each of these in ascending order.

Your first Indigo application

As I don't want to be banned from the demo writing community I should start with the mandatory "Hello World" demo :-). The following instructions will guide you through the process of creating both an Indigo service and client:

Start Visual Studio 2005 and create a new Project in C# and choose a Console Application as the template. Call it IndigoDemo.
In the Solution Explorer, right-click on References and choose "Add Reference...". Select System.ServiceModel from the list and click OK.
Add the following namespace import to the top of the Program.cs file:

using System.ServiceModel;
In the IndigoDemo namespace, we'll first create the service contract. We'll choose for a contract named IHello with two members, SendMeGreeting and HelloIndigo, as shown below. Notice the use of an interface and the ServiceContract and OperationContract attributes:

[ServiceContract]
public interface IHello
{
    [OperationContract]
    string SendMeGreetings(string name);
    [OperationContract]
    string HelloIndigo();
}
To the same IndigoDemo namespace, add a class called HelloService that implements IHello, as shown below:

public class HelloService : IHello
{
    #region IHello Members

    public string SendMeGreetings(string name)
    {
        return string.Format("Hello {0}", name);
    }

    public string HelloIndigo()
    {
        return "Hello Indigo";
    }

    #endregion
}
Now it's time to create the "service host" that will run the service. ServiceHost is the class you need to do this. The following Main method contains the Indigo hosting code for our service:

static void Main(string[] args)
{
     //
     //Host the service in a simple console application
     //
     using (ServiceHost<HelloService> svc = new ServiceHost<HelloService>())
     {
          //
          //Add endpoint for the IHello contract, with a default WS-Profile binding on the specified address
          //
          svc.AddEndpoint(
               typeof(IHello),
               new WSProfileBinding(),
               "http://localhost:1234/HelloService"
          );

          //
          //Launch the service
          //
          svc.Open();

          Console.WriteLine("Service is running. Press <ENTER> to stop.");
          Console.ReadLine();

          //
          //Stop the service
          //
          svc.Close();
     }
}

In this code, we create a (generic) instance of a ServiceHost for our HelloService. Next, an endpoint is added, which consists of an address, a binding and a service contract, being the interface IHello which was annotated with the ServiceContract tag earlier. Starting the service is as simply as calling Open, and stopping it can be done using Close.
So far so good. The service is ready, now we'll jump to the client-side piece of our demo. In the Visual Studio 2005 IndigoDemo solution, add a new C# Console Application project called IndigoDemoClient.
In the Solution Explorer under IndigoDemoClient, right-click on References and choose "Add Reference...". Select System.ServiceModel from the list and click OK.
In order to make our client aware of the service contract of our service, we need to copy the IHello interface over here as well. We'll see a sample with discovery later on. For now, just copy the IHello interface to the IndigoDemoClient namespace:

[ServiceContract]
public interface IHello
{
    [OperationContract]
    string SendMeGreetings(string name);
    [OperationContract]
    string HelloIndigo();
}
Time for the client. As you might expect, we need a proxy. How to obtain that proxy? Using the generic ChannelFactory.CreateChannel static factory method, as shown below:

static void Main(string[] args)
{
    //
    //Ask the user for input
    //
    Console.WriteLine("Client is running. Enter your name and press <ENTER> to talk to the service.");
    string name = Console.ReadLine();

    //
    //Create a proxy for the service
    //
    IHello proxy = ChannelFactory.CreateChannel<IHello>(
        new Uri("http://localhost:1234/HelloService"),
        new WSProfileBinding()
    );

    //
    //Call the service to send a greeting
    //
    string greeting = proxy.SendMeGreetings(name);

    //
    //Housekeeping
    //
    ((IChannel) proxy).Close();
    ((IChannel) proxy).Dispose();

    //
    //Output to the user
    //
    Console.WriteLine("The server answered: {0}", greeting);
    Console.WriteLine("Press <ENTER> to quit.");
    Console.ReadLine();
}

This code should be pretty self-explanatory in my very opinion. As you can see, the use of generics makes creation of a proxy easier but also introduces some plumbing (see the housekeeping part). You can avoid this plumbing however by applying the following trick to IHello:

[ServiceContract]
public interface IHello : IChannel
{
    [OperationContract]
    string SendMeGreetings(string name);
    [OperationContract]
    string HelloIndigo();
}

and changing Main like this:

static void Main(string[] args)
{
    //
    //Ask the user for input
    //
    Console.WriteLine("Client is running. Enter your name and press <ENTER> to talk to the service.");
    string name = Console.ReadLine();

    //
    //Placeholder for the answer
    //
    string greeting;

    //
    //Create a proxy for the service
    //
    using (IHello proxy = ChannelFactory.CreateChannel<IHello>(
        new Uri("http://localhost:1234/HelloService"),
        new WSProfileBinding()))
    {
        //
        //Call the service to send a greeting
        //
        greeting = proxy.SendMeGreetings(name);

        //
        //Close connection to the service
        //
        proxy.Close();
    }

    //
    //Output to the user
    //
    Console.WriteLine("The server answered: {0}", greeting);
    Console.WriteLine("Press <ENTER> to quit.");
    Console.ReadLine();
}
Time to run it. Right-click the IndigoDemo solution on top of the Solution Explorer and choose Properties. In Common Properties, Startup Project select Multiple startup projects and set the action for both the IndigoDemo and IndigoDemoClient application to 'Start'. Click OK.
Now hit F5 to run the application. Once the service console prints "Service is running. Press <ENTER> to stop." switch to the client console and type you name. Output similar to the following should be displayed:

Client is running. Enter your name and press <ENTER> to talk to the service.
Bart
The server answered: Hello Bart
Press <ENTER> to quit.
Exit the client by pressing <ENTER> but leave the service host console window running.

In this first sample you saw how to create both a service and a client without the use of a configuration file, just by writing plain code. I chose to use the WSProfileBinding which is well-suited for HTTP (or HTTPS) services with the well-known Request-Response (or Simplex) message pattern style. One of the things we saw was how to create a proxy using the ChannelFactory class of Indigo. Now I want to take you to the next step of discovering a running service:

Assuming you followed the steps above correctly, the service should still be running now. If it's not, restart the Visual Studio 2005 debugger using F5 and wait for the service to come alive.
Open an instance of Internet Explorer and go to http://localhost:1234/HelloService. You should see a page "Indigo Service" that tells you "You have created an Indigo service." If you didn't realize this yet, it's time to awake now :-). The page also contains a link to the well-known WSDL discovery address on http://localhost:1234/HelloService?wsdl, just like this was the case with classic web services.
Indigo provides a command-line utility called svcutil.exe which is accessible through the Visual Studio 2005 Command Prompt. Call svcutil.exe /? to see the functionality it provides:

C:\temp>svcutil
Microsoft (R) Service Model Metadata Tool
[Microsoft(R) .NET Framework, Version 2.0.50215.0]
Copyright (C) Microsoft Corporation. All rights reserved.

svcutil.exe: Utility to generate ServiceModel code from Metadata documents, and
vice versa.

- USAGE -
svcutil.exe [options] [metadataPath* | assemblyPath* | metadataUrl*]

svcutil.exe differs from wsdl.exe on quite some fields. One notable difference is the support to work in two ways: metadata-to-assembly and assembly-to-metadata.
Time to experiment with it. Execute svcutil.exe http://localhost:1234/HelloService?wsdl as mentioned on the web page from step 2. The result should look like this:

C:\temp>svcutil.exe http://localhost:1234/HelloService?wsdl
Microsoft (R) Service Model Metadata Tool
[Microsoft(R) .NET Framework, Version 2.0.50215.0]
Copyright (C) Microsoft Corporation. All rights reserved.

Generating files...
C:\temp\tempuri.org.Bindings.cs
C:\temp\output.config

Two files have been generated. Take a look at both of these using Notepad.
In the first file, the tempuri.org.Bindings.cs file, you should find three members. First of all, there's a IHello interface that looks the same as the original one you wrote yourself in the service's code. The second interface is the IHelloChannel which derives from IHello and IProxyChannel. And last the most important class, HelloProxy. This class both derives from the IHello contract interface and the ProxyBase generic class. Notice that the address of the endpoint is not in the code, in contrast to the output of wsdl.exe in the (near) past. This variable information lives in the output.config file.
Open the output.config file and notice the following sections (marked in red):

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    <system.serviceModel>
        <client>
            <endpoint address="http://localhost:1234/HelloService" bindingConfiguration="IHello"
                bindingSectionName="customBinding" contractType="IHello">
                <addressProperties actingAs="http://localhost:1234/HelloService"
                    identityData="" identityType="None" isAddressPrivate="false" />
            </endpoint>
        </client>
        <bindings>
            <customBinding>
                <binding configurationName="IHello">
                    <contextFlow transactions="Ignore" transactionHeaderFormat="OleTx"
                        logicalThreadId="Ignore" locale="Ignore" />
                    <security algorithmSuite="Default" authenticationMode="SspiNegotiated"
                        contextMode="Session" defaultProtectionLevel="EncryptAndSign"
                        enableKeyDerivation="true" includeTimestamp="true" messageProtectionOrder="SignBeforeEncrypt"
                        securityVersion="WSSecurityXXX2005" secureConversationVersion="WSSecureConversationFeb2005"
                        trustVersion="WSTrustFeb2005" generateRequestSignatureConfirmation="false" />
                    <httpTransport manualAddressing="false" maxMessageSize="65536"
                        authenticationScheme="Anonymous" bypassProxyOnLocal="false"
                        hostnameComparisonMode="StrongWildcard" mapAddressingHeadersToHttpHeaders="false"
                        proxyAuthenticationScheme="Anonymous" realm="" transferTimeout="00:01:00"
                        useSystemWebProxy="true" />
                    <textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"
                        messageVersion="Default" encoding="utf-8" />
                </binding>
            </customBinding>
        </bindings>
    </system.serviceModel>
</configuration>

All of the marked sections should be easy to understand right now. There's an endpoint which consist of - remember? - an address, a binding and a contract. Remember that these three go hand-in-hand all the time. I won't cover the other stuff of the config file for now, but most of the generated stuff is related to the WS-Profile binding that was specified concerning security, sessions, transport protocol and encoding.
Let's create a simple client now, at the command line. In the folder where the tempuri.org.Bindings.cs file was dropped, create a new file called demo.cs and add the following code to it:

class Test
{
    static void Main(string[] args)
    {
        HelloProxy proxy = new HelloProxy();
        string result = proxy.SendMeGreetings(args[0]);
        System.Console.WriteLine("The Hello service returned '" + result + "'");
        proxy.Close();
    }
}
Now compile the tempuri.org.Bindings.cs file first, as follows:

C:\temp>csc -r:System.ServiceModel.dll -t:library tempuri.org.Bindings.cs
Microsoft (R) Visual C# 2005 Compiler version 8.00.50215.44
for Microsoft (R) Windows (R) 2005 Framework version 2.0.50215
Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.
Next, build the demo.cs file, referencing both the System.ServiceModel.dll and tempuri.org.Bindings.dll assemblies:

C:\temp>csc -r:tempuri.org.Bindings.dll,System.ServiceModel.dll demo.cs
Microsoft (R) Visual C# 2005 Compiler version 8.00.50215.44
for Microsoft (R) Windows (R) 2005 Framework version 2.0.50215
Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.
Last but not least, rename output.config to demo.exe.config:

ren output.config demo.exe.config
Now run demo.exe with one parameter, specifying your name:

C:\temp>demo Bart
The Hello service returned 'Hello Bart'

Works great. So far, we've been hosting our service in a console application. However, you can host the service in IIS as well (or in other hosts). Let me show how (assuming you have IIS 5.1 or 6.0 up and running and you installed .NET v2.0 and WinFX afterwards):

Stop your Visual Studio 2005 debugger if it's still running. Add a C# Type Library project to the solution and give it the name "IndigoDemoLibrary".
In the Solution Explorer under IndigoDemoLibrary, right-click on References and choose "Add Reference...". Select System.ServiceModel from the list and click OK.
Add the IHello interface and the HelloService class of the earlier IndigoDemo service project to the Class1.cs file. Save the file and compile the solution.
Open Windows Explorer and create a folder somewhere on your system. I'll be using c:\temp\HelloService. In this new folder, create a subfolder called bin.
Open the bin-folder of the IndigoDemoLibrary project, in my case C:\Documents and Settings\...\My Documents\Visual Studio 2005\Projects\IndigoDemo\IndigoDemoLibrary\bin\Debug, and copy the IndigoDemoLibrary.dll file to the bin folder (c:\temp\HelloService\bin) created in step 4 above.
In the (root) folder created in step 4 above (c:\temp\HelloService), create a file called service.svc, with the following code:

<%@Service Language="C#" class="IndigoDemoLibrary.HelloService" %>
<%@Assembly Name="IndigoDemoLibrary" %>
In the same folder, create a web.config file containing:

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    <system.serviceModel>
        <services>
            <service serviceType="IndigoDemoLibrary.HelloService">
                <endpoint address="" bindingSectionName="wsProfileBinding" contractType="IndigoDemoLibrary.IHello, IndigoDemoLibrary" />
            </service>
        </services>
    </system.serviceModel>
</configuration>
Now it's time to configure the Indigo service virtual directory in IIS. Go to Start, Run, enter "inetmgr" (without quotes) and click OK. Locate the "Default Web Site" under <computername>\Web Sites. Right-click and choose New, Virtual Directory. Click Next. In the field Alias specify "HelloService" (wtihout quotes) and click Next again. Now specify the folder you created in step 3 (c:\temp\HelloService). Click Next. On the "Access Permissions" wizard screen make sure both Read and Run scripts are enabled and click Next. Finally, click on Finish.
If you have both .NET v1.x and v2.0 on the machine, right click on the HelloService virtual directory you just created and go to the Properties. On the ASP.NET tab in the first dropdownlist select version 2.0.50215.0 and click OK.
Open an Internet Explorer instance and navigate to http://localhost/helloservice/service.svc. You should get to see the same page as you saw earlier with our console-hosted Indigo service.
I guess you'll be able to figure out for yourself how to adapt the demo.exe.config file from the previous demo in order to use the IIS-hosted Indigo service instead. Small tip: you need to change an address on two places, somewhere in the neighborhood of the <endpoint> tag :-). In case you're not seeing clear enough, an alternative configuration file is listed below:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    <system.serviceModel>
        <client>
            <endpoint
                address="http://localhost/HelloService/service.svc"
                bindingConfiguration="IHello"
                bindingSectionName="wsProfileBinding"
                contractType="IHello" />
        </client>
        <bindings>
            <wsProfileBinding>
                <binding configurationName="IHello" />
            </customBinding>
        </bindings>
    </system.serviceModel>
</configuration>

What's coming next?

In my next Indigo-related posts, I'll cover data and message contracts, other types of addresses and binding and much more. Stay tuned once again ... you ain't see nothing yet :-).

My Dear Huge Demo VPC

bart — Wed, 31 Aug 2005 22:06:00 GMT

After more than 8 hours looking at progress bars, my brand new VPC with beta stuff is ready. It contains:

Windows XP SP2 + Platform SDK
Office 2003 SP1
.NET Framework 1.1
.NET Framework 2.0 Beta 2
WinDbg 6.5
Internet Explorer 7 Beta 1
Visual Studio 2005 Team Suite Beta 2
SQL Server 2005 CTP
Microsoft Shell Beta 1 (MSH aka Monad)
WinFS Beta 1 + SDK
WinFX Beta 1 (Avalon, Indigo) + Visual Studio Extensions + SDK

Time to clone the VPC harddisk image (about 16 GB used disk space) and start playing with all this stuff. You'll see posts about all this exciting stuff later on over here. Stay tuned!

Do you know Windows Presentation Foundation and Windows Communication Foundation already? Yes, you do!

bart — Fri, 29 Jul 2005 06:54:00 GMT

Avalon, Indigo and other Vista subsystems have been renamed to marketing-shaped flashy names :-). More information on Dave Glover's blog.

Microsoft® Pre-Release Software Code Named “Avalon” and “Indigo” Beta1 RC (ISO)

bart — Mon, 25 Jul 2005 19:48:00 GMT

Well, the title should be clear. You can grab the bits over here. One extract from the website:

This Beta1 "RC" release supports Visual Studio 2005 Beta2 and the .NET Framework 2.0 beta 2. There is also an updated WinFX SDK, including documentation, samples and tools available for this release. ... Supported Operating Systems: Windows Server 2003; Windows XP Service Pack 2

The WinFX SDK Beta1 RC can be downloaded over here. Both files are ISOs, so you can use the VCD ISO tool from MSDN to mount it to a drive letter, or you can burn it to a cd-rom, or you can attach it to a virtual machine in Virtual PC or Virtual Server directly.

Ready for a download of over half a gig? Well, you should to become a real Indigoing Avaloner guy :-).

Reliable messaging using MSMQ simplified

bart — Sat, 23 Jul 2005 10:34:00 GMT

Introduction

The upcoming technology release of Indigo will simplify a lot of stuff around MSMQ and other "distributed software" technologies out there. Based on attribute-based programming the underlying implementation of various application aspects such as reliable messaging, service policies, service contracts, etc is abstracted and hidden for the developer, while relying on the various standards that were developed recently on the WS-* field. In a similar way the use of various transportation channels such as HTTP, MSMQ, etc is made easier and more transparent. So far for some Indigo evangelism on my blog for now (I'll do extensive posting on Indigo later this year once beta 1 of "Windows Vista" hits the road).

However, nowadays the development of a SOA-based application with reliable messaging support is not that straightforward as it could be. WSE currently lacks support for reliable messaging support as such through the WS-* series of standards. There is however a sample by architect George Copeland on how to do implement a reliable messaging solution using WSE 3.0 that can be found on MSDN on http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/html/wseandws-rm.asp. In the first half of this year however (this article is dated in June this year) I came across the problem of implementing such a reliable messaging solution that could be combined with a service-oriented approach, as part of my last year's dissertation (which can be downloaded on http://www.bartdesmet.net/download/thesis/, in Dutch however). In this post I'll show you some of this stuff.

Basics of MSMQ

If you ask a developer for the Windows platform for a messaging solution in the Windows OS, he/she should come up with MSMQ as the answer number one. I won't explain MSMQ itself over here, more information can be found on www.microsoft.com/msmq (look for MSMQ 3.0, which is the XP/2003 version of the technology). In .NET you can use the MSMQ technology by taking advantage of the System.Messaging namespace which is pretty straightforward to use. The basic steps look like this:

Create a message queue using the MSMQ management tools, through an installer class or using code (MessageQueue.Create). You can choose to create a public queue or a private queue, with or without transactional support.
Put messages on the queue in application A, using the Send method on the MessageQueue class. The message object should be marked as [Serializable] in order to serialize it and put it on the queue as a message. To send more complex messages with support for encryption, priority based delivery, timeout values, etc you have to use the Message class instead.
Receive the message at the other side (application B) using the Receive method on the MessageQueue class, pointing to the same queue. This method returns a Message object, from which you can get the message itself by using the Body property. In reality, you'll have to attach a formatter to the message queue instance to make deserialization possible, based on the original type of the message object.

In code, this looks as follows:

//sender
MessageQueue mq = new MessageQueue(path);
Message msg = new Message(body_object_of_message); //assume the type of this object to be MyMessageType
mq.Send(msg, somelabel); //the label can be a GUID or a textual message

//receiver
MessageQueue mq = new MessageQueue(path);
mq.Formatter = new XmlMessageFormatter(new Type[] { typeof(MyMessageType) }); //alternatively use a binary formatter
Message msg = mq.Receive(); //use a
MyMessageType original_message = (MyMessageType) msg.Body;

As you can see, this approach does not have a service-oriented look and feel. First of all, the messaging stuff is far too heavy to code using the System.Messaging namespace. Let's say it's too low-level to be really handy to program. A second drawback is the fact that you need to wrap a series of parameters to some call in a (serializable) message object. In contrast, a web service is far more easy to use:

//sender
object res = proxy.DoSomething(par1, par2, par3);

//receiver
[WebMethod]
object DoSomething(object par1, object par2, object par3)
{
//perform work
}

When doing the same in MSMQ, you have to wrap the service operation parameters in a data carrier object (called the message) in order to do the same. Another disadvantage of the use of MSMQ for developing kind of a service-oriented application is the hosting of the app: you'll be responsible to write a server application that listens on the queue to take in requests, process them (on a background thread maybe) and send the result back to the client (using a response queue, because messaging in MSMQ is one-way messaging by design).

So, the drawbacks of MSMQ and System.Messaging are:

Object-based, not method-based (read: no "service operation" concept)
Low-level API, little abstraction for SOA
No hosting functionality (server app), no abstraction on the client (proxy client)
Uni-directional communication by default

Writing the server application really isn't that straightforward at all. When bidirectional communication or message acknowledgements (as part of a reliable messaging solution) are needed, a signficant amount of additional code ("plubming"?) is needed. Furthermore, threading will be required to have a better scalability and the use of a Windows Service as the application host is likely to be your choice. Combined, you'll have pretty much work to do in order to get the whole thing up and running.

Services built on top of MSMQ

Defining an MSMQ service

Somewhere in March/April I decided to write an abstraction layer for MSMQ that allows developers to create a service that uses the MSMQ protocol for (reliable) message delivery while maintaining the advantages of attribute-based development to write the service. That way, developers would not have to worry about creating a service application or a proxy manually, or to create the wrapper types for service operation calls. As a result, the development of this allows developers to write code like this:

[MsmqService] //compare with WebService
public class MyService
{
   [MsmqMethod] //compare with WebMethod
   public int Sum(int a, int b)
   {
      return a + b;
   }
}

Once this code is written and compiled, it's time to make it available over MSMQ. To do this, we need to generate a service application to host the code needed for multi-threading, message-to-operation translation, etc. As the matter in fact, this little piece of code results in:

2 message queues, one for the input parameters (a, b) and one for the answer (the sum)
2 carrier types, one for the input parameters (a, b) and one for the answer (the sum); both need to be serializable

Generating a service contract

In order to make things easier, a tool called mqdl.exe is available to convert the class definition (compiled to a .dll assembly) to a so-called MQDL service contract. This is called "export" mode. For the sample mentioned above, this looks as follows:

<?xml version="1.0" standalone="yes"?>
<MqdlDocument>
<Service svc="SomeService" component="SomeTestService.SomeService">
    <Operation id="Sum">
      <Input>
        <Parameter name="a" type="System.Int32" />
        <Parameter name="b" type="System.Int32" />
      </Input>
      <Output type="System.Int32" />
    </Operation>
</Service>
</MqdlDocument>

Creating a service application

Next, the mqdl.exe tool can be used to generate a service application and a proxy class. Let's start with the service application, called "svcman" mode. For each operation, a monitor is created that's watching a message queue. When a message is received, it's deserialized and passed to the service class (that we did create earlier) for processing. The answer that comes back is wrapped into a response message object, that is sent back on the response queue that's associated with the incoming message queue. The generated code for the Sum operation looks like this:

public class SumMonitor
{
        delegate System.Int32 ProcessDelegate(System.Int32 in1,
                                              System.Int32 in2);

        private class ProcessCallbackData
        {
            public ProcessDelegate pdel;
            public Message msg;
        }

        private MessageQueue queue;
        private bool stop = false;
        private bool stopped = false;

        public SumMonitor(string prefix)
        {
            string path = prefix + "SumRequests";
            if (!MessageQueue.Exists(path))
                MessageQueue.Create(path);
            queue = new MessageQueue(path);
            queue.Formatter = new XmlMessageFormatter
   (new Type [] { typeof(InputSum) });
        }

        public void Stop()
        {
            stop = true;

            while(!stopped);
        }

        public void Start()
        {
            while(!stop)
            {
                try
                {
                    Message msg = queue.Receive(TimeSpan.FromSeconds(5));

                    InputSum input = (InputSum) msg.Body;

                    SomeTestService.SomeService svc
    = new SomeTestService.SomeService();
                    ProcessDelegate d = new ProcessDelegate(svc.Sum);
                    ProcessCallbackData pcd = new ProcessCallbackData();
                    pcd.pdel = d;
                    pcd.msg = msg;
                    d.BeginInvoke(input.in1, input.in2,
                                  new AsyncCallback(Done), pcd);
                }
                catch {}
            }

            stopped = true;
        }

        private void Done(IAsyncResult res)
        {
            ProcessCallbackData pcd = (ProcessCallbackData) res.AsyncState;

            OutputSum output = new OutputSum();
            output.output = pcd.pdel.EndInvoke(res);

            Message resp = new Message(output);
            resp.CorrelationId = pcd.msg.Id;
            pcd.msg.ResponseQueue.Send(resp);
        }
}

Note that callbacks are used to call the underlying service class in an asynchronous fashion. Furthermore, transport types are generated based on the MQDL contract:

[Serializable]
public class InputSum
{
    public System.Int32 in1;
    public System.Int32 in2;
}

[Serializable]
public class OutputSum
{
    public System.Int32 output;
}

Next, a service manager class is generated to host all of the monitors and start these on different threads:

public class ServiceManager
{
    private SumMonitor m1;

    public ServiceManager(string path)
    {
        m1 = new SumMonitor(path);
    }

    public void Start()
    {
        new Thread(new ThreadStart(m1.Start)).Start();
    }

    public void Stop()
    {
        m1.Stop();
    }
}

In the end, you just need to write a simply application (e.g. a Windows Service) that calls the Start and Stop methods on the ServiceManager, like this:

public static void Main()
{
ServiceManager mgr = new ServiceManager(".\\private$\\");
mgr.Start();
}

Consuming the service

At the other side, we need a proxy to hide all of the details of translating a service call to a transport type, sending it to a request queue, polling the response queue and translate the answer back to a method call return value. This is done by the "proxy" mode of mqdl.exe, which generates code like this:

public System.Int32 Sum(System.Int32 a, System.Int32 b)
{
MessageQueue __queueReq = new MessageQueue(__path + "SumRequests");
__queueReq.Formatter = new XmlMessageFormatter(
new Type [] { typeof(InputSum) });

string __pathResp = ".\\private$\\" + Guid.NewGuid().ToString();
MessageQueue __queueResp = MessageQueue.Create(__pathResp);
__queueResp.Formatter = new XmlMessageFormatter(
  new Type [] { typeof(OutputSum) });

InputSum __input = new InputSum();

__input.in1 = a;
__input.in2 = b;

Message __req = new Message(__input);
__req.ResponseQueue = __queueResp;
__queueReq.Send(__req);

OutputSum __output = new OutputSum();
try
{
  string __id = __req.Id;
  Message __msg = __queueResp.ReceiveByCorrelationId(__id,     TimeSpan.FromSeconds(__timeout));
  __output = (OutputSum) __msg.Body;
}
finally
{
  MessageQueue.Delete(__pathResp);
}

return __output.output;
}

People who do understand Dutch can read the details of this in my thesis (see http://www.bartdesmet.net/download/thesis/), chapter 10.

Schematic overview

The following picture illustrates the overall mechanism of mqdl.exe:

The mqdl.exe tool has three modi as I explained:

export mode, takes an assembly (DLL) and generates the MQDL contract (XML) using reflection
svcman mode, takes the MQDL contract (XML) and generates monitors and a service manager, both in C# using pretty large XSLT transforms
proxy mode, takes the MQDL contract (XML) and generates a proxy class in C# using another XSLT transform

Give me some code

You can take a look at this (experimental) implementation over here. Feel free to use it if it looks useful to you, suggestions and additions are welcome (but keep in mind the Indigo story that's due to be released soon).

Longhorn milestones ... some dates

bart — Tue, 08 Mar 2005 02:56:00 GMT

I've been talking today at UGent about the .NET Framework and the future of the Microsoft (.NET) platform for the upcoming years (SQL Server 2005, .NET Framework v2.0, VS 2005, Team System, Longhorn, Orcas, ASP.NET v2.0, ClickOnce, DSI, etc). Although I didn't mention the current schedule for Longhorn, I'd like to share it over here (source: various places on the internet):

M9 - March 2005 (that's this month, yes!)
Beta 1 - May 2005
Beta 2 - October 2005
RC0 (quite exceptional to have an RC0) - February 2006
RC1 - April 2006
RTM - May 24, 2006

Fingers crossed ...

Today there's also the news that (long-awaited and "subject to various delays") WinFS might come to XP too (see http://www.microsoft-watch.com/article2/0,1995,1772619,00.asp?kc=MWRSS02129TX1K0000535), as Avalon and Indigo do (both to XP and W2K3). In the end this would mean that the WinFX core and kernel enhancements are the key features that will be unique to Longhorn. Nevertheless, I'm burning with impatience for LH to come...

Updates

There seems to be some confusion about RTM and GA (general availability). May 24th is currently known as the RTM date, which means that the launch (GA) should be a couple of months later, somewhere in the (late) summer of 2006.
For what WinFS is concerned, the last plan I heard about is that the beta would come at the time LH Client is released.
LH Server (and possibly LH Client SP1) are planned for the first half of 2007. Maybe WinFS RTM will be synch'ed with this release too (since the real full WinFS story only makes sense with support on both client and server).

A night of sweet XAML dreams with Avalon

bart — Thu, 23 Dec 2004 13:14:00 GMT

Going to bed now after a crazy night full of WinFX, XAML and Avalon using the CTP of November 2004 running on both Windows Server 2003 and Windows XP SP2. It's oh so cool that I couldn't even stop this night. Starting with plain vanilla XAML (eXtensible Application Markup Language) for UI definition in Avalon over to custom XAML on my own classes. All this with .NET Framework v2.0 beta (new number to remember: v2.0.40607) and Visual Studio 2005 beta 1. Unfortunately, the VS2005 December 2004 CTP seems to be incompatible with the Avalon CTP (version number of the .NET Framework with the new VS CTP is v2.0.41202), so I had to install, remove and install again but luckily the system wasn't screwed by this (everything still runs fine). Seems that the MSIs are already of an excellent quality.