Developing Collaborative Microsoft .NET Solutions

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : June 14, 2001

Michael Herman

EC3 Enterprise Consulting Competency Centers
Microsoft Corporation

Summary: This article explores the Microsoft .NET Platform with a particular focus on how to architect, design, and build collaborative Web Services using the .NET Platform, Exchange 2000 Server, and the Microsoft Web Storage System.

Introduction

Microsoft is creating a new generation of software that melds Web computing and communications in a revolutionary new way by offering developers and end users the tools they need to transform the Web and every other aspect of their computing experience. We call this initiative Microsoft .NET.

Microsoft .NET will allow the creation of truly distributed Web Services that will integrate and collaborate with a range of complimentary services in ways that today's customers can only dream of. The fundamental idea behind Microsoft .NET is that the focus shifts from individual Web sites and devices connected to the Internet, to a fabric of cooperating computers, devices, and services that work together to deliver broader, richer solutions. People will have control over how, when, and what information is delivered to them. Computers, devices, and services will be able to collaborate with each other instead of being isolated islands where Web surfing is the only form of integration. Businesses will be able to offer their products and services in a way that lets customers and suppliers seamlessly embed them in their own electronic fabric of business processes and daily activities.

There are five components in the Microsoft .NET Platform:

Microsoft Windows® operating system services platform
.NET Framework
.NET Building Block Services
.NET Orchestration
Microsoft .NET Enterprise Server family

Within the .NET Enterprise Server family, Exchange 2000 Server is the reliable, easy to manage messaging and collaboration solution for bringing users and knowledge together.

This paper will explain the Microsoft .NET Platform with a particular focus on how to architect, design, and build collaborative Web Services using the .NET Platform, Exchange 2000 Server, and the Microsoft Web Storage System. The Microsoft .NET distributed Web architecture will be explained, as well as the key development features of the Microsoft Web Storage System.

In addition, we'll look at how the Web Storage System and the .NET Framework work together for building high-value collaborative Web Services. A travel agency scheduling example will be used to illustrate the practical architecture and design considerations that you need to think about as a Web Services architect and developer. Finally, we'll look ahead at the additional .NET features the Exchange 2000 Server development team is planning to deliver over the next few releases of the Microsoft Web Storage System.

XML

Microsoft .NET will help drive a transformation in the Internet that will see HTML-based presentation greatly enhanced through the adoption of programmable XML-based information. XML is a widely supported industry standard defined by the World Wide Web Consortium, the same organization that created the standards for the Web browser. XML provides a means of separating actual data from the presentational view of that data. It is a way to distribute data to a variety of digital devices, allowing Web sites to collaborate and interact through the XML-based Web Services they choose to expose.

Built on the standard integration fabric of XML and Internet protocols, the Microsoft .NET Platform is a revolutionary model for developing an advanced new generation of software. Microsoft .NET is explicitly designed to allow the integration or orchestration of any group of resources on the Internet into a fabric of cooperating solutions. Today, this type of integration is extremely complex and costly. Microsoft .NET will make it quicker and easier to design, implement, and deploy these types of collaborative Web solutions.

Web Services

The loosely coupled XML-based Microsoft .NET Platform introduces the concept of XML-based Web Services. Whereas today's Web sites are hand-crafted and don't work with other sites without significant additional development, the Microsoft .NET Platform provides intrinsic mechanisms that will enable any Web site or service to collaborate with any other in a seamless way.

The simplest definition of a Web Service is a programmable application component that is accessible through standard Web protocols.

There are four categories of Web Services that will be delivered to the Internet:

Public .NET Web Services
Commercial .NET Building Block Web Services
Ready-to-use, out-of-the-box Web Services
Custom-developed Web Services

Public Web Services will appear on the Internet and be easily and broadly integrated into new and existing Web solutions. Some will be freely available while others will be supported by a variety of business models. The latter category of Web Services are called commercial Building Block Web Services and will be available from application service providers (ASPs) as well as from Microsoft. Passport is Microsoft's first Building Block Service and provides a single sign-in capability (allowing a user to use a single name and password across multiple Web sites). Forthcoming Passport Building Block Services include electronic wallet and public profile services. Please visit the Microsoft Passport Web site to learn more.

With the .NET Platform, developers can also look forward to leveraging ready-to-use, out-of-the box Web Services supplied by Microsoft and other software companies in their own collaborative solutions.

The custom-developed category of Web Services includes those Web Services developed for in-house use by corporate developers and solutions partners.

Developers will be able to leverage and customize a range of core Microsoft .NET Building Block Services in their own applications and services, reducing the effort required to create compelling solutions. These core Microsoft .NET Building Block Services correspond to areas of functionality where Microsoft has deep expertise and can provide value to a broad set of developers. Microsoft is unifying these developer building blocks to enable the easy delivery of highly distributed, programmable services that run across standalone machines, in corporate data centers, and across the Internet.

With the option of subscribing to these core .NET Building Block Services off the shelf, developers can make a "buy or build" decision as to where they want to spend their development resources. Some may elect to build basic service capabilities themselves, but many will likely opt for a well-packaged solution with strong development tools support, just as many developers choose not to write their own printer drivers or windowing system and instead focus their resources on differentiating their own high-value solutions.

Web Services have the following characteristics:

You can ask a site for a description of the Web Services it offers.
Web Services are defined in terms of the formats and ordering of the messages they support.
Web Service consumers send and receive messages using XML.
All of these capabilities are built using open Internet protocols.

Distributed Web Services built with the Microsoft .NET Platform will be available both online and offline. A service can be invoked on a standalone machine not connected to the Internet, provided by a local server running inside a company, or accessed through the Internet cloud. Different services can cooperate and exchange information through a process called federation which allows organizations to decide whether to run their own infrastructure or host it externally without compromising their control or access to services. For example, a corporate directory service can federate with another directory Web Service that runs on the Internet.

Microsoft .NET Building Block Services can be consumed on any platform that supports XML. Windows, Exchange 2000 Server, the Microsoft Web Storage System, and Visual Studio® will offer the best environment to create and deliver collaborative Web solutions.

Web User Experience

While Web Services allow developers to easily expose the functionality of an application so that other server and client applications can connect to it, many applications need to expose all or part of this functionality to Internet and intranet users through a Web user interface (UI).

In addition, Microsoft .NET enables solutions running on PCs and devices to collaborate seamlessly with the information and function rich world of the Internet, including the ability to work online and offline, and have the application transparently move between using local and remote applications and services.

Microsoft .NET will affect the Web User Experience in 3 ways:

Innovative new improvements for building new Web user interfaces.
Transparent presentation of a user interface across a broad range of devices.
The way we work and play.

From a user interface perspective, Microsoft .NET will offer users and developers the following user interface technologies:

Natural Interface. A collection of technologies that enable the next generation of interactions between humans and computers, including speech, vision, handwriting, and natural-language input through a new "type-in" box.
Universal Canvas. An XML compound information architecture that integrates browsing, communications, and document authoring into a single, unified environment enabling users to synthesize and interact with information in a unified way. The universal canvas builds upon XML schema to transform the Internet from a read-only environment into a read/write platform, enabling users to interactively create, browse, edit, annotate, and analyze information. Because the underlying information is XML, the universal canvas can bring together multiple sources of information from anywhere in the world.
Information Agents. Manages your identity and persona over the Internet and provides greater control of how Web sites and services interact with you. Unlike today's Internet, your personal information will remain under your control and you decide who can access it. Information agents will enable you to create your personal preferences just once, which you can then permit any Web site or service to use.
SmartTags. Extends IntelliSense technology to Web content and enables your PC and devices to be smart about handling information from the Internet. An extensible architecture allows anyone to create adaptive user experience and data handlers. Built into virtually every Microsoft application, IntelliSense technology automates repetitive tasks, simplifies complex tasks, personalizes the software, and makes the functionality in the products more accessible.

To support the transparent presentation of Web UI on any type of device, including the latest Internet Explorer and HTML 3.2 compatible browsers, the .NET Platform introduces ASP+, the next generation of Microsoft's Active Server Page (ASP) technology. For Web designers and developers, it's about making Web UI fundamentally easier to design and develop while leveraging existing experience developing ASP applications. For Web masters, it is about Web applications and services that are easier to deploy and manage, and have higher scalability, security, and reliability.

The key technology at work here is ASP+ Server Controls that will be fully supported by the new Visual Studio .NET designer. The development model is the same familiar model Visual Basic developers use today: select a control from the tool box, draw it on a Web Form, double-click on it to add code to respond user events, and then compile your project. The form and code are automatically compiled and deployed to your development Web server where ASP+ server controls automatically detect the user's browser type and generate pure DHTML or HTML 3.2 that is compatible with the browser type. Several categories of extensible and composable ASP+ server controls will ship with Visual Studio .NET. The list of categories includes intrinsic controls (that map to their HTML equivalents), data-aware list controls, rich calendar and ad rotator controls, and form and field validation controls.

Combining the Web Services and Web UI features of the .NET Platform will significantly change the way we work and play on the Internet. For example, to book a vacation, one typically has to gather several pieces of information together: preferred travel times, vacation destination, special dietary considerations, smoker/non-smoker preferences, preferred rental car agency, airplane seating preference, frequent flyer account numbers, hotel preference, payment information, and so on. A travel agency may have some or all of these preferences, but will they have your most recent information? Or what if you use more than one travel agent?

Instead of pulling all this information together each time, why not simply book your vacation in your Outlook® calendar and have an Information Agent running on your Exchange server automatically contact a Web Service running on your travel agent's Web site? The call to the Web Service would include the preferred travel times and destination information. If the travel agency needed additional information about your travel preferences, why couldn't the agency simply call back to a Web Service exposed by your Exchange server and have the Web Service automatically provide the information you've authorized it to share with that agency?

Once the travel agent finalizes your vacation plans, the Web Service on your Exchange server is again contacted to update the original calendar appointment information. This appointment can be auto-synchronized with the calendar in your Pocket PC or made immediately available through a wireless Pocket PC device. Your vacation details are available any time, anywhere.

This is the new world of collaborative Web Services enabled by Microsoft .NET, Exchange 2000 Server, the Web Storage System, and Visual Studio. This paper elaborates on collaborative scheduling in the Travel Agency Collaborative Scheduling Example.

Microsoft .NET Platform

Key attributes of applications and Web Services built for the .NET Platform include:

They expose themselves as a Web Service in addition to having a Web UI.
They use open Internet protocols.
They support rich Web user experiences adapted to smart clients and devices.

For architects and developers, .NET applications and Web Services are also quick to develop and deploy, and easy to integrate with other Web Services and existing applications.

Figure 1: Microsoft .NET Platform

Windows Operating System Services

The Microsoft .NET Platform is built on the scalability, reliability, security, and manageability of the Windows 2000 Server family. For Windows-based .NET servers, Windows 2000 Server provides high-performance operating system services including:

Security (including encryption and a full Public Key Infrastructure).
Complete, high performance, standards-based XML subsystem.
Extremely high bandwidth I/O between disk and memory and any TCP/IP connection.
Continuous deployment by allowing multiple versions of applications to run concurrently.
Highly efficient threading and fiber support.
Content indexing, search and retrieval.
Memory caching.
Process scheduling.
Windows Streaming Media support for audio and video collaboration.

Windows 2000 Professional, Windows NT® Workstation, and the consumer versions of Windows (Windows 98 and Windows Me) will continue to feature Internet Explorer for the richest Web User experience and XML support. In addition, Windows CE provides the rich set of operating system features required by mobile applications running on small- and medium-size devices to support online, offline, and wireless solutions.

.NET Orchestration

BizTalk Server 2000, one of the new .NET Enterprise Servers, provides the design tools and run-time environment for orchestrating any group of business processes and Web Services within, as well as between organizations. .NET Orchestration, the second component of the .NET framework, is used to integrate and extend Web Storage System workflow into a scalable fabric of cooperating workflow solutions.

.NET Orchestration addresses one of the most common business challenges of being able to quickly evolve business processes and integrate them with customers and business partners, while at the same time addressing the technical challenges that arise from these processes being spread across multiple software systems running on multiple hardware platforms running at multiple customer, partner, and service provider locations.

The .NET Orchestration solution to these challenges is to separate process definition from its underlying implementation. Business process experts create and manage the evolution of the business processes while developers focus on implementing the underlying services required to support them. The .NET Orchestration visual designer included with BizTalk Server provides the point of coordination between process design and the integration with external Web Services and messaging systems.

One of the ways.NET Orchestration can be used is to integrate and extend individual Web Storage System workflows into a larger fabric of cooperating workflow solutions.

.NET Enterprise Servers

The .NET Enterprise Servers are Microsoft's comprehensive server family that allow you to quickly build and manage an integrated, Web-enabled enterprise system. Designed with scaleable, mission critical performance in mind, .NET Enterprise Servers are built from the ground up for interoperability using the most current Internet Web and data standards.

The seven core .NET Enterprise Servers include:

SQL Server™ 2000
Internet Security and Acceleration (ISA) Server 2000 (formerly Proxy Server)
Host Integration Server 2000 (formerly SNA Server)
Exchange 2000 Server and Exchange 2000 Conferencing Server
Commerce Server 2000
BizTalk Server 2000
Application Center 2000

Exchange 2000 Server

Within the .NET Enterprise Servers family, Exchange 2000 Server is the reliable, easy to manage messaging and collaboration solution for bringing users and knowledge together. Exchange 2000 Conferencing Server provides real-time chat, data, audio, video, and application sharing that is as easy to use as booking a meeting through Outlook.

A key innovation in the Exchange 2000 Server release is its distributed Web logical architecture. Physically, the front-end services can run on their own physical servers separate from the back-end Exchange Services and Web Storage System, depending on the need to scale the number of user connections, middle-tier processing power or back-end processing, and storage requirements.

Figure 2: Exchange 2000 Server distributed Web architecture

The front-end protocol services implement a rich set of Internet protocols to support client applications, as well as server-to-server communication. The client protocol services include HTML/HTTP, POP3, IMAP4, NNTP and WebDAV (XML over HTTP), FrontPage and Office Server Extensions protocols, H.323 audio/video conferencing, and T.120 data conferencing. The server-to-server (and server-to-Internet) protocol services include SMTP, NNTP, and X.400.

In addition, the front-end protocol services support Outlook Web Access for Exchange 2000 Server (OWA 2000) which exposes Outlook 2000 functionality as an HTML/HTTP Web component-based Web UI, making it ideal for Internet kiosk, roaming users, and home access scenarios. OWA 2000 can be used as a complete e-mail client with access to e-mail, calendar appointments, and contacts, plus access to all the information stored in your private and public folders. In addition, developers can use each component of the OWA 2000 Web UI to automatically render rich calendars, contact lists, e-mail, and threaded discussions in their own collaborative Web solutions.

The Exchange services implement the core messaging and collaboration services, including support for the front-end protocol services layer, systems management, and server-to-server replication.

The Web Storage System implements a secure hierarchical folder model for storing any type of unstructured or semi-structured content (e-mail, documents, files, executables, and so on) and then adds support for accessing and updating that content through a rich set of APIs, Internet protocols, an event model that supports both synchronous and asynchronous processing, and a workflow engine. The latter enables the Web Storage System to become a powerful collaborative Web platform for automating business processes.

ADO 2.5 is the strategic Web Storage System object model for accessing information about a folder and the items it contains, as well as the individual items themselves. ADO 2.5 ships with Windows 2000 and uses the new Web Storage System OLE DB provider. The first key benefit is that a unique, easy-to-read URL identifies every item in the Web Storage System. In addition, ADO 2.5 is the object model to use for hierarchal traversal of the folders and items in the Web Storage System.

A new ADO 2.5 object, the ADO record, is used to retrieve the properties of an individual folder or item and to create new folders or items. The new Stream object provides efficient access to an item's attachments (such as Office and XML documents) as well as audio and video streams. Traditional ADO Recordsets are used to retrieve information about a collection of items.

A new series of Web Storage System Collaboration Data Object (CDO) libraries are built on top of ADO and OLE DB providing higher level, object-oriented access to the items and management functions in the Web Storage System and Exchange 2000 Server. (Given that the Web Storage System CDO is implemented on top of ADO and OLE DB further emphasizes the strategic role of ADO for data access across the Microsoft platform.)

For compatibility with existing e-mail clients, including all versions of Outlook and Outlook Web Access for Exchange Server 5.5, the Web Storage System also supports the MAPI and CDO 1.2 APIs.

For compatibility with the simplest desktop applications, the Web Storage System also provides an installable file system (IFS) driver that allows the Web Storage System hierarchical folder store to be viewed as a hierarchical file system in Windows Explorer, the command prompt, or the standard file system dialog boxes for opening and saving documents. IFS drive folders can also be shared like normal file system folders and accessed using the traditional Server Message Block (SMB) network file-sharing protocol.

This rich set of Web Storage System APIs and Internet protocols will enable a new set of collaboration services in "Tahoe", Microsoft's second Web Storage System-based collaboration server product. In addition, a future version of Office will ship with a version of the Web Storage System that will run locally on a client PC and support Active Server Pages as well as direct synchronization and caching with server-side Web Storage System-based products.

.NET Building Block Services

Building Block Web Services are the commercial Web Services offered by Microsoft and other Internet service providers that developers will be able to leverage in the development of their own applications and Web Services. The core Microsoft .NET Building Block Web Services will include:

Identity
Notification and Messaging
Personalization
Storage
Calendar
Directory and Search
Dynamic Delivery

Identity services are based on the Passport service described earlier. Notification and messaging is a unified service that integrates instant messaging, e-mail, fax, voice-mail, and other forms of notification. Personalization services control how and when notifications and messages are delivered, and how information on multiple devices should be coordinated. .NET Storage services is the Internet digital equivalent of today's bank safety deposit box. A user will hold the key and control the access.

Calendar is an integration service for your work, social, and home calendars that, coupled with real-time presence data, will allow other Web Services to determine your availability. Directory and Search makes it possible to find services and people. Additionally, developers and applications will be able to use schema-based queries to ask questions about those services. Dynamic Delivery services enable Microsoft, ISVs, solution partners, and other developers to offer incremental levels of functionality and reliable automatic upgrades on demand, without user installation and configuration.

A recent development, Universal Description, Discovery and Integration (UDDI), co-developed by Microsoft, IBM, and Ariba, is a specification and reference implementation for distributed XML-based information registries for Web Services. UDDI registries let you describe and discover the Web Services exposed by an organization. Each UDDI registry entry includes descriptive information about a business and technical information about the services that it exposes. Visit the UDDI Web site for more information.

.NET Framework

The .NET Framework contains five basic components that developers will program to:

Common Language Runtime
.NET Base Classes
Data and XML transport
Web Services
Web UI

Figure 3: The .NET Framework: applications expose Web Services and Web UI

Common Language Runtime

The design goals of the Common Language Runtime (CLR) are:

Dramatically simplify application development.
Provide a robust and secure execution environment.
Support multiple programming languages.
Simplify deployment and management.

The Common Language Runtime allows all programming languages to achieve functional parity and to actively participate in the .NET development environment equally. This means that not only are C++®, Visual Basic, C#™, and JScript® great Microsoft .NET languages, but Microsoft partners have implemented an additional 20+ languages that run on the .NET Framework.

Two key features have contributed to this development. First, all languages compile into an Intermediate Language (IL). Similar in concept to pseudocode or Java byte codes, all languages essentially compile into one metalanguage. Then, the CLR can compile IL on the fly (or in advance) so that it can run in any environment and any CPU. In addition, all language implementations that support the CLR will automatically inherit all the functionality of Visual Studio .NET, including authoring, debugging, compiling, object models, new server explorer features, and so on, as well as improvements implemented in the run-time itself, the .NET Base Class libraries and third-party debuggers, profilers, code coverage analyzers, and documentation tools.

In addition, the CLR eliminates a lot of unnecessary plumbing like component registration, GUIDs, IDL files, HRESULTs, IUnknown, AddRef/Release, and CoCreateInstance. All CLR languages are object-oriented and gain full support for inheritance including languages that were previously considered non-OO languages like Visual Basic and COBOL. This includes deriving classes written in one language from superclasses written in a second or third CLR language. Finally, all .NET objects are automatically garbage-collected with a new multi-generational mark-and-compact garbage collector.

Base Classes

To replace the many families of class libraries and application frameworks that exist on a typical desktop or server machine, the .NET Base Classes were developed to provide a single, common set of run-time classes across all the .NET CLR languages, and to fully leverage the features of the CLR and the .NET Platform.

Top-level Base Classes hierarchy includes:

System.Web.Services
System.Web.UI
System.XML
System.Data.ADO
System.Data.SQL
System.WinForms
System.Security
System.IO
System.Runtime

Data and XML

The Data and XML components of the .NET Framework refer to the way information will be transported between new and existing components, Web Services, and applications.

ADO+ is a key .NET innovation that at the same time represents an evolutionary improvement in ADO (ActiveX® Data Objects). ADO+ is a standards-based programming model for creating distributed, data sharing applications. The technology centerpiece is the ADO+ Dataset that stores several database tables and table relationships in memory. ADO+ tables can be simultaneously accessed as an XmlDataDocument as well as relational tables and XML DOM objects (in contrast to an ADO Recordset which looks like a single table and has limited XML support).

Datasets are disconnected views of the XML or database data (implying that they exist in memory without an active connection to the underlying data servers). They can be cached locally in a data server or extended out to any tier in your solution architecture. XML is used as both the transmission and persistence format when Datasets need to be saved for disconnected, offline solutions.

In addition to supporting the extendible caching of data out to the middle-tier or client, ADO+ also coordinates all of the modifications to the underlying data server, including table creation, schema modification, relationship and constraint management, concurrency management, and transactions. Other ADO+ modifications include adding, selecting, editing, deleting, and removing data from a table or XmlDataDocument.

The interface or adapter between an ADO+ Dataset and an underlying data store is called a Managed Provider. The .NET Platform will ship with managed providers for SQL Server, XML, and ADO. The Web Storage System managed provider will follow shortly.

Extending What You Know Today

While the .NET Platform is a new platform for building integrated, collaborative solutions, it builds on what you know today and then strives to make it easier to architect, implement, deploy, and manage. A typical or model .NET server is depicted below.

Figure 4: NET Server model architecture

The model architecture is a common one used in most Windows servers today. However, the .NET Platform makes it easier to expose data, XML, Web UI, and Web Services. The .NET Common Language Runtime and Base Classes provide a full object-oriented, managed memory environment common to all CLR programming languages for building more robust components, subsystems, and applications easier and more quickly. ADO+ builds upon ADO to provide an extendible Dataset caching and persistence model for managing data in disconnected online and disconnected offline scenarios. .NET applications provide a Web UI for communicating with people and a Web Service to allow developers to easily expose the functionality of an application so that other server and client applications can connect to it.

Microsoft Web Storage System

The Web Storage System implements a hierarchical folder model for storing any type of unstructured or semi-structured content (e-mail, documents, files, and executables) and then adds support for accessing and updating that content through a rich set of APIs, Internet protocols, an event model that supports both synchronous and asynchronous processing, and a workflow engine.

The Web Storage System supports the following APIs and Internet protocols:

Data access APIs: ADO 2.5 and Web Storage System CDO
Client access protocols: MAPI, HTTP, POP3, IMAP4, and WebDAV, as well as the FrontPage and Office Server Extensions protocols
Installable file system (IFS) driver that allows folders, subfolders, and items in the Web Storage System hierarchical folder store to be accessed as a hierarchical file system mounted as the M: drive

In addition, Exchange 2000 Server, the Exchange 2000 Conferencing Server, and Active Directory™ provide support for the following APIs and Internet protocols:

Server transport protocols: SMTP, NNTP, and X.400
Real-time collaboration: H.323 Audio/Video Conferencing, T.120 Data Conferencing, Exchange Instant Messenger, and Exchange Chat
Directory protocols and APIs: LDAP and ADSI

Figure 5: Web Storage System: APIs and Internet protocols

With this set of APIs and Internet protocols, Exchange 2000 Server and the Microsoft Web Storage System becomes a powerful collaborative solutions platform for delivering automated business solutions.

Hierarchical Object Store

A folder in the Web Storage System can be viewed as:

A database table with a dynamically extensible, flexible schema.
A hierarchical file system.
A hierarchical object store.

The key to understanding these different perspectives is to understand the basics about folders, subfolders, items, and properties. For most people, their understanding of the Web Storage System's concepts of a folder and an item are based on the lists and forms that are presented to them by Outlook 2000 or a similar personal information manager. It is important to understand these concepts at a more basic level.

A hierarchy of folders, starting with the hierarchy's top-most folder, is referred to as a Top Level Hierarchy (TLH) in the Web Storage System. A Web Storage System folder is used to store a collection of items. An item has a list of properties associated with it. A property is a simple name=value pair where the value may be single or multi-valued. The name of the property is qualified by the XML namespace it belongs to, such as DAV: or urn:content-classes. The list of items and their properties can be retrieved as an ADO Recordset or WebDAV XML document. This is what makes a Web Storage System folder look like a database table.

In addition, each item in a folder is not restricted to having the exact same set of properties as the other items in the folder. It is possible to dynamically add a property to any individual item, completely independent of the other items in the folder.

Figure 6: Web Storage System: folders, items, and properties

Certain properties have special well-defined meanings and importance. One key property is the Boolean property DAV:isfolder. The isfolder property determines whether an item is a simple item or represents a collection (or subfolder) of additional items. This is how the Web Storage System's hierarchical folder store is implemented. That is, some items in a folder may have an isfolder property value of True, implying the item is a logical subfolder. The ADO GetChildren method can then be called on the item's Record object to return the list of items in the subfolder.

Each item in the Web Storage System has a unique, friendly URL that is used to identify and access the item. For items in private mailboxes, the format of the URL is:

https://server/exchange/userid/folder/.../subject.suffix

For items that live under a TLH, the format is:

https://server/TLHname/folder/.../subject.suffix

An item can also be any document, including an e-mail message, calendar appointment, contact, any Office document, an HTML page, ASP page, XML document or audio or video stream. Let's look at some more real-life examples.

The URL for an e-mail message sitting in my personal Inbox might look like:

https://ec3-tor-11/exchange/mherman/Exchange%202000%20Development.EML

The URL for a contact item in a public folder might look like:

https://ec3-pfs-04/public/EC3/Shared/Contacts/Michael%20Herman.EML

Items and content classes as ready-to-use Web Storage objects

Another key item property is DAV:contentclass. Most applications and services built on Exchange 2000 Server and the Web Storage System use the contentclass property of an item to determine the type of object that item represents. For example, a contentclass value of urn:content-classes:message implies that the item is an e-mail message and should have its properties chosen from those appropriate for an e-mail message. Other important contentclasses include urn:content-classes:appointment, urn:content-classes:person, and urn:schemas-microsoft-com:exchange:workflowprocessdefinition. Person is the contentclass value used for Contact items. The Web Storage System provides schema and property definitions for more than 30 common object contentclasses. Like property names, contentclass names are also qualified by the XML namespace they belong to—either one of the intrinsic Web Storage System namespaces or your own custom application or organization specific namespace.

MAPI applications such as Outlook 2000 maintain a similar item property known as the PR_MESSAGE_CLASS (officially, https://schemas.microsoft.com/exchange/outlookmessageclass). Client applications can use the contentclass property to determine how an item (and its list of properties) should be displayed to the user. If the contentclass is person, then OWA 2000 will render the item as a contact using HTML, while Outlook 2000 will use a built-in Outlook Contact form to display the item's properties. In the Outlook 2000 example, the equivalent PR_MESSAGE_CLASS value is IPM.Contact. To have OWA 2000 and Outlook 2000 forms behave properly for the same set of contact items, both the contentclass and PR_MESSAGE_CLASS property values have to be set appropriately.

As far as the Exchange 2000 Server and the Web Storage System is concerned, the content of a folder is simply a list of items—each item with its own list of associated properties. In addition, some items may have the isfolder property set to True, indicating that they are subfolders of additional items.

To avoid pandemonium, contentclass names are also used to name XML-based schema items called content class definitions. Content class definitions define the list of properties that are expected for a particular class of object in the folder store. The way a client application chooses to display an item is totally up to that application (and normal usage conventions). An item's contentclass property simply provides the name of the item's object class.

It is also possible to derive new solution-specific contentclass schema from the intrinsic contentclasses or create brand-new contentclasses from scratch. As you have likely guessed, schema and property definitions themselves are simply items that have their own special contentclasses: urn:content-classes:contentclassdef and urn:content-classes:propertydef.

Most applications are expected to create their own schema folder that is global only to the instances of that particular solution.

ADO or WebDAV? It's your choice

In addition to directly accessing items or objects in the Web Storage System using their URLs, queries can also be executed against the folder store. Regardless of whether you choose to use ADO or the WebDAV protocol, the same underlying query processor processes them all. ADO is familiar to most Windows developers but with the Exchange 2000 Server version of the Web Storage System, it has the limitation that it can only be used by client or server applications that run on the same machine as the Web Storage System, so the Web Storage System OLE DB provider is not natively remotable.

For developers familiar with ADO, there is a provider known as the OLE DB Provider for Internet Publishing (MSDAIPP) that runs on top of WebDAV (as well as the FrontPage WEC protocols) that supports remote ADO connections. You can read the About the OLE DB Provider for Internet Publishing Guide for additional information.

Note: The Web Storage System version of CDO is not remotable with either the Web Storage System or MADAIPP OLE DB provider.

WebDAV is a set of extensions to HTTP that are remotable by definition and the parameters of the extended requests are formatted as XML documents. After the query processor executes the query against the folder store, it returns the results as an XML document to the requesting application.

For both ADO and WebDAV queries, familiar SQL query language syntax can be used. SELECT *, LIKE, WHERE, ORDER BY, GROUP BY, CONTAINS, FREETEXT, and column aliasing are supported; JOIN and MAX, MIN, SUM, and so on, are not. In addition, the SCOPE option on the FROM clause can be used to specify whether only the current folder (and no subfolders) should be searched or whether the current folder and all subfolders should be searched. The former is referred to as a SHALLOW search, while the latter is a DEEP search. Here is an example:

SELECT Name, WorkPhone, CellPhone FROM SCOPE('DEEP TRAVERSAL OF "<folder URL>"')

Extending Web Storage System functionality

Many types of solutions can be developed using the data access methods described above. However, there is often a need to extend the functionality of the Web Storage System. This can be accomplished through two mechanisms:

Traditional middle-tier components (referred to here as front-end Web Service components)
Event-driven back-end components

Front-end Web Service components. Referring to Figure 4, the middle-tier or front-end Web Service components are used to wrap any of the intrinsic or custom objects in the folder store with additional functionality, and in the case of a Web Service, are often used to expose the capabilities of a class or group of classes as a .NET Web Service.

Event-driven back-end components. While middle-tier components can be used to enforce business rules, they only apply to those applications that actually call the middle-tier components. A more effective approach is the use of event-driven back-end components as shown in Figure 4.

Any change to an item in the Web Storage System, whether it be to a simple item or a folder, can cause an event to be raised resulting in some custom code being executed. The executed code is called an event sink. In the Exchange 2000 Server version of the Web Storage System, event sinks are implemented as COM+ or scripted components.

When an event sink is registered for a particular event in a particular folder, the Web Storage System passes an event information structure that includes an ADO record for the item that was created, changed, or deleted. In addition, event sink registrations stipulate whether the sink is to be executed synchronously or asynchronously relative to the change being made to the item.

Workflow-Enabling Web Storage Objects

In addition to being able to develop the store-level event sinks mentioned above, the Exchange 2000 Server workflow engine and the Workflow Designer for Exchange 2000 Server work together to implement a higher-level set of workflow event services.

Workflow engine

In the Exchange 2000 Server version of the Web Storage System, the workflow engine is implemented as a COM+ component. Besides the inherent performance and manageability advantages of running the workflow engine under COM+, the Web Storage System leverages the role-based security model of COM+ to determine who is able to workflow-enable the Web Storage System objects in a particular folder.

The workflow engine implements the low-level store event sink interfaces so that the engine is called whenever a change occurs in a workflow-enabled folder. The workflow engine in turn exposes a set of higher-level workflow events to the Workflow Designer.

Workflow Designer for Exchange 2000 Server

The Workflow Designer for Exchange 2000 Server is a visual designer for workflow enabling Web Storage System folders and items. It ships as part Microsoft Office 2000 Developer Edition 1.5. The design surface is used for drawing state-transition diagrams representing a business process. The nodes represent the states that a particular item or document can be in at a given instant. An arrow is drawn between two states whenever it makes sense from the perspective of the business process. The arrow is representative of a transition from one state to the next. A transition is protected by a condition that controls when an item is allowed to change from the current state to a new state. Typically, the condition will test one or more properties in the changed item's ADO record object that is automatically made available when the workflow event is raised. As part of the transitioning from the current state to the next, a Visual Basic Script action script can be executed to access some external functionality, such as sending an e-mail notification or integrating with BizTalk Server's .NET Orchestration process integration capabilities.

Using the Web Storage System for Mobile and Offline Solutions

Currently, the Web Storage System is only available as a server-side technology that ships with Exchange 2000 Server, and will be available in the future with the Tahoe release, Microsoft's Web Storage System-based collaboration server product.

A future version of Office will also include a client-side version of the Web Storage System that will support automatic caching of server-side Web Storage System content, as well as generic Web content. In addition, the local Web Storage System will also support subscription-based replication of server content to the local store. Furthermore, the local Web Storage System is capable of hosting fully dynamic Web sites through client-side support for Active Server Pages (ASP). This capability will enable many new categories of fully operational, dynamic, disconnected mobile and offline solution scenarios.

The Big Picture

The following diagram depicts how three types of client applications can access and update an item's properties.

Figure 7: a The client-side big picture

MAPI clients, Outlook 2000 for example, can create new items, update the properties of existing items, or delete individual items or item properties. Similarly, by using the Web Storage System's rich set of APIs and Internet protocols, traditional Visual Basic, as well as Web server applications, can interact with and change the single instance of the very same items.

Additionally, item changes made by these client applications can trigger event-driven back-end logic, including the workflow processes running in Exchange 2000 Server workflow engine. The Workflow Designer for Exchange 2000 is used to create and update business processes that are saved in workflow definition (WFD) files. WFD files can be stored in each workflow-enabled folder or in a common application folder similar to the way that contentclass schema items are shared. The following diagram depicts how event-driven back-end workflow logic can respond to the creation of new items or changes made to an existing item.

Figure 7: b Back-end event-driven big picture

When a user double-clicks or otherwise indicates that they want to open an item, it's the application that first looks at the contentclass (or PR_MESSAGE_CLASS) and browser parameters to determine the appropriate Web UI or form to be used to display the properties of the selected item.

Web Storage System and the .NET Platform

The following diagram illustrates how the Web Storage System is addressing the requirements of the .NET Framework today. A later section, Looking Forward, takes a peek at the new .NET features the Exchange development team is looking to deliver over the next few releases of the Web Storage System.

Figure 8: The Web Storage System and .NET Framework

Web Services

The SOAP Toolkit for Visual Studio 6 can be used today to quickly develop custom Web Services for the Web Storage System. The Exchange Server Downloads at https://msdn.microsoft.com/exchange/ and https://msdn.microsoft.com/library/en-us/soap/htm/kit_intro_19bj.asp are both excellent sources. While the SOAP Toolkit makes it easier to develop and connect to Web Services, the SOAP family of protocol standards doesn't require a particular toolkit or platform to realize the benefits of Web Services.

Included in the SOAP Toolkit is the infrastructure necessary to expose SOAP Web Services on Windows operating systems and to consume them using Visual Studio 6.0. The SOAP Toolkit automates all the key elements of creating a Web Service.

If you have an existing COM component, the SOAP Toolkit makes it easy to turn it into a Web Service and to consume it in, for example, Visual Basic. The SOAP Toolkit includes a tool that will extract the type library from an existing COM component and turn it into a SOAP Contract Language (SCL) contract that represents that component's capabilities, such as interfaces, methods, and properties. It will also produce the files necessary to implement the service for consumption by other applications. You can also generate this contract by hand.

Once you have a contract, the toolkit includes an extension for Visual Studio that will automatically turn the contract into a proxy that you can program against just like a local COM component. The Toolkit also contains SOAP listeners that receive SOAP calls and directs them to the appropriate service.

Web Services are most frequently invoked using conventional SOAP remote method invocation protocols. SOAP is supported by the following XML-based standards: XML Schema Datatypes (XSD) for schema definition, the SOAP Discovery protocol, the Service Contract Language (SCL), and the Simple Object Access Protocol (SOAP) protocol itself. In addition, data remoting Web Services use XML/HTTP protocols such as WebDAV. See the Data and XML section for additional details.

Web UI

To support rapid development of Web UI, the Web Storage System includes three key technologies:

Web Storage System Forms, including the Forms Registry and the EXWFORM Web Storage System Forms forms renderer.
Outlook Web Access for Exchange 2000 Server Web components.
Outlook and Instant Messenger view controls.

Forms registration properties are stored in separate items or objects called Forms Registrations. The forms registry properties determine the Web UI to be used to render properties of the item based on the item's contentclass and a variety of other criteria, including the user's browser type, request type, query string parameters, and so on. The Web UI to be used can be identified by a conventional URL or the pathname of a custom forms renderer DLL on the Web Storage System server. Custom forms renderer DLLs run as an extension to an ISAPI application implying that they can be performant and scalable. Outlook Web Access for Exchange 2000 Server is implemented as one of these DLLs. An intrinsic or custom forms renderer has access to the set of HTTP request headers, as well as an ADO record of properties for the item requested by the user's browser.

The Web Storage System ships with its own intrinsic forms renderer: EXWFORM Web Storage System Forms. Developers create Web Storage System Forms in a similar manner to ASP pages or Web pages that use DHTML dynamic data binding. EXWFORM forms provide a number of shortcuts that reduce or eliminate the need for any actual script code in the page. All Web Storage System forms renderers (intrinsic or custom) execute server-side.

Lastly, OWA 2000 exposes most of Outlook 2000's client functionality as a Web component-based Web UI. OWA 2000 can be used as a complete e-mail client with access to e-mail, calendar appointments, and contacts, plus access to all your private and public folders. In addition, developers can use each component of the OWA 2000 Web UI to automatically render rich calendars, contact lists, e-mails, and threaded discussions in their own collaborative Web solutions.

Data and XML

To support the transport of relational data and XML through the .NET Framework, the Web Storage System supports ADO 2.5, WebDAV, and Web Services.

ADO provides the server-side data access object model that is familiar to most Visual Basic and ASP developers. WebDAV, the W3C Distributed Authoring and Versioning protocol, supports data remoting using an XML-based HTTP request and response protocol. Data returned by a WebDAV request can be accessed through the XML Document Object Model (DOM) or as a remote ADO Recordset through the OLE DB Provider for Internet Publishing (MSDAIPP) (sometimes known as "Rosebud"). For more information, refer to the Hierarchical Object Store section of this paper.

Lastly, applications can use the XML/HTTP-based SOAP suite of protocols to perform method invocations against services running on a remote Web server and the results are returned as SOAP-formatted XML documents.

Component Run-time Environment

For the Exchange 2000 Server version of the Web Storage System, the supported component run-time environment is COM+.

Base Classes

Excluding the server-to-server transport protocols, there are six categories of base classes supported in the Exchange 2000 Server version of the Web Storage System:

Client access protocols and APIs
Data access
Installable file system (IFS) driver
Collaboration Data Objects (CDO)
Real-time collaboration
Events

Details on the APIs and protocols that belong to each group can be found in the Microsoft Web Storage System section of this paper.

Visual Studio and Office

For rapid application development and high developer productivity, great tools, in addition to a great platform, are required. For building .NET applications and services today, Visual Studio 6.0 and Office 2000 Developer Edition (including Outlook 2000, FrontPage 2000, and the Workflow Designer for Exchange 2000 Server) are the key tools.

Federated Web Services Model

There are two primary approaches to building collaborative solutions with Web Services: simple and federated. A simple Web Service is implemented on a single Web server and exposes a single Web Service. In Figure 9, Server X, Server Y and the Travel Broker Web sites expose Simple Web Services and applications make direct calls to the methods advertised by these Web Services.

As Web Services evolve, specialization will occur as specific servers take on specific responsibilities—from either a functional or horizontal scaling or reliability perspective. Server X and Server Y in the figure below are examples. This situation, however, leads to a complication for developers, operations people, and Web Services consuming applications when a Web Service moves from one server to a second or third server. The answer is federated Web Services and UDDI.

Federated Web Services are advertised on a single, well known front-end Web server called the master Web server, while the Web Services components may execute on any number of middle-tier servers. Applications wishing to connect to a Web Service simply access the SOAP contracts on the master Web server and the remote method invocations will automatically execute against the appropriate middle-tier servers. An excellent choice for a master Web server for many types of users will be their Exchange front-end messaging and collaboration servers. As Web Services evolve, UDDI registries will become the more obvious choice for advertising business and technical information about an organization's Web Services.

The federated Web Services advertised on the Exchange server can include:

Local, out-of-the-box Exchange Web Services
Local custom Web Services
Federated Web Services from any number of internal or external .NET servers.

This scenario is depicted at the top of Figure 9.

Figure 9: Rich federated Web Services model

The last scenario depicted in Figure 9 is a brokered call. A brokered call occurs when one Web Service makes a call to another Web Service on behalf of the original calling application. In Figure 9, the Exchange server is exposing a federated Web Service being called by Outlook. If the operation requested by the Outlook user is a vacationbooking request, the Exchange server will broker that call to a Web Service running on the travel agent's Web site.

In addition, Web Service federation allows organizations to decide whether to run their own infrastructure or host it externally without compromising their ability to control or access Web Services.

Travel Agency Collaborative Scheduling Example

Let's look at the vacation booking scenario first described in the Web User Experience section. An Outlook user wants to book a vacation. In theory, some or all of the following information may be necessary to complete the booking process with a travel agent:

preferred travel times
vacation destination
hotel preference
rental car
special dietary considerations
smoker/non-smoker preferences
preferred rental car agency
airplane seating preference
frequent flyer account numbers
payment information

The travel agent may already have some or all of the above information. However, it may not be the most recent information or the person may be booking with a travel agent they've never used for personal travel. We'll first work through a design that leverages the federated Web Service paradigm, and then we'll look at an inefficient approach.

Rich federated Web Services example

In the rich federated Services model above, the Outlook user has either an Outlook Appointment form or Web form that has been customized for personal vacations. First, the form will need to be registered with a new contentclass, say, urn:content-classes:vacationbooking. The Outlook outlookmessageclass also needs to be set appropriately. The schema for this contentclass could include one property for every piece of information from the above list but why bother? Only the first three or four pieces of information are unique to most vacations. When do we want to go? Where do we want to go? Where do we want to stay? Do we need a rental car?

These properties need to be part of the vacationbooking contentclass schema. However, if the vacationbooking contentclass is derived from the Appointment contentclass, only the destination, hotel, and rental car properties need to be added to the new schema and the new vacationbooking appointment form.

When a new item is added to the Outlook user's calendar, the event sink in the workflow engine is executed and a condition checks to see if the value of the new item's contentclass is vacationbooking. If it is, then the workflow for this item will transition to the next state in the business process and the action script associated with the transition is executed. The action script would initiate a brokered call to the Web Service exposed by the travel agent's Web site passing on the four pieces of information gathered by the vacationbooking form.

Any good travel agent would then ask about your other preferences in addition to your method of payment. How is this accomplished? If the travel agent calls back on the phone or sends an e-mail, the information might as well have been entered on the original vacationbooking form. However, what happens instead is that the travel agent's application executes its own remote method or data access call against a secondary Web Service on the Outlook user's Exchange server. This service provides the user's preference information to authorized users like the travel agent. The preference information is stored in one location as an item in the Outlook user's private folders. The information is always current and secure.

Inefficient Web Services architecture

To highlight the value of the above approach, consider the inefficient Web Services architecture depicted in Figure 10 for the same vacationbooking scenario. In this scenario, there is no workflow, no brokered call to the travel agent's Web Service is possible, and no callback Web Service on the Exchange server is available for providing preference information.

Figure 10: Inefficient Web Services architecture

In this scenario, additional client-side code would gather all the required information into a large remote method invocation against the travel agent's Web Service. If any additional preference information is required, the travel agent's application would call back to where? Presumably, the application would call the vacationbooking code running inside of the Outlook client. More likely, the travel agent will e-mail or call for the additional information and the Outlook user would manually retrieve it from an item in their private folders, resulting in wasted time and delays.

These two scenarios highlight the practical vision that the .NET Platform and Framework represent with a specific focus on the value of Web Services.

Looking Forward

Looking forward over the next few releases of the Web Storage System, additional support will be provided for each component of the .NET Framework.

From a Web UI perspective, Web Storage Systems Forms will continue to evolve through the integration of ASP+. The implementation of the Forms Registry and Outlook Web Access for Exchange 2000 Server Web UI components will also continue to improve over time.

From a Data and XML transport perspective, the Exchange Managed Provider will provide support for ADO+ Datasets including extendible caching and persistence of data out to any tier in your solution architecture. Data within an ADO+ table may be accessed as a relational table (similar to an ADO Recordset), as an ADO+ XML Datadocument, or as a conventional XML DOM object.

In addition, expect to see tighter integration of the Web Storage System with the .NET Common Language Runtime.

Conclusion

The Microsoft .NET Platform will revolutionize computing and communications in the first decade of the 21st century by being the first platform that takes full advantage of both. Microsoft .NET will make computing and communicating simpler and easier. It will spawn a new generation of Internet services and enable tens of thousands of developers to create revolutionary software for online services and businesses. It will put you back in control and enable greater control of your privacy, digital identity, and data.

The Exchange 2000 Server product team would appreciate receiving your feedback on Exchange 2000 Server's Microsoft .NET strategy. Please send your comments to e2knet@microsoft.com.

For more information:

https://www.microsoft.com/exchange/

https://msdn.microsoft.com/exchange/

https://msdn.microsoft.com/wss/

Programming Microsoft Outlook and Exchange, 2nd Edition

Acknowledgements

This paper would not have been possible without the support of the Exchange 2000 Server product team and the significant contributions, inspiration, and passion of Gordon Mangione, Alex Hopmann, Brent Ingraham, Harry Katz, Keith McCall, Chris Vandenberg, Thomas Rizzo, Lyle Curry, Jeff Wierer, Kevin Hunter, Bill Skilton, and the Microsoft EC3 Enterprise Consulting Competency Centers team.