.NET Matters

Using VHD snapshots with Windows Azure Virtual Machines

noreply@blogger.com (Unknown) — Sat, 04 Jan 2014 19:55:00 +0000

I often use Windows Azure Virtual Machines to create a test environment. A requirement of such a test environment is to be able to quickly take one or more snapshots of a virtual machine and selectively restore a given snapshot later. Unfortunately Windows Azure (IaaS) does not provide this functionality out of the box.
This is where I use the CloudXplorer tool.

1. Take a snapshot of the disk (while the VM is stopped)

2. Start the VM, make changes and perform tests. When you have completed the tests, shutdown the VM.
3. Use CloudXplorer to promote the snapshot after breaking the disk lease.

4. Use CloudXplorer to (re)acquire the lease.

You can now restart the VM in the state where the snapshot was taken.

Using Data Transfer Objects in Layered Architecture

noreply@blogger.com (Unknown) — Wed, 06 Oct 2010 21:57:00 +0000

1 Introduction

A layered application consists of three principal layers: presentation, domain and data source.

The presentation layer is about the interaction between the user and the application, while the data source layer for most applications consists of a relational database and the logic needed to read and write data in the database.

The domain layer contains the domain logic, also referred to as business logic. This is the work the application needs to do. It is important to notice that each layer has its own responsibilities and that communication between the layers must occur via well-defined interfaces.

The domain layer can be subdivided into a Domain Model and Service sub-layer depending on the complexity of the application and the patterns used to implement the domain logic.

The domain logic can use the following patterns:

· Transaction Script

· Domain Model

· Table Module

2 Introducing Data Transfer Object

DTO is an enterprise design pattern to implement the interface between the presentation and the domain layer.

Using DTO’s assures that the domain model (and possibly the domain logic) is not exposed to the presentation layer. Although the use of this pattern is certainly not advocated by Microsoft .NET tooling and Microsoft example code, it is imho a necessary pattern to achieve the needed separation between the presentation and the domain layer.

The discussion whether or not to use DTO’s is out of the scope of this document as there are pro’s and con’s for each approach.

Advantages of DTO’s:

· Isolation of logic

· SOA requirement

· Reduced number of remote calls

· Improved performance

· Testablility

· Deterministic content

Disadvantages of DTO’s:

· Possible class explosion

· Additional computing

· Additional code effort

Most of the disadvantages can be resolved by code generation of the DTO’s and the associated mappers between the DTO’s and the domain entities. Additional computing is in most remote scenario’s (presentation layer is remote) not an issue because serialization of more complex domain entities will require more computing than serializing the simple DTO structures.

How to use DTO’s efficiently is the subject of this document.

3 Packaging and dependencies

Following figure shows the packages and dependencies in a layered application.

The domain model is the heart of the application. It contains the domain entities and the repository interface definitions. By defining the repository interfaces, the domain model describes the operations it requires to bring entities in memory and persist entities to the database. The business logic is either contained in the domain model (DDD – approach) or in the services when using the Transaction Script pattern. The domain model has no dependencies on any other part of the architecture and is technology agnostic.

The service layer and the data layer have a dependency on the domain model. The data layer because it needs to implement the repositories and handle the persistence of the domain entities. The service layer because it is responsible for orchestrating the business logic.

By defining the repository interfaces in the domain model, the service layer becomes independent of the data layer and is as such independent of the used storage technology. To instantiate the repositories, the service layer uses the inversion of control pattern, eventually accompanied by dependency injection (IoC/DI).

Because the presentation layer should by ignorant of the domain model, it communicates with the service layer using the Data Transfer Object pattern. Since the DTO’s could be shared between the presentation and the service layer (in a .NET only scenario), the DTO’s should not know about the domain entities. In order to map data between the DTO’s and the domain model, mapper or DTO factories must be created in the service layer (because the service layer is the only one that knows both the domain entities and the DTO’s.

4 Sending data to the Presentation Layer

Data is delivered to the client in the form of a DTO. This is simplified representation of part of the domain model and is designed to fit the display needs of the client.

If the service would simply use the domain model to retrieve the data and map the needed data from the retrieved entity object graph, way too much data would probably have been retrieved from the database, transported and brought into memory on the application server. We might solve this problem by making the domain model and data layer dependent on the DTOs. But doing this will make it impossible to share the DTOs with the client and will also introduce pollution in the domain model.

Following technique illustrates how we can use LINQ to solve this problem and still retrieve exactly what we need from the database.

4.1 Simple scenario

We have a database with two tables (Nursery and NurseryPlant) having a one-to-many relation (a Nursery has one or more Plants).

In the domain model this results in two entities (Nursery and NurseryPlant).

When the client needs to display an overview of the Nurseries, it receives a ‘NurseryOverviewResponse’ message containing one or more ‘NurseryOverviewDto’ instances.

The NurseryOverviewDto contains the NurseryId, Usage and Year properties from the Nursery entity and the ForDisplay property which is a calculated property on the DTO (concatenating the other three properties).

The NurseryOverviewDto is produced by code generation and looks as follows:

The same code generator also produced the ‘NurseryOverviewDtoFactory’ type in the service layer.

This type contains mapping function between the Nursery entity and the DTO. It also contains an ‘ExpressionSelector’ which is an LINQ expression that can be used to perform projection in the DTO.

On the repository, following method is defined:

When called from the service implementation, this results in the following query on the database

4.2 Retrieving DTO with master-detail relation

In this scenario the DTO has a master-detail relationship (Nursery – NurseryPlant).

In order to do the correct projection we need (linked) factories for both types.

Remark that the factory for the master set contains a ‘Queryable<T>’ of the detail set.

The repository is the following:

This results in one query retrieving exactly the needed data from the database.

Conclusion

Using LINQ expressions in the service layer allows us to efficiently populate DTO’s and keep the DTO’s independent from any other component on the server side.

In a next post I will explain how the code generation is implemented.

When WCF blows the whistle (Part1)

noreply@blogger.com (Unknown) — Sun, 05 Sep 2010 18:31:00 +0000

By default WCF will blow the whistle on applications when they exchange data (by calling a service) that exceeds certain limits imposed by the WCF runtime. These are limits regarding the size of messages, the complexity of the message (such as the number of objects in the object graph), the size of elements in the message and other characteristics of the data exchanged. Exceeding this limits result in the breaking the communication and reporting of this situation as an exception, either on the client or the service side.

WCF is a defensive system, meaning that the limits imposed on the exchanged messaged are deliberately chosen ‘ as small as reasonably’ possible. This is (imho) a healthy approach, especially in the context of public exposed services.

This means that if you run against these limits, the following questions should arise first:

Is this really what I intend to achieve?
Can/should I change the design in order to fit into the default limits?
What are the risks if I decide to relax the limitations?

In this series of posts I will discuss the various WCF limits and the ways to change the default settings.

Limit 1. ReaderQuotas

Data contracts are a potential entry point for hackers. One of the types of attacks are ‘Denial of Service’ attacks in which a user sends a vast amount of data to the service so that the service spends most of its time simply trying to receive and read the data and performance suffers accordingly. In order to avoid this type of attacks it is advisable to define messages that cannot contain nested data structures, arrays or collections of indeterminate length. The limits on the message structure are imposed by ‘ReaderQuotas’.

‘ReaderQuotas’ are defined per binding, as such they can be different for each service endpoint. The ‘ReaderQuotas’ are checked by the receiving side (being either the server or the client).

Following quota can be defined:

MaxArrayLength: maximum number of bytes in an array. (default=16384)
MaxStringContentLength: maximum length of a string type member in the message. (default=8192)
MaxDepth: maximum level of nesting structures in the message. (default=32)
MaxBytesPerRead: maximum number of bytes per read. This quota limits the number of bytes that can be consumed by the reader during a single call to the Read() method. This quota is an approximation, because transformations in the encoding layer happen before this quota is applied. This quota is closely tied to the number of bytes received on the wire at the transport level, but its purpose is to control the quantity of data we receive for each read. In practice, it is used to limit the size of start tags. Because the entire start tag must be buffered to be processed (attributes uniqueness must be verified), the size must be limited to mitigate DOS attacks.(default=4096)
MaxNameTableCharCount: maximum number of characters allowed in a table name. This quota limits the total number of characters in strings that are atomized in the NameTable for the reader. When strings are atomized they are inserted into a NameTable and never removed. This can cause the buildup of large amounts of character data in a NameTable. This quota places a limit on how much data can be buffered in the reader's NameTable. (default=16384)

Internally ‘ReaderQuotas’ apply to the XmlDictionaryReader type used internally to manipulate the soap message.

Configuring ReaderQuotas

In configuration file:

        1: <system.serviceModel>

       2:   <bindings>

       3:     <basicHttpBinding>

       4:       <binding>

       5:         <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"

       6:               maxBytesPerRead="4096" maxNameTableCharCount="16384" />

       7:       </binding>

       8:     </basicHttpBinding>

       9:   </bindings>

In code:

Setting the ReaderQuotas in code is not that straightforward because the ReaderQuotas property is not defined on the Binding base class. A little reflection can help as shown in the next example:

       1: using (ServiceHost host = new ServiceHost(typeof(TestService), new Uri("http://localhost:80/TestService"), new Uri("net.tcp://localhost:100/TestService")))

       2: {

       3:     host.AddDefaultEndpoints();

       4:     foreach (ServiceEndpoint endpoint in host.Description.Endpoints)

       5:     {

       6:         PropertyInfo propInfo = endpoint.Binding.GetType().GetProperty("ReaderQuotas");

       7:         if (propInfo != null)

       8:         {

       9:             XmlDictionaryReaderQuotas qoutas = propInfo.GetGetMethod().Invoke(endpoint.Binding, null) as XmlDictionaryReaderQuotas;

      10:             qoutas.MaxBytesPerRead = 10000; // set individual value

      11:         }

      12:     }

      13:     host.Open();

Another option is to derive your own binding type form the WCF provided bindings and tune the ‘ReaderQuotas’ to the desired value.

       1: //-----------------------------------------------------------------------

       2: // <copyright file="MaximizedNetTcpBinding.cs" company="RealDolmen N.V.">

       3: //     Copyright (c) RealDolmen. All rights reserved.

       4: // </copyright>

       5: // <author>Luc Van Keer</author>

       6: //-----------------------------------------------------------------------

       7: namespace Bromo.TaskChannel

       8: {

       9:     using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Text;

    using System.ServiceModel;

    using System.Xml;

  

    public class MaximizedNetTcpBinding : NetTcpBinding

    {

        #region Constructors

  

        public MaximizedNetTcpBinding()

            : base()

        {

            this.MaximizeSettings();

        }

  

        public MaximizedNetTcpBinding(SecurityMode securityMode)

            : base(securityMode)

        {

            this.MaximizeSettings();

        }

  

        public MaximizedNetTcpBinding(string configurationName)

            : base(configurationName)

        {

            this.MaximizeSettings();

        }

  

        public MaximizedNetTcpBinding(SecurityMode securityMode, bool reliableSessionEnabled)

            : base(securityMode, reliableSessionEnabled)

        {

            this.MaximizeSettings();

        }

  

  

        #endregion

  

        #region Properties

        #endregion

  

        #region Private Methods

  

        /// <summary>

        /// Maximizes the settings.

        /// </summary>

        private void MaximizeSettings()

        {

            this.ReaderQuotas = XmlDictionaryReaderQuotas.Max;

        }

  

        #endregion

    }

}

Conclusion

The ‘ReaderQuotas’ default values are reasonable values for most services. If you decide to change the defaults, there must be a good reason to do so and the first approach should be to question the design and try to make it operate with the default values.

Following test illustrates the danger of augmenting for example the ‘maxDepth’ value (which at first view might look like a harmless change). This test sends the ‘Employee’ message to the service. The Employee message contains a ‘Manager’ reference to another employee instance. Following graph shows the processor load when performing 500 operation call with a delay of 10msec between each call, sending either a normal 2 level ‘Employee’ structure and a abnormal 1000 level structure.

Singleton implementations in .NET

noreply@blogger.com (Unknown) — Thu, 26 Aug 2010 08:54:00 +0000

Technorati Tags: Design Patterns

The ‘gof design patterns’ book describes the intent of a singleton as follows: ‘Ensure a class has only one instance, and provide a global point of access to it’.
For a .NET application this means that there is one instance of the singleton type per application domain.
Following code snippet show a ‘generic’ (C++) implementation for the pattern:

   1: class Singleton {   2: public:   3:     static Singleton* Instance();   4: protected:   5:     Singleton();   6: private:   7:     static Singleton* _instance;   8: };   9: Singleton* Singleton::_instance = 0;  10:    11: Singleton* Singleton::Instance () {  12:     if (_instance == 0) {  13:         _instance = new Singleton;  14:     }  15:     return _instance;  16: }

** It should be noted that this implementation is not thread-safe. Calling the ‘Instance()’ method from multiple threads can result in the creation of more than one instance of the ‘Singleton’ class.

When creating an .NET implementation of the singleton pattern, the following functionality is either mandatory or desired:

Functionality	MoSCoW	Description
One instance per application domain	M	Ensures that there is only one instance of the type per application domain.
Thread-safe construction	M	Construction of the singleton type instance in a multithreaded/multicore environment must also result into one instance per application domain, regardless of any race conditions or compiler/processor optimizations.
Lazy initialization	S	The actual creation of the type instance is triggered by the first access to the singleton.
Initialization status indication	C	The possibility to test if the singleton instance has already been created (of course without creating it).
Re-initialization after exception	C	The possibility to re-trigger the creation of the singleton, should an exception have occurred during the previous attempt to create the instance of the singleton.

Basically we have there are two styles to implement the singleton pattern, we can rely on type initializers (aka. static constructors) or instantiate the singleton instance via the ‘Instance’ property getter (like the sample above does).

Common Features in all approaches

Following features are common to all approaches:

The instance constructor is private. (see Singleton Pattern and inheritance)
The singleton type is sealed. (see Singleton Pattern and inheritance)
The instance is stored in a private readonly static field.

Approach 1: Using the .NET Type constructor

In .NET a type constructor (also known as static constructor or class constructor or type initializer) is used to set the initial state of a type. You define a type constructor just like an instance constructor with the following exceptions:

It must be marked static.
It is automatically marked as private by the compiler.
It cannot have parameters.

Furthermore, the .NET CLR guarantees that a type constructor is only executed once for each type loaded in the application domain, and that the execution is thread-safe.

Following code shows the implementation:

   1: public sealed class SingletonApproach1   2: {   3:     private readonly static SingletonApproach1 instance;   4:     5:     public static SingletonApproach1 Instance   6:     {   7:         get   8:         {   9:             return instance;  10:         }  11:     }  12:    13:     static SingletonApproach1()  14:     {  15:         instance = new SingletonApproach1();  16:     }  17:    18:     private SingletonApproach1() { }  19:    20:     public int P1 { get; set; }  21: }

Example code using the singleton:

   1: class Program   2: {   3:     static void Main(string[] args)   4:     {   5:         const Int32 iterations = 1000 * 1000 * 1000;   6:         PerfTest1(iterations);   7:         PerfTest2(iterations);   8:         PerfTest1(iterations);   9:         Console.ReadLine();  10:     }  11:     static void PerfTest1(Int32 iterations)  12:     {  13:         Stopwatch sw = Stopwatch.StartNew();  14:         for (Int32 x = 0; x < iterations; x++)  15:         {  16:             SingletonApproach1.Instance.P1 = 1;  17:         }  18:         Console.WriteLine("PerfTest1: {0}", sw.Elapsed);  19:     }  20:     static void PerfTest2(Int32 iterations)  21:     {  22:         Stopwatch sw = Stopwatch.StartNew();  23:         for (Int32 x = 0; x < iterations; x++)  24:         {  25:             SingletonApproach1.Instance.P1 = 1;  26:         }  27:         Console.WriteLine("PerfTest2: {0}", sw.Elapsed);  28:     }  29: }

Remark that we do not (and cannot) call the type constructor. The call to the type constructor is automatically issued by the JIT-compiler when compiling the first method that accesses the type (either by creating an instance or accessing a static method, property or field).
In the example this happens when compiling the ‘PerfTest1’ method because it accesses the static ‘Instance’ property of the type.

Disadvantages of this approach

There is a performance penalty in the first method accessing the singleton because the JIT-compiler injects the call to the type initializer in this method. See the difference in execution time between ‘PerfTest1’ and ‘PerfTest2’ while both methods perform the same work.
PerfTest1: 00:00:03.1461604 PerfTest2: 00:00:00.8905847 PerfTest1: 00:00:03.1043356
Exception Handling. When an exception occurs in the instance constructor this will make the type unusable and results in a ‘TypeInitializationException’ in the application code. Each subsequent use of the type will result in the same exception, and there is no way to re-execute the type initializer.
You cannot test if the singleton has already been initialized, since adding this test would lead to instantiating the singleton. This is caused by the fact that accessing a static field (other than ‘Instance’ in this case) will also trigger the execution of the type initializer.

Score

Functionality	MoSCoW	Score
One instance per application domain	M
Thread-safe construction	M
Lazy initialization	S	(When no other statics beside ‘Instance’ exist)
Initialization status indication	C
Re-initialization after exception	C

Approach 2: Using the .NET field initializer

   1: public sealed class SingletonApproach2   2: {   3:     private readonly static SingletonApproach2 instance = new SingletonApproach2();   4:     5:     public static SingletonApproach2 Instance   6:     {   7:         get   8:         {   9:             return instance;  10:         }  11:     }  12:    13:     private SingletonApproach2() { }  14:    15:     public int P1 { get; set; }  16: }

In this approach we replaced the type initializer with a field initializer. If we examine the generated IL-code for both approaches, it becomes clear that when using the field initializer approach, the compiler has generated a type initializer with a content that is exactly the same as the one we manually added in the type initializer approach.

The difference between the two implementations is in the metadata attributes of the singleton class. When we use a field initializer the class is decorated with the ‘beforefieldInit’ attribute, where this attribute is missing when we explicitly write the type initializer method.
The ‘beforefieldInit’ attribute defines the approach the JIT-compiler will use when it issues the code to call the type initializer.
Simply stated, when the ‘beforefieldInit’ attribute is present, the JIT-compiler has the freedom to choose when to invoke the type initializer as long as it is invoked before a reference to a static field or instance of the type is used. In other words the JIT-compiler is allowed to use optimizations when it comes to calling the type initializer. On the other hand, when the ‘beforefieldInit’ attribute is not present, the call to the type initializer will be placed exactly before the code accessing the static field or instance of the type. We call these behaviors the ‘beforefieldInit’ and the ‘Precise’ behavior.
The CLI specfication states the following regarding ‘beforefieldInit’:

A type may have a type-initializer method, or not.
A type may be specified as having a relaxed semantic for its type-initializer method (for convenience below, we call this relaxed semantic BeforeFieldInit)
If marked BeforeFieldInit then the type's initializer method is executed at, or sometime before, first access to any static field defined for that type
If not marked BeforeFieldInit then that type's initializer method is executed at (i.e., is triggered by):
- first access to any static or instance field of that type, or
- first invocation of any static, instance or virtual method of that type

Whether or not the JIT-compiler is allowed to insert optimizations results in a performance difference between the two approaches. Generally speaking the ‘beforefieldInit’ approach result in better performance. Following code sample shows the results. Keep in mind that performance measurements can be misleading and must always be interpreted in the total context of the application. In this sample we executed the method calling the type initializer a billion times in the absence of any other application code, with the sole purpose to highlight the performance difference between the two approaches. In real life application the differences will not be that large, maybe even imperceptible.

Disadvantages of this approach

This approach has the same disadvantages as the ‘approach 1’, except for the performance penalty in the first method calling the singleton.
Performance results are:
PerfTest1: 00:00:00.9240271 PerfTest2: 00:00:00.9049068 PerfTest1: 00:00:00.8854748

This solution is not as lazy as it seems. Because the JIT-compiler has a greater degree of freedom it can place the call to the type initializer anywhere in the calling before the access to the singleton. Following example illustrates this behavior. You can see that the singleton is already created before the write to the console in the calling method.

   1: public sealed class SingletonApproach2   2: {   3:     private readonly static SingletonApproach2 instance = new SingletonApproach2();   4:     5:     public static SingletonApproach2 Instance   6:     {   7:         get   8:         {   9:             return instance;  10:         }  11:     }  12:    13:     private SingletonApproach2() { Console.WriteLine("Singleton created"); }  14:    15:     public int P1 { get; set; }  16: }  17: class Program  18: {  19:     static void Main(string[] args)  20:     {  21:         Do();  22:         Console.ReadLine();  23:     }  24:     static void Do()  25:     {  26:         Console.WriteLine("About to access the singleton");  27:         SingletonApproach2.Instance.P1 = 1;  28:     }  29: }

Singleton created
About to access the singleton

Score

Functionality	MoSCoW	Score
One instance per application domain	M
Thread-safe construction	M
Lazy initialization	S	(When no other statics beside ‘Instance’ exist) Initialization may occur earlier in the method.
Initialization status indication	C
Re-initialization after exception	C

Approach 3: Using a simple lock

In order to implement the ‘Status Indication’ and ‘Re-initialization after exception’ features, we have to leave the type initializer approach and switch to the classical implementation where the singleton instance is constructed in the ‘Instance’ getter.

   1: public sealed class SingletonApproach3   2: {   3:     private static SingletonApproach3 instance;   4:     private readonly static object synclock = new object();   5:     6:     public static SingletonApproach3 Instance   7:     {   8:         get   9:         {  10:             lock (synclock)  11:             {  12:                 if (instance == null)  13:                 {  14:                     instance = new SingletonApproach3();  15:                 }  16:                 return instance;  17:             }  18:         }  19:     }  20:    21:     public static bool IsInitialized  22:     {  23:         get  24:         {  25:             lock (synclock)  26:             {  27:                 return instance != null;  28:             }  29:         }  30:     }  31:    32:     private SingletonApproach3() { }  33:    34:     public int P1 { get; set; }  35: }

This is a thread-safe implementation since the lock allows only one thread at a time to have access to the ‘Instance’ getter method and takes care of the ‘memory barrier’ problem because all reads occur after acquiring the lock and all writes occur before releasing the lock.

Disadvantages of this approach

There is a performance penalty caused by acquiring the lock on each access to the singleton instance.
PerfTest1: 00:01:03.3850922
In a multi-thread application, getting a reference to the singleton instance is serialized, which may lead to scaling issues.

Score

Functionality	MoSCoW	Score
One instance per application domain	M
Thread-safe construction	M
Lazy initialization	S
Initialization status indication	C
Re-initialization after exception	C

Approach 4: Using lock with double check

Next code sample show the ‘double check’ implementation. There is a lot of discussion about the thread safety of this construction, due to possible compiler and multicore optimizations. Choosing for the solution to declare the instance field as ‘volatile’ ensures a thread-safe implementation in .NET.

   1: public sealed class SingletonApproach4   2: {   3:     private static volatile SingletonApproach4 instance;   4:     private readonly static object synclock = new object();   5:     6:     public static SingletonApproach4 Instance   7:     {   8:         get   9:         {  10:             if (instance == null)  11:             {  12:                 lock (synclock)  13:                 {  14:                     if (instance == null)  15:                     {  16:                         instance = new SingletonApproach4();  17:                     }  18:                 }  19:             }  20:             return instance;  21:         }  22:     }  23:    24:     public static bool IsInitialized  25:     {  26:         get  27:         {  28:             lock (synclock)  29:             {  30:                 return instance != null;  31:             }  32:         }  33:     }  34:    35:     private SingletonApproach4() { }  36:    37:     public int P1 { get; set; }  38: }

Disadvantages of this approach

Although the performance is better than the simple lock version, it is still inferior to all other approaches.
PerfTest1: 00:00:14.6866434

Score

Functionality	MoSCoW	Score
One instance per application domain	M
Thread-safe construction	M
Lazy initialization	S
Initialization status indication	C
Re-initialization after exception	C

Approach 5: Using .NET field initializer with true laziness

This approach is a variation of approach 2 where we deal with the lazy initialization. Using a nested class, true laziness is achieved.

   1: public sealed class SingletonApproach5   2: {   3:     public static SingletonApproach5 Instance   4:     {   5:         get   6:         {   7:             return Nested.instance;   8:         }   9:     }  10:    11:     private SingletonApproach5() {}  12:    13:     class Nested  14:     {  15:         internal readonly static SingletonApproach5 instance = new SingletonApproach5();  16:         static Nested() { }  17:     }  18:    19:     public int P1 { get; set; }  20: }

Score

Functionality	MoSCoW	Score
One instance per application domain	M
Thread-safe construction	M
Lazy initialization	S
Initialization status indication	C
Re-initialization after exception	C

Performance

Following table list the time elapsed to access the singleton one billion times with the first access instantiating the singleton. For approaches using the type initializer the time is shown for instantiating and non-instantiating methods.

Approach	Instantiating method	Non-instantiating method
1	00:00:03.1461604	00:00:00.8905847
2	00:00:00.9240271	00:00:00.9049068
3	00:01:03.3850922
4	00:00:14.6866434
5	00:00:00.9222056	00:00:00.8969283

Remark: Singleton Pattern and static class

So far, so good, but why didn’t we implement the singleton as a static class? A static class also offers the singleton behavior where it comes to the use of type initializers and thread safety while executing the type initializer. The main reason why a static class is not preferable as a singleton pattern implementation is that it severely limits OO capabilities because it cannot be used as a parameter in a method call and it cannot implement an interface.
Following code will not compile due to the limitations mentioned above:

   1: public interface IMySingleton   2: {   3:     int P1 { get; set; }   4: }   5:     6: public static class Singleton1 : IMySingleton   7: {   8:     public static int P1 { get; set; }   9: }  10:    11: public static class Singleton2 : IMySingleton  12: {  13:     public static int P1 { get; set; }  14: }  15:    16: class Program  17: {  18:     static void Main(string[] args)  19:     {  20:         DoSomethingWithASingleton(Singleton1);  21:     }  22:    23:     static void DoSomethingWithASingleton(IMySingleton s)  24:     {  25:         Console.WriteLine(s.P1);  26:     }  27: }

Remark: Singleton Pattern and inheritance

You may have noticed that the instance constructor of the singleton type is private so that application code cannot use the constructor to create instances of the singleton (which would violate the singleton pattern). Actually this makes the singleton type ‘not inheritable’ even without marking it ‘sealed’. We might ask the question whether the visibility of the instance constructor should be changed to ‘protected’ to allow inheritance.
It is my opinion that it should not be changed (as such not allowing inheritance) for the following reasons:

If inheritance is allowed, the derived type can add extra instance constructor(s) allowing application code to directly create instances of the singleton type. This is a violation of the singleton pattern (and of the ‘Liskov substitution principle’).
If you can derive ‘once’, you can also derive ‘twice’ (and more). This can result in multiple instances of the base singleton class, which is once more a violation of the singleton pattern. Following code sample illustrates this situation.

   1: public class MySingletonBeforeInit   2: {   3:     private readonly static MySingletonBeforeInit instance = new MySingletonBeforeInit();   4:     public static MySingletonBeforeInit Current   5:     {   6:         get { return instance; }   7:     }   8:     public Guid P1 { get; set; }   9:     protected MySingletonBeforeInit()  10:     {  11:         Console.WriteLine("Creating MySingletonBeforeInit");  12:         this.P1 = Guid.NewGuid();  13:     }  14: }  15: public class MySingletonDerived1 : MySingletonBeforeInit  16: {  17:     private readonly static MySingletonBeforeInit instance = new MySingletonDerived1();  18:     public new static MySingletonBeforeInit Current  19:     {  20:         get { return instance; }  21:     }  22:     protected MySingletonDerived1() { Console.WriteLine("Creating MySingletonDerived1"); }  23: }  24: public class MySingletonDerived2 : MySingletonBeforeInit  25: {  26:     private readonly static MySingletonBeforeInit instance = new MySingletonDerived2();  27:     public new static MySingletonBeforeInit Current  28:     {  29:         get { return instance; }  30:     }  31:     protected MySingletonDerived2() { Console.WriteLine("Creating MySingletonDerived2"); }  32: }  33: class Program  34: {  35:     static void Main(string[] args)  36:     {  37:         Console.WriteLine(MySingletonDerived1.Current.P1.ToString());  38:         Console.WriteLine(MySingletonDerived2.Current.P1.ToString());  39:         Console.WriteLine(MySingletonDerived1.Current.P1.ToString());  40:         Console.WriteLine(MySingletonDerived2.Current.P1.ToString());  41:         Console.ReadLine();  42:     }  43: }

Creating MySingletonBeforeInit
Creating MySingletonDerived1
Creating MySingletonBeforeInit
Creating MySingletonDerived2
07ed6401-131a-45b6-ae57-be6a685c00d9
5bef7ecb-3ccd-4101-a377-e50b93c3af87
07ed6401-131a-45b6-ae57-be6a685c00d9
5bef7ecb-3ccd-4101-a377-e50b93c3af87

Conclusion

Unless you need to test for initialization of the singleton, or need to ability to re-initialize after an exception (both are rarely needed in my opinion), Approach 2 is the preferred choice. It offers the best mix of functionality, performance and simplicity.
Keep in mind that in this article, I only talk about thread safety in the context of instantiating the singleton. When you use the singleton in a multi-threaded environment, it is still the programmer’s responsibility to write thread-safe implementation of the other methods and properties of the singleton type.

Guide to Claims-based Identity and Access Control

noreply@blogger.com (Unknown) — Sat, 06 Mar 2010 09:31:00 +0000

This is a comprehensive guide explaining the use of claims for authentication and authorization in the most common scenarios. It provides a good introduction for those looking to apply claims-based identity in applications.

Find the guide her

Find the code samples here

Using differencing disks with VirtualBox

noreply@blogger.com (Unknown) — Sat, 23 Jan 2010 13:20:00 +0000

When evaluating new software, you often need to setup an isolated environment using virtual machines. This can be a lot of work when you have to install the machines from scratch. To avoid this you can setup a base configuration (for instance a machine which already has SQL server and Visual Studio installed) and copy the hard disk when creating a new instance. The downside of this method is that you waste a lot of disk space. To avoid this most virtualization products such as VmWare, VirtualBox and Virtual PC use differencing disks. These are disks that store only the different sectors in regard to their base or parent disk.

Following procedure shows how to use differencing disks with VirtualBox:

Build the base system.
After installing the operating system, apply all necessary update and install the VirtualBox additions.
Release the base disk
Since the base disk will become ‘read-only’, it must be detached form all virtual machines.
Make the base disk immutable
Use the following command:
VBoxManage modifyhd <disk file> --type immutable
Create a new system from the base disk
When creating the new system attach the immutable base disk. A new differencing disk will be created.
Turn off the autoreset feature of the differencing disk
This is necessary since the content of a differencing disk will be destroyed when the virtual machine is started.
Use the following command:
VBoxManage modifyhd <differencing disk file> --autoreset false

If you want to start a new hierarchy from a differencing disk, you can use the ‘VBoxManage clonehd’ command to build the new base disk. Following figure shows an example:

Using SQL Attribute Store with Active Directory Federation Services 2.0 (aka Geneva Server)

noreply@blogger.com (Unknown) — Wed, 30 Dec 2009 18:02:00 +0000

Active Directory Federation Services 2.0, also known as Geneva Server, can act as a Security Token Service (STS) for a claims-aware application (called Relying Party in this context) by providing a security token containing the claims demanded by the application.
To produce the claims, ADFS 2.0 uses the Active Directory as attribute store and retrieves attributes about identity of the authenticating client.

You can imagine cases where all the information needed to build the claims cannot be found in the Active Directory.

An application might for example request an age verification of the caller. This can be done by letting the STS retrieve the birthday of caller from an external database and producing a producing a ‘AdultVerification’ claim containing true or false.

Step by Step implementation

1. Define the external attribute store in the Geneva Server

The external attribute store is a SQL database containing a table BDates. Since we are using integrated security and the database is accessed by the Geneva service, do not forget to configure access for the service account (Network Service in this case)

2. Define a new claim type for the AdultVerification claim

3. Add a custom rule to the relying party to construct the AdultVerification claim

4. Specify the expected claims in the web.config of the relying party

At this point you can access the AdultVerfication claim in the application code and implement access checks as shown in the following code sample.
A better and more flexible way is to write a custom claims authorization manager module so that you can configure the access in the configuration file of the application.

5. Write a custom claims authorization manager

6. Configure the application to protect pages

Add the ClaimsAuthorization module to the http modules of system.web and system.webserver

Configure the custom authorization manager to protect the SecretPage.aspx

Test the application. When an underage user navigates to the SecretPage, following error is returned

In a next post I will describe how to build a custom attribute provider, so that external attributes can be retrieved using any custom mechanism (for example via a web service).

Using message credentials when calling a SOAP service from Silverlight 4

noreply@blogger.com (Unknown) — Mon, 14 Dec 2009 00:16:00 +0000

Silverlight 4 beta introduces the possibility to pass user credential (username/password) to SOAP services via the request headers. This is important when you enable a SOAP service for crossdomain access.

Shortly summarized, this is how it works:

Add an https binding to the service and configure this binding to use transport security with message credentials.
Use SLsvcutil.exe to generate the SL proxy.
Add the username and password to the ClientCredentials.UserName property of the proxy.
Remember to allow https request headers in the crossdomain policy file.

Example:

The question arises if this way of working is safe enough in true business environments.
When we look at a network trace we can notice that the username/password information is protected because of we are using https. When we enable the WCF message tracing on the server, we see that the values of the username and password have been silently removed from the trace.

To see what is really in the headers of the SOAP message, I added a message inspector to the WCF service. This inspector logs the content of the headers to a trace file. This is the content of the trace file:

Notice that the values for the username and the password are visible in plain text.
The problem is that anyone (with bad intentions) who has access to the configuration file of the service can add such an inspector to the service.
This combined with the fact that server credentials are negociated via the transport protocol (https), you can find yourself in a possible unsafe situation.

Using full WS bindings with username/password is a whole different story. In this case the server must present a well known certificate that is specified in the client configuration. This way you are sure to be talking to the right party. Secondly the username/password is encrypted and can only be decrypted by the receiving service.
The same message inspection on a full WS service gives following trace file:

Conclusion: Although you can use username/password authentication to SOAP services in SL4, be aware that it uses TransportWithMessageCredentials under the covers and that the username/password information is not encrypted at message level. This opens possibilities for "man in the middle" and "phishing" attacts to reveal usernames and passwords.

Windows and .NET Idenity and Security "Back to basics" series. Part 1.

noreply@blogger.com (Unknown) — Sat, 24 Oct 2009 19:23:00 +0000

Motivation

I decided to start writing a series of articles on the identity and security mechanisms in .NET and Windows. This idea grew while talking to my -almost all of time younger- colleagues about .NET security. I started realizing that for developers who only worked in .NET environments, it is not that easy and obvious to understand how some of the .NET functionalities such as for example authentication and threading relate to the basic Windows operating system subsystems.

When developing in the .NET ecosystem we all are aware of the existence of sets of rules (or laws) that exist and that have to be respected. Examples of these laws and regulations in the .NET world are Code Access Security (CAS), Role-Based Security, AppDomain rules and many others. So when writing .NET code you have to play by the rules of the .NET world. But in the end when the .NET application is executed (and we all hope it eventually will) by the Windows operating system, a whole different set of rules apply. The reason is that the operating system treats the .NET application just like any other application or process on the machine, and here the game is played by the rules of the operating system. And since we all know that operating systems are a lot like the Old Testament gods (a lot of rules and no mercy), things can go wrong.

In a nutshell, in this series of articles I will try to explain the rules regarding identity and security in the .NET world and how they relate and map the corresponding rules in the Windows operating system world.
I will try to follow Albert Einstein's advice - keep this as simple as possible, but not simpler - and that is why this series is called "Back to basic".

Identity in the Windows world

When the operating system wants to protect access to its resources (files, communication ports, shared memory, semaphores and others) it needs to identify who is requesting access to the resource. It is clear that the process of identifying who requests access must provide strong authentication. When it is easy to fake another identity, there would be no security!

The Windows operating system grants or denies access to a resource based on an access control list (ACL). The ACL is a list of elements (ACE's) describing who can or cannot be allowed a certain type of access (Read, Write, Update or other) to the resource in question. Each ACE describes an access type for a Security Principal.

A Security Principal is an abstract term to indicate the party whishing to access the resource. Examples of Security Principal are users, machines, user groups.

A Security Principal is identified by a security identifier (SID). A SID is a structure that is unique in time and space that is issued by a trusted authority. For example, a SID representing a local user on a Windows machine is issued by the local security authority (LSA) component on the machine, while a SID representing a domain account is issued by the domain's security authority.

I won't go into details describing the format of SID's, but it is important to notice that besides the SID's issued by the authorities to identify user defined parties (such as individual users), there is a category of Well Known SID's that exist in every installation and always have the same value. Examples of Well Known SID's are the EveryOne user group, the Creator/Owner and the Administrator SID.

In the next figure the PsGetSid utility from http://www.sysinternals.com/ is used to display the SID of Everyone (Well Known SID), a local user and the machine.

Following figure shows the detail ACL for a file name MyFile.txt after the security was configured using the standard Windows explorer.

This concludes the introduction. Remember that there is a lot more to tell about SID's and ACL's (for example how inheritence works), but this should be sufficient to understand the relation with the .NET world later.

In the next part we will talk about processes, threads, process tokens and how they relate to security identifiers. After that we will have set the scene to dive into the .NET world.

Using enums with NetDataContractSerializer

noreply@blogger.com (Unknown) — Sun, 18 Oct 2009 09:07:00 +0000

When using the NetDataContractSerializer in WCF you can run into troubles when serializing enum types. If you do not specify a zero value for the enum, and try to serialize/deserialize a collection (such as an IList) of enums, you will get a serialization exception stating that no '0' value for the enum was defined. Example: public enum ColorsNonZeroBased { Red = 1, Orange = 2, Green = 5 } When trying to serialize IList you get the following exception: System.Runtime.Serialization.SerializationException: Enum value '0' is invalid for type 'Bromo.TaskChannel.Test.ColorsNonZeroBased' and cannot be serialized. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.. The solution is to provide a zero value for the enum (which is probably the recommended solution), or you can add a [FlagsAttribute] to the enum.

XML Documentation Guide

noreply@blogger.com (Unknown) — Thu, 12 Jun 2008 07:10:00 +0000

Whenever you need to document your .NET code (and don't remember all the possibe XML tags), here's a guide describing the tags. http://dynicity.com/products/XMLDocComments.aspx

Using statement and the WCF proxy

noreply@blogger.com (Unknown) — Mon, 09 Jun 2008 05:22:00 +0000

When you implement the closing of a WCF proxy with the 'using' statement, be aware that in some conditions exceptions can be lost. Example: try { using (MyProxy proxy = new MyProxy()) { proxy.SomeOperation(); } } catch (Exception ex) { ..... }
If the call to the service operation results in 'faulting' the channel, the original exception will be lost because leaving the using block will trigger a call to the Close method on the proxy, resulting in another exception (telling you that the channel is faulted) which masks the original exception. The annoying thing is that the behaviour of this code is dependent on the type of binding used (e.g. with a basicHttpBinding everything goes well, with a wsHttpBinding the real exception is masked when the channel is faulted). You can come up with different solutions for this problem. Some examples: - Keep the using statement and embed each call to an operation in it's own try..catch statement. - Replace the using statement with a try..finally construction, where you check the channel status in the finally clause. If the channel is faulted, you can call the Abort method instead of the Close method.