Microsoft's mail server begins to exhibit .NET characteristics
The Microsoft marketing machinery is off to an early start stamping most new Microsoft products, as well as some current products, with the .NET brand. You might have seen Microsoft Exchange 2000 Server on the list of .NET Enterprise Servers and wondered what the implications of the listing are. Has Exchange 2000 really undergone (or will it undergo) significant changes because of its identity as a .NET server? Let's look at what the .NET initiative means for Exchange 2000 now and in the future.
The Microsoft .NET Initiative
Microsoft announced .NET with characteristic modesty: ".NET promises a world of business without boundaries" (from "What Microsoft's .NET Vision Means for Businesses" at http://www.microsoft.com/business/vision/netvision.asp). The white paper accompanying the announcement elaborates on this vision: "The fundamental idea behind Microsoft .NET is that the focus is shifting from individual Web sites or devices connected to the Internet to constellations of computers, devices, and services that work together to deliver broader, richer solutions" (from "Microsoft .NET: Realizing the Next Generation Internet" at http://www.microsoft.com/business/vision/netwhitepaper.asp). For a list of several Microsoft Web sites and documents about .NET, see "Related Microsoft Resources," (page 54).
A simple analogy within a traditional enterprise computing environment is the transition from a single-server program to a distributed-database application that the end user accesses with a desktop client that retrieves and combines data from numerous locations. .NET extends this distributed-application example from the enterprise to the Internet and from structured data to Web Services. Different from the services that Web portals provide today, a Web Service is a programmable application component that you can integrate into a multiprocess distributed solution.
Currently, if you order equipment on the Web, you might be able to check the vendor site for a shipment-tracking number, then enter that number at the shipper site to see the status of the shipment. A .NET solution implements the shipment-tracking functionality as a Web Service so that the vendor site can query the shipper site and display the shipment status for you directly. This level of programmability is a step beyond what we see today on the Internet.
You might argue that because applications are moving in this direction anyway, .NET is just Microsoft rebranding for marketing purposes. Not so! Microsoft is revamping and reinventing the majority of its tools (e.g., Visual Studio--VS, Visual Basic--VB) and platforms (e.g., Windows 2000 Server, Win2K Advanced Server, and Win2K Datacenter Server) to create a .NET platform that facilitates distributed solutions on the Web (and possibly to combat a competing paradigm from Sun Microsystems and Oracle). The .NET platform components are
- Windows services
- .NET Framework
- .NET Building Block Services
- .NET Orchestration
- .NET Enterprise Servers
Each component contains crucial new technologies. For example, the .NET Framework includes a new programming environment with a set of programming classes, an Intermediate Language (IL) that all high-level language (HLL) code will be compiled into, and a runtime environment (Common Language Runtime--CLR) to run IL. The framework also supports a new data access model (ADO+) and a pervasive use of XML over HTTP to access data (WWW Distributed Authoring and Versioning--WebDAV--and Simple Object Access Protocol--SOAP). Microsoft's first .NET tool set that lets programmers create applications within the .NET Framework will be Visual Studio.NET, scheduled for availability in mid-2001.
Similarly, .NET Building Block Services include a set of new XML-based Web Services: Identity, Notification and Messaging, Personalization, XML Store, and several others. For example, you might be able to use one Microsoft Passport to log on to many Web sites or even to access your Exchange mailbox.
The .NET Enterprise Servers are Application Center 2000, BizTalk Server 2000, Commerce Server 2000, Exchange 2000, Host Integration Server 2000, Internet Security and Acceleration (ISA) Server 2000, SQL Server 2000, Mobile Information 2001 Server, and the upcoming Tahoe server. Several of these servers are available today. Because the .NET Framework is not yet fully developed, Microsoft couldn't have developed these servers from the ground up using the pure .NET code. However, a server such as Exchange 2000 might qualify as a .NET server because you can use WebDAV with it or because it provides .NET services.
An Administrator's Perspective
One reason that Exchange 2000 deserves the .NET moniker is that it supports .NET-style distributed Web architectures. Many Exchange 2000 services can be run on separate physical servers, letting you optimize a server farm. For instance, you can offload POP3 processing to a front-end server, reducing load on the back-end message-store server.
Figure 1 shows a simple Exchange 2000 environment. In this example, the enterprise has several systems providing .NET-type Web services: two front-end servers supporting POP3, IMAP4, and SMTP services; three front-end servers supporting HTTP (Outlook Web Access--OWA) services; one front-end server supporting Network News Transport Protocol (NNTP) services; and two Win2K domain controllers (DCs) configured as Global Catalog (GC) servers providing directory and authentication services. Remote users can load Microsoft Outlook Express, use POP3 or IMAP4 to download their mail, use Lightweight Directory Access Protocol (LDAP) to search the directory, and use SMTP to forward a message.
At first glance, Figure 1 seems to exemplify the .NET environment description at the beginning of this article ("constellations of computers, devices, and services that work together to deliver broader, richer solutions"). You isolate the protocol and directory services on different servers so that you can optimize each of the services for their anticipated loads and optimize the "constellation" as a whole for the user population; Microsoft refers to this implementation as server specialization. However, not all the services in Figure 1 are .NET Web Services. In fact, the only service that meets the strict definition of an application exposing itself through a .NET Web UI is OWA for Exchange 2000.
In addition to placing separate Exchange 2000 functions on specialized front-end servers, you could increase the number of any one of the specialized servers to improve performance. For example, instead of having only one OWA server, you could have two or more, using a load-balancing solution such as Microsoft's Network Load Balancing (NLB) to hide the specific server details from the user. Remote users would always enter the same URL to access their mail, but a different computer might handle a user's connection request each time. Instead of telling users, "Connect to http://mail1.company.com; if that fails, try http://mail2.company.com through http://mail25.company.com," you tell them, "Connect to http://mail.company.com," and the load balancer finds an OWA server with adequate free resources. This use of multiple instances of a single type of front-end server is another example of the .NET goal of shifting from individual Web sites or devices to constellations of sites or devices.
Previous
