Flow of Messages, Part 2

Continuing from last time, we were looking at the flow of a message during a service call. We left off at the point where the service client had just dropped a message off to the network. Today, we're going to follow that message up through the completion of the service call. This is essentially going through the process of a one-way call.

Right from the start, we hit a fork in the road. Either the service is running (because it's always-on or something has previously told it to turn on) or we need to start the service in response to the message arriving. Let's assume that we need to activate the service because everything afterwards is the same for the two paths. For each protocol that we want to activate on, the transport has a corresponding component that serves as the activation listener. The job of the activation listener is to listen for the first message destined for a service, start that service up, and then get out of the way. The details of activation aren't going to be used in this series, which is fortunate because it takes a long time to explain the process. Instead, we're going to jump ahead to the point where the service has come up. The activation listener does not actually process any messages. Once the service has been started, the first message goes to the transport just like any other message.

The message then passes through the transport and protocol channels, undoing any of the processing that was performed on the client side. At the bottom of the channel stack, the transport channel takes the stream of bytes used for network transmission and converts that stream back into an XML message. The message passes up through the stack of protocol channels, which again apply any number of transformations along the way.

At the top of the channel stack, we need something to reverse the process that the proxy performed to translate our method call into an XML message. This component is called the dispatcher because it needs to pull messages out of the pipeline and route each message to the appropriate service call. Back on the client side, the proxy took information about the service method being invoked and encoded that information into the message as addressing headers. The dispatcher looks at those addressing headers, finds the appropriate method to invoke, converts the payload of the message back into method parameters, and finally calls the method on the service instance.

We have a quick break coming up, but when this series next continues, we'll take a look at some of the extensibility points we passed through during the service call.

Next time: The Pool is Full

Comments

• Anonymous
  March 05, 2007
  In the channel development series so far, we've just been looking at channels. I've already mentioned

• 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