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.
SOAP enjoys strong support from both Microsoft and IBM; you can expect SOAP support before long in both Exchange 2000 and Lotus Notes. On the XML front, industry efforts such as MessageML and SyncML provide the XML vocabularies necessary for more sophisticated cross-process communication. SOAP and XML promise a level of cross-organization cooperation and coordination that could make a project manager cry tears of joy.
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.
End of Article
