Archive for August 10, 2008

Static Classes in C#

Posted: August 10, 2008 in .NET, CLR
Tags:

Normally in application development projects of any type we come across some sort of Utility classes, which has a bunch static methods for Date ,String .. etc manipulations.While reviewing code for the past few years I have seen two problems

  1. Some developers using object instances to access this methods without looking into the fact that they are static methods.
  2. During initial design & coding there are only static methods but down the line during support instance methods are getting added.

So we need to have a way where we can stop the instantiation of the class and addition of instance methods to it.

One option to do it in .NET 1.1 was making the class sealed with a private constructor.But that does not stop anyone from adding instance methods(of no use though) and private constructor takes up unnecessary metadata space.

In .NET 2.0 we have static classes for this purpose which can have only static members and can never be instantiated.

In my last post I had discussed about the Lightweight Transaction Manager(LTM) introduced with .NET 2.0.In this post we will take a look at MSDTC and how we can handle distributed transactions.
Microsoft Distributed Transaction Coordinator(MSDTC) can handle transactions with
1) Multiple Durable Resource Managers
2) Transaction Flow crossing process and machine boundaries.

As we have seen in the first post, in a transaction which is distributed across machines every box has a local transaction manager.The local transaction manager of the machine which initiates the transaction is called root transaction manager and it coordinates with local transaction managers in other machines.So all the transaction managers need to have a communication protocol for interacting messages over the network.For a distributed transaction across multiple windows machines each machine will have MSDTC as it’s local transaction manager and one of them will be the root.This is not a problem as MSDTC running on windows can communicate over network using RPC.

But what happens if one of the machines is running on Unix with a different transaction manager?

This is a question cross platform communication for distributed transaction related messages.Here also the Web Services standards come to our rescue.

There are two web Services standards for implementing this WS-coordination and WS-AtomicTransactions.
I will try to explain them briefly below:

WS-Coordination(WS-COOR)

This protocol defines an extensible coordination framework among different Web Services.It introduces a new SOAP Header block called Coordination Context.
The Web Service acting as a coordinator sends a Coordination context header to the target services.The target services upon receiving the coordination context analyses the information contained in the Coordination context header and decides to join the coordination or not.
The information contained in the coordination context depends upon the coordination type.The coordination types are open ended and new ones can be added.

WS-AtomicTransaction(WS-AT)

Atomic Transaction is one coodination type.This is built upon WS-Coordination framework and supports 2PC.But the messages are exchanged in SOAP format and thus achieving platform interoperability.

so to have distributed transactions with machines running on different platforms the local transaction manager supported by each platform should be able send and receive WS-COOR and WS-AT compliant XML messages over HTTP.