Subtle (or Not-so-subtle) Nuances of Microsoft .NET Enablement

Defining Microsoft .NET

Microsoft .NET is a comprehensive software development environment that was introduced in 2000 as Microsoft's next-generation programming environment. Pronounced "dot net," and widely known as the Microsoft .NET Framework, it was designed to compete with the counterpart Java-based Java 2 Enterprise Edition (J2EE) platform. The .NET Framework is the Microsoft Web services strategy for connecting information, people, systems, and devices through software, with the promise of "information anytime, anywhere, on any device." Integrated across the Microsoft platform, .NET Framework-based technology provides the ability to more quickly build, deploy, manage, and use connected, security-enhanced solutions with Web services.

Part One of the series Subtle (or Not-so-subtle) Nuances of Microsoft .NET Enablement.

The Microsoft .NET environment includes what a business might need to develop and deploy a Web service-connected information technology (IT) architecture: smart clients, servers to host Web services, development tools to create them, applications to use them, and a worldwide network of more than 35,000 Microsoft Certified Partner organizations to provide any help users might need.

The Microsoft .NET Framework is an integral Microsoft Windows component for building and running the "next generation" of applications and extensible markup language (XML)-based Web services. Among the potential benefits of the .NET Framework-based technology is the ability to provide a productive, standards-based, industrial strength, enterprise-ready, multilanguage environment that simplifies application development. This should enable developers to make use of their existing skill sets, facilitate integration with existing software, and ease the challenges of deploying and operating Internet-scale applications. The .NET Framework is the infrastructure of the .NET platform, which includes the Common Language Runtime (CLR) and the .NET Framework class library. The CLR provides the environment for running .NET Framework-based applications, whereas the class library provides the foundation services, including Active Server Page (ASP).NET; ActiveX Data Objects (ADO).NET; WinForms (for building graphical user interfaces [GUIs]); and base class libraries for accessing Common Object Model (COM) services.

Programmers can chose from several different programming languages, such as Microsoft C# (C Sharp), Visual Basic .NET (VB.NET), J# (J Sharp), Managed C++, JScript.NET, and others. The European Computer Manufacturers Association (ECMA) has standardized .NET as the Common Language Infrastructure (CLI), and numerous other languages have been reengineered as CLI languages. ECMA also standardized the C# programming language, designed by Microsoft to be the flagship .NET Framework-based language.

Depending on the class libraries used, the output of .NET and CLI compilers may or may not be identical, since .NET compilers generate Microsoft Intermediate Language (MSIL) bytecode, and CLI compilers generate Common Intermediate Language (CIL) bytecode. MSIL is executed by the CLR, and CIL bytecode is executed by the Virtual Execution System (VES). Both the CLR and VES are run-time engines like the Java Virtual Machine (JVM) in Java, since they provide a fundamental set of services that all programs use. The difference is that Java bytecode can also be interpreted as well as compiled, but the JVM supports only Java, and not multiple programming languages.

As mentioned earlier on, the heart of both .NET and CLI is a cross-platform language system. Although similar to Java because it uses an intermediate bytecode language that can be executed on any hardware platform that has a run-time engine, it is also unlike Java, as it provides support for multiple programming languages.

Currently in a beta release, the Microsoft .NET Framework 3.0 (formerly called WinFX) includes a new set of managed code application program interfaces (APIs) that are an integral part of the upcoming Windows Vista and Windows Server "Longhorn" operating systems. It will also be available for Windows XP SP2 and Windows Server 2003. The Microsoft .NET Framework 3.0 includes version 2.0 of the CLR, and it consists of four major components:

1. Windows Presentation Foundation (WPF) (formerly code-named Avalon), a new user interface (UI) subsystem which is API-based on XML and vector graphics (it will make use of three-dimensional [3D] computer graphics hardware and Direct3D technologies);
2. Windows Communication Foundation (WCF) (formerly code-named Indigo), a service-oriented messaging system that allows programs to interoperate locally or remotely similar to Web services;
3. Windows Workflow Foundation (WF), which allows for building of task automation and integrated transactions using workflows; and
4. Windows CardSpace (WCS) (formerly code-named InfoCard), a software component that securely stores digital identities of a person, and provides a unified interface for choosing the identity for a particular transaction, such as logging in to a web site.

For a general discussion of the evolution of system architecture, see Architecture Evolution: Service-oriented Architecture versus Web Services.

Interoperability is Key

While more technical details on Microsoft's ever-morphing technology blueprint can be seen in What Do Users Want and Need?, a key aim of .NET is interoperability between systems, both internal and external. The framework uses Web services and componentized systems as building blocks to create more collaborative systems. A resulting enterprise system is componentized by creating business objects that can be independently accessed to perform specific business functions and processes. The .NET Framework uses the XML standard as its "glue" for transferring data between objects, and in and out of the core system, and it complies with the concept and freedom of a browser and Web services as a means of rendering the information to a user. The business object should act as a "gatekeeper" to the system by ensuring that the following three fundamentals remain intact:

1. Security is enforced by the mere fact that every time an object is accessed the user is authenticated, and the security level prescribed by the core application is adhered to.
2. The business logic of the underlying application is always protected, whereby parameters are simply passed to the object for processing. The object protects the underlying business logic, and processes the transaction based on the passed parameters as if a user was sitting at a client workstation and entering the transaction.
3. The underlying data integrity is always protected, as the raw data is never accessed, since all data manipulation is controlled by the protected business object. The integrity of the underlying system is kept intact at all times, while at the same time an environment is created to extend functionality with a minimum amount of time, cost, and expertise.

Thus, with the advent of .NET, Microsoft-centric users might have the "best of both worlds," as they can benefit immensely from a feature-rich core system and have the added advantage of being able to develop business-specific applications to extend the functionality around the core system. This comes without the concern that future upgrades of the core system might affect or break the business-specific application.

Yet the Microsoft .NET strategy continues to confuse many users and vendors, due to the lack of understanding surrounding the technology. Indeed, because of the massive marketing campaign undertaken by Microsoft on the benefits of its .NET Framework-based technology, many vendors have adopted a "too liberal" approach to marketing their .NET Framework-based initiatives. The fact is, as soon as a software product is enhanced to consume or emit XML, it is called a .NET Framework-based product. In an effort to have their offerings perceived as ".NET-enabled," numerous vendors are referring to their solutions as such, though their products fall short of fulfilling many of the Microsoft-defined .NET parameters, some of which were outlined earlier on.

Beware of Mere .NET Compatibility

Consider the case where the body of software code comprising the core of the enterprise system has already been written. This code encompasses the business logic—the vast collection of rules that define required business transactions, and the rules and conventions for ensuring data accuracy, integrity and completeness, and appropriateness. The vendor is naturally reluctant to rewrite that core (which was difficult to write and maintain in the first place) in a new language, or to make the major structural changes necessary to employ a newer, more powerful database or operating system (OS) platform technology. Analyzing the current state of affairs of .NET readiness amongst the independent software vendors (ISVs), the most basic categorization (but not necessarily the most prevalent) is the case of mere .NET compatibility. This means that legacy software simply runs on .NET-branded servers (Microsoft Windows). On a positive note, these Microsoft-centric vendors can run on the latest Microsoft OS and database platforms. But on the downside, the well-publicized benefits of Web services are possibly not easily achievable, although these are often the first things companies want to integrate.