.NET is Microsoft's vision for computing. Introduced with great fanfare more than two years ago, .NET promises to use common Internet protocols to seamlessly interconnect devices, data and applications. Heavily reliant on XML, .NET is designed to allow users to access applications and data wherever they may be on whatever device is most convenient.
What are Web services?
Before we go further, let us take a minute to talk about Web services. One of the most confusing things about Web services is the very term itself. The word 'services' conjures up visions of people paying for something and getting something back. But at the most basic level, Web services is just a new flavour of standards-based software technology that allows programmers to combine existing computer systems in new ways, over the Internet, within one business or across many.
Web services lets companies bridge communications gaps between software written in different programming languages, developed by different vendors or running on different operating systems. The technology is drawing such huge hype because it promises to make it easier for companies to integrate software and reuse software that they or others have already built, and building software is historically an expensive and time-consuming process.
The most important part of Web services is a technology called XML, or extensible markup language (more on XML follows). For Web services to work, both sides (companies in communication with each other over the Internet) need to be able to speak XML. Microsoft's Web services strategy is, surprise, surprise, called .NET.
What is .NET?
The idea for .NET dates to 1999, when it was talked about as Next Generation Windows Services. Before the arrival of .NET, the Microsoft acronym of choice was DNA, which stands for Distributed Internet Architecture.
.NET supplants DNA and elevates the Microsoft development environment and tools to a new level of sophistication, power and ease of use, compared with previous versions of Microsoft development tools.
According to Microsoft, ".NET is a set of Microsoft software technologies for connecting your world of information, people, systems, and devices". Unlike Windows, .NET won't ship as a stand-alone product on a specific date. Instead, the company is gradually incorporating the technology into a variety of new and existing products.
The truth is, .NET evades easy definition because it covers so many topics. Some define it as a development platform for building XML Web services, while others think it's a set of enterprise servers. Both lines of thinking prove correct, although neither tells the whole story. Here's a blueprint for the second-generation Web from a .NET perspective:
XML (extensible markup language) is a common method for describing data, and lets programmers write their own tags to identify information in a document and put it into context. Industry groups are getting together to define their own XML dialects. For example, the shoe industry might agree on one tag to represent shoe size, another to represent shoe colour and so on.
.NET uses XML for universal representation, exchange and storage of all kinds of data -- and, in particular, to describe and manipulate component interfaces.
Today, components come in many flavours: shared libraries, script language modules and application-specific plug-ins. Component models like Component Object Model (COM) and Common Object Request Broker Architecture (Corba) make code reuse among these flavours possible but not easy, so it often doesn't happen -- particularly across organisational boundaries. Yet imagine how useful it could be to, say, travel agents, if airlines provided a pre-compiled component that could look up flight vacancies, reserve airfares and so forth. .NET aims to make component construction and reuse so easy that there's no excuse not to do it.
In theory, objects created by object-oriented programming (OOP) languages are components. In practice, the languages' object models don't match cross-language component models like COM and Corba. The .NET Common Language Runtime, a universal OOP engine, aims to solve this problem.
Because all .NET languages share the same object model, an object written in any .NET language is automatically a component available to all others.
This has some amazing ramifications. Most importantly, all .NET languages now provide all the features of any other .NET languages. For the first time, Visual Basic.NET offers structured exception handling and true object-oriented facilities like inheritance and polymorphism - just like C++ programmers are used to.
Microsoft also created a brand new programming language called C# (pronounced c sharp) that it submitted to the European Computer Manufacturers Association (ECMA) for consideration as a standard.
Every programming language comes with standard libraries -0 called frameworks in the case of OOP languages -- that encapsulate common code and define patterns for using it. The Java Development Kit's class libraries and Delphi's Visual Component Library are such frameworks. The .NET framework covers similar ground, but in a language-neutral way. C#, Visual Basic.NET and other .NET languages are only lenses through which programmers see the same underlying framework.
The Common Language Runtime (CLR)
.NET introduces an important technology known as the Common Language Runtime, or CLR. This is the basic library of functions and methods that make up the .NET framework. In other words, for all the functionality offered by .NET, there are corresponding routines in the CLR that enable this functionality to be used.
You can think of the CLR as a 'virtual machine', similar to Java's virtual machine concept. The comparison is quite apt; just as a Java program compiles to a pseudo byte-code (rather than pure machine language, like a C++ program does) which can then be executed on any Java virtual machine on any computer, so too .NET programs compile to an intermediate language.
In .NET, this is called the Microsoft Intermediate Language -- or MSIL. All .NET languages target the CLR, and all .NET languages compile down to MSIL.
It is this MSIL intermediate code that executes in the .NET framework. Theoretically, this even means that .NET programs could run on non-Windows platforms if ever Microsoft develops an implementation of the CLR for another operating system -- such as Unix.
Simple and open protocols let the first-generation Web scale up beyond most people's wildest expectations. The Web protocol, HTTP, carrying an HTML payload, brought client/server applications to the masses. On the next-generation Web, HTTP will also carry various XML payloads. Most notable among these is Simple Object Access Protocol (SOAP), which enables n-tier applications (this is when you use a mix of computer hardware and/or software layers, in order to provide a modular collection of information services) made by interconnecting network services across programming-language and platform boundaries. The .NET technology works hard to make it easy for developers to make and use components with SOAP interfaces.
In the n-tier environment, a network service has to juggle connections to users, data and other services. Windows NT and 2000 already supply basic middleware (Microsoft Transaction Server, or MTS, and COM+, respectively) for pooling and transactional control of these resources. The .NET platform doesn't invent new middleware. Instead, it aims to generalise and further simplify the use of existing COM+ technology.
Developers rely on tools that can capably build, debug and deploy software. Today, these tools are language-specific. But projects aren't. A first-generation Web service will probably involve several kinds of components and several flavours of glue. There are tools for building, debugging and deploying these various pieces, but there hasn't been one that comprehends the whole. That is what Microsoft hopes to achieve with Visual Studio.NET. Leveraging the universality of the .NET framework, runtime and languages, it gives developers a single interface through which to manage multilanguage, multicomponent projects.
An important technology here is the CLR. The CLR allows programs written in more than 20 languages to run on the .NET platform. With the CLR built into SQL Server for example, developers will be able to program for SQL Server using the same language and Visual Studio .NET tools they use to write their desktop- and server-based applications. Today, developers typically use the T-SQL language for Microsoft database programming, but with the Visual Studio for Yukon release (the forthcoming version of SQL Server), they will be able to use Visual Basic, C#, J#, C++ and other CLR-supported languages to write to databases.
The next-generation Web
These broad strokes paint a picture of software development for the next-generation Web. Some aspects have been known for a while. XML interfaces to Web services have been in use for several years. Many languages support XML and are now starting to support SOAP. Savvy Web developers are already using XML to isolate business logic from presentation and to offer interfaces to partner services.
Nobody needs to wait for .NET to do these things, and nobody should. Services built this way will interoperate now, no matter the platform or implementation language, and they will interoperate with .NET.
Who is .NET aimed at?
Today, what's of use in .NET is mostly aimed at Microsoft's legion of developers. These developers are relying on XML and the Simple Object Access Protocol (SOAP), which is a standard for sending messages across the Internet that activate programs or applications regardless of their underlying infrastructure. Also useful are Universal Description, Discovery and Integration (UDDI) -- a directory of companies and their XML interfaces -- and Web Services Description Language (WSDL), which describes what a piece of application code can do.
But today, to most companies .NET means using XML and SOAP to let diverse and even proprietary systems talk to one another and share data -- a goal that by no means defines just .NET. After all, Hewlett-Packard, IBM, Novell and Sun are among other vendors using the same standards for their own strategies similar to .NET.