Archive

Posts Tagged ‘C#’

GOF Series: Episode #3 [The Singleton - aka the devils work]

October 9th, 2008 Simon Segal No comments

Next in the series we continue with the creational group of patterns and move onto the singleton pattern.

What is the singleton and how does it work?

  • A globally available single instance of class, where only one single instance can exist at any given point in time.
  • Maintains and instantiates itself across multiple threads at any given time.
  • All public methods and members are accessed via the single instance.
  • Constructed instances cannot be created outside of the singleton class. This is achieved by using a private constructor only accessible from the singleton itself.

Is the singleton the devils work?

  • They promote tight coupling between objects and components – consumers know exactly where to get a copy of their collaborating classes.
    • Remember that coupling is a measure of dependencies.
  • Cannot be easily substituted ala dependency injection.
  • Inherently lack scale.
  • Difficult to unit test.

Singleton example in C#

Given this singleton below:

public sealed class Singleton
{
    static Singleton _instance = null;
    static readonly object _padlock = new object();
    static List<int> _ThreadSafeCounterList = new List<int>();
    static readonly Guid _instanceId = Guid.NewGuid();

    private Singleton() { }

    public static Singleton Instance
    {
        get
        {
            lock (_padlock)
            {
                if (_instance == null)
                {
                    _instance = new Singleton();
                }
                return _instance;
            }
        }
    }

    public List<int> ThreadSafeCounterList
    {
        get
        {
            lock (_padlock)
            {
                return Singleton._ThreadSafeCounterList;
            }
        }
        set
        {
            lock (_padlock)
            {
                Singleton._ThreadSafeCounterList = value;
            }
        }
    }

    public Guid ID
    {
        get { return _instanceId; }
    }
}

and this program:

class Program
{
    static AutoResetEvent evt;

    static void Main(string[] args)
    {
        Console.WriteLine(“Enter a key to begin the singleton workers”);
        Console.ReadLine();
        const int countup = 2000;
        for (int x = 0; x <= countup; x++)
        {
            //new up a background worker
            BackgroundWorker bg = new BackgroundWorker();
            //wire up the work handler delegate to do the computation
            bg.DoWork += new DoWorkEventHandler(bg_DoWork);
            //when x has reach the upper boundary of the loop
            //subscribe to the event that fires when the
            //work handler has completed its work (will subscribe)
            //to the last thread dialled up via the bg worker
            if (x == countup)
            {
                //last bg worker thread - subscribed to its 
                //completed event to signal an end
                bg.RunWorkerCompleted +=
                    new RunWorkerCompletedEventHandler(bg_RunWorkerCompleted);
            }
            //run up a thread
            bg.RunWorkerAsync(x);
        }
        //wait until blocks the current thread (main thread)
        //until signaled - will pause here..
        evt = new AutoResetEvent(false);
        evt.WaitOne();
    }

    static void bg_RunWorkerCompleted(object sender,
        RunWorkerCompletedEventArgs e)
    {
        Console.WriteLine(“Start reading of the list in “ +
            “the order the items were written.”);
        Console.ReadLine();

        //loop the list of integers and print 
        //them in order they were inserted
        for (int i = 0; i < Singleton.Instance.
            ThreadSafeCounterList.Count; i++)
        {
            Console.WriteLine(Singleton.Instance.
                ThreadSafeCounterList[i].ToString());
        }

        //signal to the user the total processing figures
        Console.WriteLine(“TOTAL added to Thread safe List is : “ +
            Singleton.Instance.ThreadSafeCounterList.Count.ToString());

        //pause for user entry
        Console.ReadLine();

        //signal to the main thread to continue
        //and therefore exit.
        evt.Set();
    }

    static void bg_DoWork(object sender, DoWorkEventArgs e)
    {
        System.Threading.Thread.Sleep(10);

        Console.WriteLine(“Added “ + e.Argument.ToString() +
            ” by thread with hashcode “ + Thread.CurrentThread.GetHashCode() +
            “\tto instance ID:\t” + Singleton.Instance.ID.ToString());

        //add the integer to the list
        Singleton.Instance.ThreadSafeCounterList.Add((int)e.Argument);

        //give back a time slice so the other threads get a piece
        System.Threading.Thread.Sleep(10);

        //write out to the window when you find 
        //the same integer that was just added
        //because a time slice was given back to
        //the OS task scheduler, another thread
        //may be processing, so the found integer 
        //and thread hashcode will not necessarily
        //print in order.
        Console.WriteLine(“Found “ + Singleton.Instance.
            ThreadSafeCounterList.Find(
            delegate(int findInt)
            {
                if (findInt == (int)e.Argument)
                {
                    return true;
                }
                else
                {
                    return false;
                }
            }).ToString()
                + ” by thread with hashcode “ +
                Thread.CurrentThread.GetHashCode() +
                “\tto instance ID:\t” +
                Singleton.Instance.ID.ToString());
    }
}

We have a program that will count up to 2,000 and use a thread safe singleton to insert and read those 2,000 counters. Each iteration will fire off a new background worker thread to do the work of both the insert and read of each of the iterations counter. Whilst this program serves no useful function, it represents an example of a thread safe singleton where data is shared and accessed in both read and volatile writes concurrently.

Next up

Next up in the series will the prototype pattern and I am going to try and include it with an IronRuby example as well as in C#. The entire Patterns series code and PowerPoint presentation can be downloaded here.

Share/Save/Bookmark

Categories: C#, Design Patterns Tags: ,

Lesser coupled WCF Services.

August 15th, 2008 Simon Segal 1 comment

I hear people talk about how WCF or ASMX services are inherently loosely coupled by default out of the box, whether they use HTTP or TCP or any old transport available for that matter. “Just use Web Services or WCF and you get loose coupling for free” they say. So the story of temporal coupling using Web Services is well known now as are the many issues with platform coupling and indeed the solution below does not address platform coupling directly as it leans on XML to manage serialization. The coupling that I am interested in addressing here is that created by dependency to the ubiquitous proxy or WSDL contract. Lets examine this a little more closely.

The Reason:

The most common method for a consumer of a service (WCF / ASMX) to maintain and manage the resolution to it’s interface is WSDL. This requires each consumer having to carry around the contract with it, forever in it’s servitude to understand the mysteries that lie at the boundary of it’s faithful service. So without this proxy I don’t know what message to send and where to send it (and yes I know you don’t have to use WSDL and you can proxy off the interface - but that leaves us still coupled to the service interface). Coupling is a measure of dependency and because our consumer depends rather heavily on the service interface or WSDL it is quite squarely coupled to it. Version control with WSDL isn’t trivial to manage and so the coupling story gets worse when we want to change the interface. WCF does provide some methods to relax this versioning problem by ignoring parts of messages from old contract consumers however this is still not adequate. We also hit the coupling ceiling when you consider that all my endpoints are bound to particular message types with respect to the message sent and returned. More recently prescribed guidance has suggested a pattern in sending more coarsely grained messages that are less chatty by utilising complex types or [DataContract] in the world of WCF, but unfortunately I’m still coupled to the schema of these big messages.

How to address this?

One way of addressing this would be to provide blandly consistent service interfaces that never change and utilise the most generic of all messages - System.ServiceModel.Channels.Message, otherwise known as an untyped message in WCF. We can bundle up our rich business messages (as serialized POCO’s) and send them in the body of the untyped message. Once having arrived at our bland endpoint, we could check for an appropriate handler of this message (POCO). What’s required is to de-serialize XML out of the body of our untyped message and back into a POCO and then have the handler manage the message for which it was built to handle. Below is a really rudimentary way of thinking about this interaction.

messageAndHandler

The Code for sending the message could look something like this:

public void ExampleSend()
{
    //create a channel to the BUS
    EndpointAddress address =
        new EndpointAddress
            (“net.tcp://localhost:9002/Org.ItResults.” +
            “Soa.Hosts.HumanResourceServiceSvc”);

    NetTcpBinding binding =
        new NetTcpBinding
        { SendTimeout = new TimeSpan(0, 10, 0) };
    ChannelFactory<IEndpoint> factory =
        new ChannelFactory<IEndpoint>(binding, address);
    IEndpoint channel = factory.CreateChannel();

    TestMessage tm = new TestMessage(Guid.NewGuid());

    XmlReader reader = Serializator.SerializeMessage(tm);

    //Create the Message to put on the BUS
    //with the serialized data contract embedded
    //into its body and the target method
    //at the endpoint for the BUS channel
    Message msg = Message.CreateMessage(
        binding.MessageVersion,
        “urn:BaseEndpoint-Recieve”, reader);

    //send the message onto the BUS
    channel.Recieve(msg);

    //Close the comms
    factory.Close();
}

On the receiving side the code might look like the following:

public void TestReceive(Message msg)
{
    //NOTE: the types of T handlers could be
    //loaded into the host process

    //a library where an appropriate
    //set of handler might be located
    const string path =
        @”D:\LocalWorking\ITResults\” +
        “Org.ItResults.ServiceOriented.System” +
        @”\Org.ItResults.Soa.Poc.Messages\bin\debug“;

    //get all the types in the path that have
    //generic args. They may be Message Handlers
    //for messages (the generic args)
    List<Type> generics =
        GenericTypeReader
        .InterfaceTypesInPathWithGenericArgs(path);

    List<object> unravelled = new List<object>();

    //for each type found with a generic arg
    //try to deserialize the body of the message
    //in the endpoints method arg into each
    //generic type found
    generics.ForEach(t =>
        unravelled.Add
        (Serializator.DeserializeMessage(msg, t)));

    unravelled.ForEach(delegate(object o)
    {
        //find a handler for the deserialized object
        IMessageHandler handler;
        handler = GenericTypeReader.
            FindHandlerForMessageTypeInPath<IMessageHandler>
            (path, o.GetType());

        handler.GetType().
            GetMethod(”HandleMessage”)
            .Invoke(handler,
            new[] { o });
    });
}

Where a message handler looks something like:

public interface IMessageHandler { }

public interface IResponseMessageHandler<T> :
    IMessageHandler where T : IMessage
{
    /// <summary>
    /// Handles messages that are not required
    /// to return a response.
    /// </summary>
    /// <param name=”message”>
    /// The type of message to handle.
    /// </param>
    Message HandleMessage(T message);
}

public interface IOneWayMessageHandler<T> :
    IMessageHandler where T : IMessage
{
    /// <summary>
    /// Handles messages that are not required
    /// to return a response.
    /// </summary>
    /// <param name=”message”>
    /// The type of message to handle.
    /// </param>
    void HandleMessage(T message);
}

And finally the message and it’s concrete handler might look like this:

public interface IMessage
{
    Guid ID { get; }
}

[XmlRoot(Namespace = "Org.ItResults.com.au")]
public class TestMessage : IMessage
{
    private Guid _id;
    private string _nameofMEssage;

    #region IMessage Members

    [XmlElement(Order = 1)]
    public Guid ID
    {
        get { return _id; }
        set { _id = value; }
    }

    #endregion

    public TestMessage() { }

    public TestMessage(Guid id)
    {
        _id = id;
    }

    [XmlElement(Order = 2)]
    public string NameOfMessage
    {
        get { return “Test Message”; }
        set { _nameofMEssage = value; }
    }
}

public class TestHandler :
    IOneWayMessageHandler<TestMessage>
{
    #region IMessageHandler Members

    public void HandleMessage(TestMessage message)
    {
        Console.WriteLine(“The Test Message name was “ +
            “{0} and it’s ID is {1}”,
            message.NameOfMessage, message.ID);
    }

    #endregion
}

It’s evident from the code that I should be able to drop message handlers (contained in libraries) in a library folder close to my service and give that service the ability to handle messages defined by handlers in those libraries. This is very similar to how nServiceBus deals with declaring how a service defines what messages it handles and I have adapted the idea to fit with WCF, which affords us the following:

  1. Decouple from any WSDL proxy and it’s associated versioning issues.
  2. Proxies are now managed via a consistent interface less likely to ever require change, as messages pass in the body of an untyped message.
  3. Release newer versions of message handlers to services without rebuilding against them or  any newly refreshed proxy definition.
  4. Freedom from carrying around WSDL.
  5. No coupling to API CRUD styled service endpoints.
    • This is where the style of using Handlers becomes important. Developers are not required to understand an RPC styled API that describes how to affect the state of underlying data, which more often than not is the legacy found in default Web Service Architecture.

It’s also worth noting that the code above does not list how to deal with return messages contained in the untyped message body of an IResponseMessageHandler<T>. This would be managed in a similar fashion to discovering the correct handlers at the service endpoint, by attempting to deserialize messages into available handlers.

Something that is missing in this example is the ability to do publish and subscribe. Some of my colleagues and I are working on a proof of concept framework that extends the concept demonstrated in this post and will include how to handle Pub / Sub (no duplex channels), endpoint discovery via PNRP and durable messaging using queues (Service Broker Queues).

Share/Save/Bookmark

If I could have just one thing!

August 10th, 2008 Simon Segal No comments

Again today came across many a situation begging for some Spec# pre and post spec_thumbcondition verification; alas the wait continues. I will attempt to do my part in pushing the call to have Spec# rolled into C# ASAP (V 4.0 pretty please Anders?). Greg Young started this push to have Spec# taken seriously as something that we want to see in the language soon and have it move its way out of research and into product roadmap. Here again is the bumper sticker that Greg made available.

Share/Save/Bookmark

Categories: C#, Spec# Tags: ,
Creative Commons Attribution-ShareAlike 2.5 Australia
Creative Commons Attribution-ShareAlike 2.5 Australia