• In the beginning, nearly all transactional APIs are procedural in nature and require the explicit creation and destruction of transaction contexts by the caller. This type of code is rather difficult to write and maintain, especially in the case of distributed transactions that span multiple database servers or resource managers.
• Microsoft introduces Microsoft Transaction Server (MTS) in 1996 which is one of the first mainstream frameworks (if not the very first) to provide automatic / declarative transaction support for distributed transactions. MTS achieves its simplicity by mapping transactional semantics directly onto COM method calls... allowing any COM implementation language (VB, C/C++, Delphi, etc) to play along.
• Microsoft spends the next 5 to 7 years improving this technology and finally getting things working quite well... culminating in the present day COM+ model.
• During this time, the Enterprise Java Beans spec imports the MTS / COM+ model of declarative transactions into the Java world.
• Continuing the back and forth Sun / Microsoft technology borrow-a-thon of the late 20th century that has many interesting chapters... Microsoft starts with the general architecture of Java, adds several nice additions and enhancements and creates the .NET Framework.
• .NET 1.0 includes (via System.EnterpriseServices) the closest realization to date of the original MTS vision of simple object-oriented transactions. In fact, the entire custom attribute system of .NET, which has many great uses totally unrelated to transactions, appears to be largely motivated by the MTS / COM+ requirements.
• Microsoft adds Services without Components to COM+ and subsequently introduces its managed counterpart, System.Transactions, in .NET 2.0 which allows developers to explicitly create and destroy transactions manually, without relying on any MTS / COM+ object mapping. So... 8 to 10 years and 700 billion "How to program with DTC / MTS / COM+" book orders later... and we're back to almost exactly where we started.

Not that this is a bad thing... quite the opposite in fact. The MTS / COM+ style and the explicit transaction style have distinct feature sets and even in the cases where those feature sets overlap, both models have their pros and cons. Regardless, it's still pretty interesting to observe the full circle that Microsoft has completed here.

Although System.Transactions is, in some ways, a step backward in time, it is also an interesting and significant step forward in terms of developer productivity. Part of the original motivation for MTS / COM+ was the fact that explicit transaction code that included proper connection management and full error handling / rollback code, was quite tedious and verbose to create and maintain in the VB / C++ world of the mid 90s.

Where MTS / COM+ was revolutionary, System.Transactions is evolutionary. Highly evolutionary... so much so that System.Transactions looks almost nothing like its primitive ancestors. By relying on modern data access layers, a garbage collection runtime and even some of the post-Java features of .NET, new code written to System.Transactions is some of the cleanest and most readable distributed transaction code that I've ever seen:

public class AccountTransactions
{
    public static void Transfer(int IN_Amount)
    {
        using (TransactionScope scope = new TransactionScope())
        {
            using (SqlConnection connection1 = new SqlConnection(DemoData.Bank1Database))
            {
                connection1.Open();
                using (SqlConnection connection2 = new SqlConnection(DemoData.Bank2Database))
                {
                    connection2.Open();
                    DoWithdrawal(connection1, IN_Amount);
                    DoDeposit(connection2, IN_Amount);
                    scope.Complete();
                }
            }
        }
    }
}

This code is based on example code from Mike Clark's recent and highly recommended MSDN Video 'Introducing System.Transactions in .NET 2.0'.

Now before anyone jumps up and screams "That doesn't look any cleaner than the JDBC / ADO.NET / etc. code that I'm already using today" please note that this code implements a full distributed transaction across two distinct database servers. The databases in question could be on different machines or be of completely different platform / resource manager type (two Oracle servers, or one SQL Server and one Oracle Server, or a message queue and a database server, etc.)

The level of effort necessary to explicitly orchestrate these types of distributed transactions has never been lower. And if that wasn't enough... the new framework also automatically supports promotable enlistment (when supported by the underlying resource manager) which significant improves performance in situations where only a single database is being accessed. System.Transactions looks like it's going to be a great new addition to the .NET data access story.

This is an extremely useful feature for roaming users and allows them to, for example, start their laptop in a new or unknown office and instantly see any local web sites and printers that are availble to them. Zeroconf can also help to simplify, or even eliminate altogether, the need for the networking configuration interfaces currently required by collaborative and/or ad-hoc networking applications such as realtime document sharing software and multiplayer games.

I've been watching the Zeroconf space in the hope that more Windows support for the protocol would materialize. Porchdog Software has had a Zeroconf stack called Howl available for quite some time now. Hopefully, based on Apple's recent commitment, we'll be seeing more Zerconf enabled Windows apps in the future.

• Word and Excel documents will be able to contain data islands that will work equally well in both connected scenarios (data is retrieved from the server at runtime) and disconnected scenarios (data is embedded in the document instance and never connects directly to any server).
• The data islands will be able to implement caching behavior such that the latest query results from the server can be retained within the document itself just in case the document find itself in a disconnected state (ie on an airplane) the next time it is opened.
• The data islands can be created or updated from .NET code running on the server without requiring Office to be installed. Presumably, you'll just need to drop a small redistributable .NET DLL into your server-side bin directory and away you go.
• All of the above features will enable the creation of data-driven reports that can be 1) populated from a server-side web process, 2) downloaded and viewed by users that don't have any direct access to the data source and 3) have their data islands modified and re-uploaded by the user. Any changes can then be committed back to the data store via server side code.

Although it's technically possible to implement some of these features today by autogenerating and/or manipulating the new Word and Excel XML formats directly from server-side code, these new VSTO features will enable developers to create much more robust solutions with only a fraction of the effort required today. This is super-impressive looking stuff... read on for the full details:

Offline and server-based Office document scenarios
VSTO 2.0 and Cached Data: Goodbye Hidden Sheets, Hello Server!

Hello World, LCG Style!
Late-Bound Invocation Notes

DynamicMethod will allow runtime code generation to occur at a finer level of granularity, with better performance, and presumably without the resource hogging issues that exist with dynamic assemblies today. This is going to be a great addition to the CLR and we certainly would have made extensive use of this functionality had it been available to us during the implementation of Codify.

Beta documentation for DynamicMethod is available on MSDN:
DynamicMethod Class

It's also pretty entertaining to consider the fact that the PR handlers at both companies probably had to avoid announcing this yesterday for fear of the the April Fools factor.

Microsoft Press Release
Sun Press Release

• Open up any Windows application that contains a tree view control (Windows Explorer, Visual Studio, etc.)
• Select any node in the tree view.
• Press the * key on your numeric keypad.
• Watch with glee as the tree node and all of its children are expanded.
• Now press the - key on your numeric keypad.
• Watch with slightly less glee since this one is pretty easy to anticipate once you've seen the first one.

I've written and tested more than my fair share of tree view code over the years. (In fact, Codify uses more tree views than should be legally allowed in a single application.) In all this time I had no idea that these little gizmos were sitting there on my keyboard waiting to save me hundreds and thousands of mouse clicks.

Maybe some of these other keys are useful too...

Codify has several new features that we're pretty excited about. We're hoping to put up some new tutorials soon that show these features in action.

As for the new site.. it was a tough decision to make. We liked our previous site design visually but were looking for a way to reduce our update friction. So... we decided to go with a less structured and more text centric site.

And being the programmers that we are... we locked on to the idea of a text-centric site and took it pretty far towards the to the furthest possible extreme. There are still a few things that we don't like so you can expect to see it evolve over time.

Hope you like it! If you run into any problems or have any feedback then please don't hesitate to let us know at team.website@workstate.com.

256 * 256

sin(pi/2)

1 gallon

(2 * 8 grams) in pounds