The .NET Framework

A Common Language Runtime supports different languages for .NET development.At the center of .NET is the .NET Framework, a development and runtime environment for developing business applications on the Windows platform. Key ingredients of the .NET Framework are CLR and a common framework of classes that can be used by all .NET languages. The .NET Framework is architected around a unified hub-and-spoke programming model designed to make different languages interchangeable. This allows development organizations to mix and match languages based on the availability of skills, expertise, and task requirements. In VisualStudio.NET, developers can automate the deployment of applications or components as Web services by simply marking a check box in the development environment. Additionally, all programming documentation is generated as XML documents, making project information and metadata easy to share with other developers, departments, or external business partners.

The Common Language Runtime

With .NET all languages translate into a CLR.The .NET approach to software integration is based on a hub-and-spoke configuration where a variety of languages are translated into a CLR. Figure 6.3 illustrates how multiple languages may be used to generate a common Intermediate Language (IL) that is at the core of the CLR framework.

The .NET IL is similar to Java's platform-neutral byte codes that can be ported across platforms.

COBOL may be used to develop .NET applications.For example, during the development of a complex application that involves the use of legacy systems, part of the application could be written in a .NET-compliant version of COBOL while other pieces might be written in C# and Visual Basic. The entire application, using a mix of languages, could be translated into IL, a compiled language at the heart of the CLR framework. Then the IL could be compiled to native code using a just-in-time compiler that precompiles frequently used code fragments. The developer could then check off whether the application would be deployed as a Web service. If so, the logic would be communicated automatically via SOAP and would be able to use emerging Web services standard application program interfaces (APIs) such as WSDL and UDDI.

What about Transactions?

MTS is the Microsoft transaction engine.Microsoft has long understood the importance of transactions for enterprise computing. In the early 1990s, Microsoft began working on its own transaction software for its middleware effort. The result was the Microsoft Transaction Server (MTS), designed to carry out basic runtime services such as ensuring all parts of a transaction occur in an all-or-none fashion, managing thread and connection pooling, and handling state management. Their transaction software was based on a Object Transaction Monitor, integrating the capabilities of a Transaction-Processing Monitor with distributed object services. The result was a transaction engine that serves as a container for components running in the middle tier of a three-tier application. This is also the approach followed by Sun in the design of their J2EE middleware.

Unlike early programming with transaction monitors, MTS does not require developers to insert complex transaction-processing code directly into their programs. Developers do not have to write the classic begin transaction, end transaction. Instead, the programmer adds a transaction attribute of component's class.