共用方式為

Lifecycle of a Channel

  • 發行項

In the original post introducing ICommunicationObject I claimed that the abstract base class helps you run our required state machine.  Today, I'll explain exactly how CommunicationObject enforces the state machine model.  Combined with the post yesterday showing how to use the state machine to protect your code, we'll be ready to start looking deeper into the WCF channel object model in the future.  Once you master the state machine, learning how to build a custom channel is just a matter of learning how to implement more interfaces.  All of the basic object management concepts are going to be the same no matter what kind of channel you're dealing with.

CommunicationObject implements all of the events and methods associated with the state machine in ICommunicationObject.  Behind the scenes, CommunicationObject keeps the state machine updated and calls into your code to hook into state transitions.  Each operation splits into three methods so that you can do work before, during, or after the operation.  After a state transition, the base class sends out an event notification that the transition occurred.

Let's say that someone calls Open() on your object.  Here's how CommunicationObject handles the call:

  1. The base class implementation validates whether it's permissible to open the object now and throws an exception if you were in the wrong state.
  2. The state machine moves to the Opening state.
  3. Your OnOpening() method gets called to let you do some work before the operation.
  4. The base class fires the Opening event to notify listeners of the state transition.
  5. Your OnOpen() method gets called to let you perform the operation.
  6. Your OnOpened() method gets called to let you do some work after the operation.
  7. The state machine moves to the Opened state.
  8. The base class fires the Opened event to notify listeners of the state transition.

Most of the time you'll just put code OnOpen() unless you have to do some setup work.

Important note: The code to fire the events is in the base class implementations of OnOpening() and OnOpened().  You must call the base class methods at some point or else!  We try to check that you've done the right thing and throw an error if something looks fishy.

Closing works exactly the same way except you'll get a call to either OnClose() or OnAbort() depending on how the close operation was invoked.  I've got a post coming up that will demystify the differences between closing and aborting.  Faulting is even simpler because it's a one transition operation.  After a fault is detected, the state machine moves to the Faulted state, your OnFaulted() method is called, and finally the Faulted event is sent.

Next time: Thinking about Timeout and Retry Policy

Comments

  • Anonymous
    February 24, 2006
    Yesterday, I introduced the ICommunicationObject state machine and mentioned that we had a base class...
  • Anonymous
    August 15, 2006
    It's hard to believe that I introduced the ICommunicationObject state machine six months ago but never...