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.
Despite this evidence of Exchange 2000's .NET-worthiness, an administrator might still have questions about the server's right to membership in the .NET community. .NET Building Block Services documents include many references to future capabilities, saying that these services "will build upon" or "will bring together" elements in the current products and that the services "will be available" in various forms. The obvious inference is that Exchange 2000 and the other .NET Enterprise Servers are not yet fully developed as .NET participants; less obvious is what will need to change for the servers to be stronger players.
Consider the Identity service mentioned earlier. Is it the job of Exchange 2000's Identity service or of Win2K's Identity service to support your Passport or third-party wallet service? Similarly, the Notification and Messaging service will be responsible for notifying a PC or smart device when various predefined events occur. Should such notification be the job of the Notification service of Exchange 2000, Win2K, or possibly Mobile Information 2001 Server?
A Programmer's Perspective
Of course, no discussion of the .NET initiative is complete without some mention of Web Services and SOAP from a programmer's perspective. To reiterate, a Web Service is a programmable application component that is accessible through standard Web protocols. To comply with the .NET vision, Exchange 2000 must be implemented as a set of components, built to comply with the .NET Framework, that you can easily integrate into other applications. The question here is how well does the current version of Exchange 2000 support SOAP and expose the server's functions as Web Services?
The answer is that Exchange 2000 has significant support for applications written within the .NET Framework—that is, it has native support for XML and WebDAV and supports SOAP through the SOAP Toolkit for Visual Studio 6.0. The SOAP Toolkit includes a tool that lets you easily turn an existing COM component into a Web Service that other applications (e.g., VB or Web applications) can use. In other words, the SOAP Toolkit lets you turn COM objects that you've written into .NET applications that interoperate with Exchange 2000 as a .NET server.
The Microsoft article "Developing Collaborative Microsoft .NET Solutions" (http://msdn.microsoft.com/library/techart/collabdotnet.htm) contains details about how you might write an application that uses ADO+ or WebDAV and SOAP. In Session 3-312, "Building Next Generation Collaborative Applications for Exchange 2000 Using Visual Studio.NET," at the Microsoft Exchange and Collaboration Solutions Conference (MEC) 2000 in Dallas in October, Harry Katz, program manager, Microsoft Exchange Server Product Unit, demonstrated a .NET application that accessed data stored in Exchange 2000. Exchange 2000's support of a new pro- gramming environment is evidence that the server deserves its inclusion in the list of .NET Enterprise Ser-vers. Exchange Server 5.5 could not be included in the list because it doesn't support WebDAV and SOAP.
SOAP is only part of the programming story. For a developer building a project management or workflow solution, accessing Exchange 2000's Web storage system, scheduling engine, and notification capabilities should be as easy as setting a programmatic reference to those facilities in your development environment. Exchange 2000 has begun this transformation with limited support of Event Sinks, functions similar to SQL Server triggers. For example, Exchange 2000 can now look at incoming mail and execute a process such as a filter against profiles stored in Active Directory (AD). However, Exchange 2000 has a long way to go before we can describe it as a series of component services. Direct integration into the Universal Runtime Engine (URE) will facilitate componentization, and by extension, Exchange 2000's ascension to the .NET big leagues.
A Cross-Platform Perspective
.NET is fundamentally about distributed application development and the availability of application services over the Internet, independent of the platform supporting the services. SOAP over HTTP lets a UNIX application determine the availability of an Exchange 2000 user for a meeting or assign that person a task as part of a larger project. XML allows for a richer, more standardized message flow between applications, regardless of the application platform. A UNIX application can already take advantage of Exchange 2000's native support for XML for property inspection and workflow processes.
|Related Microsoft Resources|
| "Developing Collaborative Microsoft .NET Solutions"|
"Microsoft .NET: Realizing the Next Generation Internet"
"What Microsoft's .NET Vision Means for Businesses"
At this stage, no clear demarcation exists between Microsoft servers that do or don't fit into the .NET environment. Certainly, a simple application such as Exchange Server 5.5 that doesn't expose itself through a Web UI or Web Services isn't a candidate for inclusion in the .NET camp. Conversely, an application built entirely according to the architectural guidelines of the .NET software development kit (SDK) would be a stellar example of a .NET program. The current version of Exchange 2000 falls somewhere in the middle—a program that displays many of the features and behaviors of .NET and that can leverage current technologies such as XML, WebDAV, and the SOAP Toolkit, but that doesn't have all the .NET underpinnings in place yet. It will be interesting to see how Exchange 2000 will change as the .NET environment matures.