Shy Cohen's WebLog : Indigo

Getting on the SOA Bandwagon

ShyCohen — Mon, 24 Jul 2006 22:33:00 GMT

Ron Jacobs just posted the ARCast we recorded at TechEd Israel titled "Getting on the SOA bandwagon". Check it out on Channel9 or SkyScrapr.

It’s playtime! The WCF Virtual Labs are now online!

ShyCohen — Wed, 22 Feb 2006 06:43:00 GMT

If you haven’t played around with WCF because you didn’t want to install stuff on your machine you’re now out of excuses :-)

MSDN Virtual Labs for WCF are up on http://msdn.microsoft.com/virtuallabs/wcf/. These are the same labs we use in the training we deliver here at MS.

These labs walk you through “the WCF fundamentals” and “reliable / transacted messaging”. They are done using a Terminal Service session to a virtual machine installed with WCF, Visual Studio 2005, and everything else that you need to play, so you don’t have to install anything on your local machine (well, if you don't have it installed already you would need to install the ActiveX control that lets you conect to the TS session ;-).

Have fun!

Reliable Messaging demystified

ShyCohen — Mon, 20 Feb 2006 22:05:00 GMT

Recently I hear many questions about Reliable Messaging in WCF. In fact, I just had an IM chat with Clemens which resulted in this blog entry. I want to expand on his comments with a little more of the insight I got being a past owner for this feature.

The first thing we should clear out is terminology - Reliable Messaging means a lot of things to a lot of people so I like to use 2 separate terms when it comes to WCF features: Reliable Sessions and Queued Messaging.

Reliable Sessions provide the equivalent of “TCP at the SOAP level” and give you exactly-once, in-order message delivery. TCP is reliable like that too (at the packet level), but only hop-to-hop. If all you ever have is a single, un-bridged connection on a super-reliable network then reliable sessions don’t give you much. However, this is rarely the case both inside the corporate network and obviously across the Internet. Reliable sessions overcome failures at the transport level (e.g. wireless network connection blinks in and out), at the transport intermediary level (e.g. a web proxy drops the request or the response), and at the SOAP intermediary level (e.g. a SOAP router blinks or drops your message due to load issues). Without this feature it is very hard to write “connected” applications that work correctly in the face of communication errors. Reliable sessions also track the connection liveliness and let you free resources on the server side if the client “goes away” for longer than a given amount of time. On top of all of that, reliable sessions give you network-adaptive congestion control which will adjust the rate of sending to the network’s ability to handle the communication load, and end-to-end flow control which will adapt the rate of sending to the server’s ability to handle the communication load. Both these features result in better network utilization. Reliable sessions are a wonderful thing for the “connected” case where both sides are up and running at the same time and allows you to use request-reply operations and alike safely.

Queued Messaging is all about having a buffer between the client and the service that decouples them in terms of availability (they don’t have to be up at the same time), processing capacity (the service only needs to be able to process the average, not peak client load), and allows wonderful things like offline support for the client (i.e. send messages to the server when it is unreachable or even not running), load-sharing and load-curve-smoothing on the service side, etc. Obviously, when you don’t know when the other side is going to process your message you don’t assume connectivity and would never block a thread waiting for the service to respond. In WCF terms this means that all your operations would be one-way.

Reliable sessions are implemented using the WS-ReliableMessaging protocol. This protocol is yet another misnamed WS-* protocol, as it actually only deals with the reliability of the transfer and says nothing about durability, delivery acknowledgments, TTL for a message, long running sessions where a particular message is lost forever, etc. Currently, there is no active work going on to develop an interoperable Queued Messaging specification, but I expect that we will get to it in the near future.

With no WS-* interoperable spec for Queued Messaging we have implemented this capability on top of the known and trusted infrastructure provided by MSMQ. We did this in a way that gives the programmer all the benefits and capabilities of working in the WCF programming model combined with the durability and transacted capture/delivery features of MSMQ. In addition, and some would say more importantly, it gives the administrator the familiar MSMQ management and administration features. In an enterprise environment one can’t just “stick” a new durable resource into the application model without getting the IT folks to buy off on it – they need to manage this resource, including doing backups, troubleshooting it when something goes wring, etc., and building this feature on a familiar V3 product like MSMQ (V4 in Windows Vista), with well documented tools and practices, is a boon for the IT guys.

We do hear what folks are saying though, and we are actively working on a set of features that will allow Queued Messaging implementations to leverage WCF’s WS-ReliableMessaging implementation. With this feature set you’d be able to “bring your own durable store” and have an interoperable Queued Messaging channel that fits nicely and naturally into the WCF architecture. In fact, if we do the job right then at the programming model level one would see no difference between the MSMQ cannel and the BYODS channel (not including configuration and error handling of course). We also expect to, at the least, have a reference Queued Messaging implementation that uses these features and illustrates the model. All I can say with any level of certainty at this point though is that we expect this to be available some time after v1 ships.

The November CTP of WinFX is online

ShyCohen — Fri, 18 Nov 2005 18:42:54 GMT

Get it while it's fresh :-)

WinFX Runtime Components:	http://www.microsoft.com/downloads/details.aspx?FamilyId=E5376297-DA10-4FC3-967D-38C96F767FC4&displaylang=en
WinFX SDK:	http://www.microsoft.com/downloads/details.aspx?FamilyId=0A118D5F-21E7-4A3E-82D9-F30C6CE3F63D&displaylang=en
VS2005 Extensions for WinFX Runtime Components:	http://www.microsoft.com/downloads/details.aspx?FamilyId=2202A637-2B68-40C0-B3AE-9235D60F42C4&displaylang=en
VS2005 Extensions for Windows WorkFlow:	http://www.microsoft.com/downloads/details.aspx?FamilyId=589E23DD-503E-4179-9858-D080C669F8B9&displaylang=en
WinFX RC Nov CTP "Readme":	http://msdn.microsoft.com/windowsvista/relnotes/winfxnovctp/default.aspx

PDC demo #2 - Transactions

ShyCohen — Tue, 18 Oct 2005 01:48:00 GMT

After a short delay, here’s the second one. This demo illustrated how transaction flowing works in Windows Communication Foundation.

PDC 2005

ShyCohen — Thu, 14 Jul 2005 15:31:00 GMT

Indigo is going to have a substential presence in this year's PDC. There are 21 sessions discussing Indigo, out of which 13 are "pure Indigo" presentations given by Indigo team members. Here's the abstract for my talk:

Indigo: Writing Reliable and Transacted Distributed Applications

What do you do when your network connection breaks half-way through a request? How do you synchronize state changes across different Web services? How do you overcome a system crash without losing important messages? Indigo provides simple and powerful reliability mechanisms that allow you to easily address these types of network and application issues. Take an in-depth look at reliable sessions, queues, and distributed transactions, and how these technologies are used to achieve reliable, transacted communication.

If you have any requests or suggestions for this talk, or if there's other Indigo stuff that you'd like to hear about, please let me know.

For the complete list of PDC sessions, see http://commnet.microsoftpdc.com/content/sessions.aspx. For a complere list of the Indigo talks, just search for Indigo across all tracks.

Indigo CTP Now Available to General Public!

ShyCohen — Sun, 27 Mar 2005 23:02:00 GMT

Get your Avalon and Indigo Community Technology Preview here.

We're Out!

ShyCohen — Wed, 16 Mar 2005 23:25:00 GMT

Woohoo! The fisrt Community Technical Preview (CTP) of Indigo is now available for download at http://msdn.microsoft.com/longhorn/ (currently restricted to MSDN subscribers, but will open up to all soon).

The documentation and samples for Indigo are part of the WinFX SDK. The SDK is available through the CTP package, and also available online at http://winfx.msdn.microsoft.com.

Have fun!

Indigo Day sessions available online!

ShyCohen — Mon, 14 Mar 2005 02:49:00 GMT

Our friends at Fawcette Technical Publications posted the Indigo Day sessions recorded at VSLive 2005 in San Francisco.

http://www.ftponline.com/special/indigo/

There's over 7 hours of material here, ranging from basic Indigo programming to migration and interoperability with shipping technologies – check it out!

Oh, and pay special attention to minute 13 of my presentation :)

Fun with Duplex contracts

ShyCohen — Fri, 11 Feb 2005 05:59:00 GMT

Well, Clemens threw the glove so here goes :-)

The first thing that we define is the contracts

using System.ServiceModel;

namespace DuplexSample.Interfaces

{

[ServiceContract]

interface IClientSide

{

[OperationContract(IsOneWay = true)]

void WriteString(string s);

}

[ServiceContract(CallbackContract = typeof(IClientSide))]

interface IServiceSide

{

[OperationContract(IsOneWay = true)]

void Rotate(string s);

}

The client side contract defines a single method that the client needs to implement on his side (WriteString). The service side defines a single method that the service must implement (Rotate). The ServiceContract attribute on the IServiceSide interface defines this to be a duplex contract, and requires that the caller would implement the IClientSide interface.

Both methods are “one-way” methods. None-one-way methods might throw, so even when you call a void method you need to wait for it to complete before you can say that the operation was successful. One-way methods are true “fire and forget”, and do not wait for the operation to complete.

Ok, now for the client implementation:

using System;

using System.ServiceModel;

using DuplexSample.Interfaces;

namespace DuplexClient

{

class ClientImpl : IClientSide

{

public void WriteString(string s)

{

Console.WriteLine(s);

}

class Program

{

static void Main(string[] args)

{

IServiceSide service;

ServiceSite mySite = new ServiceSite(new ClientImpl());

service = ChannelFactory.CreateDuplexChannel<IServiceSide>(mySite, "Default Client Config");

Console.WriteLine("Enter strings to rotate, or hit [Enter] to end.");

string str = " ";

while (str.Length > 0)

{

str = Console.ReadLine();

if (str.Length!=0) service.Rotate(str);

}

We first define a class that implements the client contract (ClientImpl). When the service operation WriteString is called, the implementation writes the string to the screen.

The Main method defines a local variable that would be used to reference the service (service) as well as a service site for the incoming calls (mySite). The service site is the object that would dispatch the calls made by the server to the instance of the client-side-contract-implementation-object that was passed in (the ClientImpl object created there).

Next, we create a duplex channel to the service, passing in the service site we created. The samples that Clemens and Bruce created hard-coded the server address and binding information into the app. Guys, come on, you know better J. Where’s the address and binding in this sample? They’re in the application configuration file. We’ll look at the configuration file format a little later.

We then go into a loop where we call the service with the string entered by the user. For each time we call the service, it would call us back multiple times on the duplex interface, resulting in the following output:

Enter strings to rotate, or hit [Enter] to end.

Indigo Rocks!

!Indigo Rocks

s!Indigo Rock

ks!Indigo Roc

cks!Indigo Ro

ocks!Indigo R

Rocks!Indigo

o Rocks!Indig

go Rocks!Indi

igo Rocks!Ind

digo Rocks!In

ndigo Rocks!I

Indigo Rocks!

Now, let’s look at the service side.

using System;

using System.Text;

using System.ServiceModel;

using DuplexSample.Interfaces;

namespace DuplexService

{

class ServiceImpl : IServiceSide

{

public void Rotate(string s)

{

IClientSide client = OperationContext.Current.GetCallbackChannel<IClientSide>();

char[] chars = s.ToCharArray();

int len = chars.Length;

for (int i = 0; i < len; i++)

{

StringBuilder sb = new StringBuilder(len);

sb.Append(chars, len - i, i);

sb.Append(chars, 0, len - i);

client.WriteString(sb.ToString());

}

The service implementation class (ServiceImpl) implements the service-side contract (IServiceSide). This contract defines a single method (Rotate). The first thing we do here is to get the callback interface to the client. This interface is exposed through the GetCallbackChannel method on the static member GetCallbackChannel of the class OperationContext, and it is set for us by Indigo before the infrastructure code calls into our implementation. We then have a loop where we rotate the string and call the client interface for each variation.

The code that hosts this service is:

using System;

using System.ServiceModel;

namespace DuplexService

{

class Program

{

static void Main(string[] args)

{

ServiceHost<ServiceImpl> host = new ServiceHost<ServiceImpl>(new ServiceImpl());

host.Open();

Console.WriteLine("Service is ready. Press [Enter] to exit.");

Console.ReadLine();

}

In this code, we first create the host (again, the endpoints are defined in the service’s configuration file) and then open it. We then wait for clients to connect and call the service method, or for the user to hit Enter.

That’s it for the code. Now, let’s look at the configuration files:

Let’s start with the service’s configuration:

<?xml version="1.0" encoding="utf-8"?>

<system.serviceModel>

<endpoint contractType="DuplexSample.Interfaces.IServiceSide, DuplexService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"

address="net.tcp://localhost:50210/DuplexService"

bindingSectionName="customBinding"

bindingConfiguration="ServiceCustomBinding"

</service>

</services>

</binding>

</customBinding>

</bindings>

</system.serviceModel>

</configuration>

A single application can host many services. Those services are defined inside the <services> element. In our case, we have a single service. Each service can have one or more endpoints, defined using the <endpoint .../> element. This element defines the 3 elements of the endpoint (Address, Binding, and Contract) as follows:

o The address we use is a TCP address. The URI consists of the schema (net.tcp), host + port, and the path for the service. A single application can listen on multiple paths on the same TCP port.

o The contract type is a strongly named CLR type, consisting of the fully qualified interface name, the assembly in which it is defines, and the assembly version, culture, and public key token.

o The binding, referred to by type (in our case, a custom binding) and the name of the specific configuration section for that type (ServiceCustomBinding). For each type we can have multiple named configurations, and the name here helps distinguish between them.

The next section is the binding section. Each binding type has a section; in our case there’s a single binding type (we’re using a custom binding that we define ourselves (customBinding) and therefore a there’s a single binding section inside the bindings element. This custom binding has a single named configuration section that says that we’re only going to use TCP. In future samples I’ll show how to create more interesting custom bindings.

Now to the client configuration file:

<?xml version="1.0" encoding="utf-8" ?>

<system.serviceModel>

<endpoint address="net.tcp://localhost:50210/DuplexService"

bindingSectionName="customBinding"

bindingConfiguration="ClientCustomBinding"

configurationName="Default Client Config"

contractType="DuplexSample.Interfaces.IServiceSide, DuplexClient, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">

</endpoint>

</client>

</binding>

</customBinding>

</bindings>

</system.serviceModel>

</configuration>

The client side defines one endpoint that allows it to connect to the service. It specifies the same address as the service, the same contract (this one is compiled into a different assembly since the client and service do not share implementation – see if you can spot the difference). The binding type and configuration are defined in the same way they are defined on the service, and the interesting thing remaining is the configuration name. This is the name that was passed in when we called the ChannelFactory.CreateDuplexChannel method on the client. The client configuration file can contain many endpoints, but the client only picks one (by name) and uses it.

That’s it! Clemens, bring on the next challenge J