How to add WCF client Message Header without using Operation Context

Introduction

In WCF when we want to set message header for service by WCF client, we normally use operation scope. Following is the example of one such implementation.

using (OperationContextScope scope = new OperationContextScope(wcfClient.InnerChannel))
      {
        MessageHeader header
          = MessageHeader.CreateHeader(
          "Service-Bound-CustomHeader",
          "http://Microsoft.WCF.Documentation",
          "Custom Happy Value."
          );
        OperationContext.Current.OutgoingMessageHeaders.Add(header);

        // Making calls.
        Console.WriteLine("Enter the greeting to send: ");
        string greeting = Console.ReadLine();

        //Console.ReadLine();
        header = MessageHeader.CreateHeader(
            "Service-Bound-OneWayHeader",
            "http://Microsoft.WCF.Documentation",
            "Different Happy Value."
          );
        OperationContext.Current.OutgoingMessageHeaders.Add(header);

(NOTE: The above code example has been taken from msdn at: http://msdn.microsoft.com/en-us/library/system.servicemodel.operationcontextscope.aspx)

This works great in simple scenarios where you can use the OperationContextScope object. But what if you cannot use the OperationContext or OperationContextScope object?

Detail

I recently ran into a scenario where I was using FactoryChannel to create client channel and send that object to sub classes that were using the channel. The problem came when I had to add a common message header to all the client proxies which were using my base class. I could have used the same code scheme that is mentioned in the above example. But the problem arose when I found out that there were hundreds of  client proxy(s) that needed to be changed. That solution was not feasible given time constraints and the mere fact that if I need to change anything again on the newly created headers then I had do to repeat the same process again for all the client proxies.

I had to find a solution where I can add the message headers at one place and do not have to change on all the client proxies. Luckily, I was using a service proxy base class which was initiating a channel for all the client proxies. Naturally, I just needed to update that proxy with a message header that I need. But that is where I hit the major road block.

The problem is that conventionally message headers are added using the OperationContextScope object. But on my base class there is no OperationContext object available to me.

The solution to the above mentioned issue comes by using good old Endpoint Behavior object.

I created an endpoint behavior where I declared a public property which carried my custom message header. On the service proxy base I declared an object for the newly created Endpoint Behavior and then added that to channel factory object.

Here is how it looked after the code modification:

   factory = new ChannelFactory();
   
    var endpointBehavior = new CustomBehaviorAttribute ();
    // Setting LoginToken as custom message header
    endpointBehavior.CustomMessageHeader = "Value";
    factory.Endpoint.Behaviors.Add(endpointBehavior);
   return factory.CreateChannel();

Here is the declaration of my behavior attribute:

    /// 

    /// An attribute that extends runtime behavior of operations so that user can
    /// attach the custom message inspector to client/service application.
    /// 

    [AttributeUsage(AttributeTargets.All)]     public class CustomBehaviorAttribute : Attribute, IEndpointBehavior     {

        #region IEndpointBehavior Members
        public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
        {
            return;
        }
 
        public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
        {

            clientRuntime.MessageInspectors.Add(new MessageInspector(behavior.CustomMessageHeader));
        }
 
        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
        {
            return;
        }
 
        public void Validate(ServiceEndpoint endpoint)
        {
            return;
        }
        #endregion
 
        #region Public Members
        /// 

        /// Gets or sets the custom message header.
        /// 

        ///          /// The custom message header.         ///          public string CustomMessageHeader { get; set; }         
#endregion Public Members

The above code snippet shows how can you add a header without using OperationContext or OperationContextScope objects.

Introduction to Single Page Applications

What is Single Page Application?

Rich and responsive web application that fits in a single page providing a fluid interface by loading all necessary code with a single page load.

Key Features of Single Page Application

Fits on a single page

Maintains navigation history and deep linking

Persisting important state on the client

Fully* loads on initial page load

Using Asynchronous downloads of features if needed.

Architecture

Here is the complete slide deck

Slide Deck

Interaction Design between user and the operating system - Part 1

Designing any kind of interaction between two entities is always an imperfect science. It gets easier if the two entities are predictable systems. If we set out to define the design interaction between two highly predictable systems then it will not take very long to do so. The complexity increases with the increase in the unpredictably of entities. This can be express in following equation:

Design Complexity ∞ 1/Predictability of entities

As we get more and more predictable entities, we get better framework to define design interactions.

In light of aforementioned theory, it is obvious to assume that designing interaction between user and operating system will be highly difficult feat. Why is that? The answer is pretty simple. Unpredictability of the user. There is a limit to how unpredictable the operating system can be but there is no limit to user unpredictability. This proves the very first statement i.e "Designing any kind of interaction between two entities is always an imperfect science".

So what are our options?

This blog and subsequent parts of this blog will try to address options, design patterns and thoughts that will help us create a better interaction design between a user and operating system.

User action dependability
Most of the operating systems that I know of are reaction in nature when it comes to user interaction. They react to each user action interdependently. For example, user opens window, closes a window, deletes a file, creates a file, etc. These all are independent actions. This is fine to some extent. We as users are used to this design of interaction. In this case the operating system is fulfilling the role of server of user actions. This is one way to look at the interaction. This works for most of us. Why this works is that we have developed a mindset that is accustomed to this pattern.

There is another way to look at it. The other way is where the operating system understands each action and tries to understand what user is thinking and trying to achieve. With each action the operating system adapts and defines the interaction framework. The operating system also adds its smartness along the way.

To better understand this let us take an example. I am writing this blog in some software. At the same time my mail client application is open. The mail client application is usually kept open all day. I keep receiving emails and the mail client keep notifying me as emails arrive. During writing this blog, I click the close button on my mail client. The mail client closes. Why the operating system closed it? Because the operating system is servicing my action. The operating system did not process the correct intention of my action. The operating system just fulfilled my action. What if the operating system does not closes the mail application right away. Instead it just minimizes it or notifies me that this is middle of the day and am I sure to close this application. Think about this for a minute. What we are looking at? Are we looking at highly adaptive and intelligent operating system? Yes, from objectively thinking it probably is. But my point here is not to have highly intelligent operating system. My point here is that operating system defines interaction framework based on some logic.