Design History of Communication Objects

A common question about why so many classes implement ICommunicationObject requires a bit of a side trip into design history. The role of ICommunicationObject is to provide a common state machine across many different objects. That state machine has no notion of sending or receiving data; sending and receiving are aspects of another concept called channels. Instead, the state machine encompasses six notions about how an object must be used:

• That an object, once created, must be configured to a particular purpose
• That a configured object must be brought into operation
• That an operational object must perform its allotted task
• That an operational object, having performed its allotted task, must be brought into retirement
• That a formerly operational object has been retired
• That an object has failed its purpose and cannot be used again

These notions correspond to six states called Created, Opening, Opened, Closing, Closed, and Faulted. Each of these states has a mechanism in the state machine for transition and notification.

Finally, there are the base objects that implement the state machine, collections of these objects (associated, for example, by a common channel factory or channel listener), collections of the collections, and so on. A service in many ways is just a collection of collections that splay eventually down into many operational channels that send and receive messages. When you have a collection of communication objects, it is convenient to work with them as a unit so that you have a single object running through the same state machine that reflects its contained objects. The same can be said about collections of collections. Since the state machine is embodied by ICommunicationObject, you can see why everything implements it.

Next time: Configuring TCP Activation from the Command Line