Flow of Messages, Part 1

In the channel development series so far, we've just been looking at channels. I've already mentioned that you should consider using other extensibility points instead of channels when that's cost-effective. However, it has so far been left a mystery what those other extensibility points are. This series is not about documenting extensibility points other than channels. I will give a brief outline though just so you have some keywords to go off researching on your own.

For illustration, I'm going to demonstrate the basic pattern of messaging that takes place during a service call. Today's part of the illustration covers the client side of that messaging. We will end today with a message being put on the network. The next part of the illustration covers the server side of messaging. Even though most service calls are two-way, I'm only going to examine this single direction. I'll let you imagine the exact same process happening in the opposite direction. After we go through the message flow, I'll list off some of the extensibility points that the message passed along the way.

Here is the client side portion of the message flow. I have a single web service off running somewhere else in the world. The exact details of how we connect to that web service are unimportant. I have previously gotten a contract that describes some service operations and directions for contacting the service. Using this contract, I have designed a client application that wants to invoke some of the service operations.

I don't want to have to worry about messaging when invoking a web service operation. Method calls are easy to understand for someone that has any programming background. Networking is something that is much harder to understand. I would like for the message exchange between the client application and the web service to look like a method call. The proxy is a combination of dynamically-generated and framework code that gives service methods the illusion of being ordinary methods. We have taken the service contract and instantiated a type that has all of the service operations exposed as type members. Invoking one of the generated type members using a method call triggers the framework to send a message to the web service.

The remaining processing on the client side is to push out that message. The message will pass down through the stack of protocol channels, having any number of transformations applied to it. At the bottom of the channel stack, the transport channel takes the message and converts it for network transmission. Typically, this means running an encoding process to turn the message into a stream of bytes. The transport channel then sends the network transmission off to the network. If everything has gone well, the network transmission will be picked up by the web service and somehow turned back into a method call. That is the process that we'll look at next time.

Next time: Flow of Messages, Part 2

Comments

• Anonymous
  March 02, 2007
  The code yesterday was meant to motivate a side-discussion on how faults get generated and handled between

• Anonymous
  March 08, 2007
  We've been looking at the flow of messages ( Part 1 and Part 2 ), but have never stopped along the way