Industry Standards

Microsoft Exchange is based on industry standard technologies, ensuring an open architecture and, therefore, extensibility (i.e., the ability to easily add on to the product). An adequate understanding of the standards used in Exchange will help in utilizing it. This section presents a brief explanation of the following standards:

• Messaging Application Programming Interface (MAPI)

• The Remote Procedure Call (RPC) protocol

• X.400

• X.500

  Note ‚  

  The Internet standards are also very important in Exchange, and they will be discussed in Chapter 2 and Chapter 7.

Messaging Application Programming Interface (MAPI)

To understand MAPI, you must first understand what an application programming interface is. At the code level, a program ‚ s functions are invoked through specific instructions. The collection of those instructions is referred to as an application programming interface ( API ). That phrase is appropriate because the API allows a programmer to interface with the functions of a program. For example, if a program has the ability to read a message, there is a specific API instruction, also called a function call, that can invoke that ability. If two programs need to interact, they must do so with an API they both understand. For example, if program A sends the instruction Read_Message 4 to program B, but program B understands only the instruction Message_4_Read, then the instruction will not be understood . Humans can use slightly different grammar and still understand one another, but computers are not that forgiving .

In the past, many client/server messaging products had their own APIs for the client/server interaction. If someone wrote a client program, it would work only with the messaging system whose API it used. If a user needed to connect to multiple messaging systems, multiple client programs were needed. See Figure 1.6.

Figure 1.6: Multiple messaging APIs require multiple programs.

Microsoft decided to remedy that situation by creating a standard messaging architecture, referred to as the Messaging API (MAPI). MAPI accomplishes two broad goals. One, it provides a standard API for client/server messaging interaction. This role makes MAPI a type of middle-ware, meaning that it stands in the middle between clients and servers. Some authors refer to middleware as the slash (/) between the words client and server . MAPI makes it possible for a single-client application to access different messaging servers. See Figure 1.7 for an illustration.

Figure 1.7: Accessing different messaging servers through MAPI

The second broad goal of MAPI is to provide a standard set of services to client messaging applications. These services include address books, message storage, and transport mechanisms. Even when using different types of MAPI applications, such as e-mail, fax, and voicemail, a user can access a single address book (a universal address book) and store different data types in the same folder (a universal inbox). The transport mechanisms relate to a single client application that can connect to different messaging systems. A single MAPI e-mail application can access an Exchange server, a Microsoft Mail post office, an Internet mail server, and others.

Although MAPI includes individual API instructions, it most often communicates those instructions in an object-oriented manner. An object is a container; in this context, it functions as a container of API instructions. The Microsoft specification for object-oriented programming is called the Component Object Model (COM). MAPI, OLE, ActiveX, and other technologies are part of the COM standard.

The original version of MAPI (called Simple MAPI) was developed by Microsoft. But in the subsequent version (MAPI 1), Microsoft worked with over 100 different vendors to develop an industry standard. Microsoft has also turned over the vast majority of the MAPI specification to standards organizations, while still taking a leadership role by including the core MAPI component with its Windows operating systems.

While MAPI deals with instructions, the next section discusses the protocols that enable those instructions to be passed between clients and servers.

Procedure Calls

You now know the instruction standard used by the Exchange client/server messaging applications, namely MAPI. But client/server applications are divided across physical machines. When a client issues a read instruction for a message, that message could be on the server. The server could understand that instruction and could send the message, but the instruction has to get to the server and the message has to get back to the client. MAPI does not handle those procedures. From MAPI ‚ s perspective, the physical distinction of the client and the server does not exist; it is transparent. Microsoft uses the Remote Procedure Call (RPC) protocol to pass instructions and data between machines. Before discussing the RPC protocol, we will first define what a procedure call is and then discuss the two types of procedure calls, local and remote.

Note ‚  

In Exchange Server 5.5 and earlier, servers in the same Exchange site relied on RPCs to transfer messages and directory information between them. Exchange Server 2003 and Exchange 2000 Server use SMTP to exchange this information between servers. You ‚ ll learn more about this in Chapter 2.

Procedure calls handle the transfer of instructions and data between a program and a processor or processors. When a program issues an instruction, that instruction is passed to the processor for execution, and the results of the execution are passed back to the program. Now, let ‚ s look at the two main types of procedure calls.

Local Procedure Calls

When a program issues an instruction that is executed on the same computer as the program executing the instruction, the procedure is referred to as a local procedure call . When Exchange Server components perform activities on that server, they issue instructions that are executed by that server ‚ s CPU or CPUs. That is an example of a local procedure call. Exchange uses a Microsoft protocol called the Local Procedure Call (LPC) to implement this mechanism.

Remote Procedure Calls

A remote procedure call is similar to a local procedure call in that it relates to the transfer of instructions and data between a program and processor. But unlike a local procedure call, a remote procedure call enables an instruction issued on one computer to be sent over the network to another computer for execution, with the results being sent back to the first computer. The computer making the instruction and the computer performing the execution are remote from each other. The transfer of instructions and data between the computers is totally transparent to the original program and to the user. To the program issuing the instruction, all of its instructions appear to be locally executed. Remote procedure calls are a key ingredient in distributed processing and client/server computing.

The RPC mechanism permits the optimization of performance by assigning different computers to do specific tasks . For example, some programs require lots of processor power, memory, or storage or all three. It would be impractical to give every computer running these applications the necessary levels of resources. But one specialized computer could be given, for example, four processors, 1 GB of RAM, and 200 GB of storage. Clients could use those resources through the RPC mechanism.

Because the request/reply aspect of RPC is intended to be transparent to the client program and user, the speed of network communication is a factor. The computers involved in an RPC session need to have a high-speed permanent link between them, such as a local area network (LAN) or a high-speed wide area network (WAN).

Exchange uses remote procedure calls in many of its communications. The protocol that Exchange uses to implement remote procedure calls is called the Remote Procedure Call (RPC) protocol. This protocol is discussed in the following section.

Remote Procedure Call (RPC) Protocol

The Remote Procedure Call protocol is based on a protocol created by the standards group Open Software Foundation (OSF) and is part of the OSF ‚ s Distributed Computing Environment (DCE) protocol suite. Microsoft includes the RPC protocol with their Windows Server 2003 and Windows 2000 Server operating systems. In older versions of Exchange (Exchange 5.5 and earlier), servers within an Exchange site transferred messages between themselves using RPCs. In Exchange Server 2003 (and Exchange 2000 Server), this functionality has been largely taken over by SMTP. RPCs are still used to communicate with Exchange 5.5 servers, but SMTP is now used for all communications between newer Exchange servers inside and outside the boundaries of a routing group.

When a user chooses to read a message, the client program issues a MAPI instruction (MAPIReadMail). The RPC protocol on the client transfers this instruction to the Exchange server where the message physically resides. This is called a request. The RPC protocol on the server receives this request, has it executed, and sends the message back to the client ‚ s screen. This is called a reply. RPC clients make requests , and RPC servers make replies. RPC is sometimes referred to as a request/reply protocol. RPCs are also used in some Exchange server-toserver communications. Figure 1.8 illustrates the RPC mechanism.

Figure 1.8: The Remote Procedure Call protocol

Note ‚  

Note that being an RPC client or server doesn ‚ t really have anything to do with being a messaging client or server. In the example in Figure 1.8, the messaging client is also the RPC client, but an RPC client is really just the computer that issued the RPC. Exchange servers often communicate information between themselves using RPCs. The computer that initiates the connection request is the RPC client, and the computer that receives the request is the RPC server.

CCITT X.400

For most of the history of electronic messaging in the private sector, there were no widely accepted messaging standards. Different messaging products used vastly different messaging protocols. This made interoperability between different systems difficult and costly, sometimes impossible . To address this situation, different standards organizations began to develop what they hoped would become internationally recognized messaging standards. One of those standards organizations was the Comite Consultatif International Telegraphique et Telephonique (CCITT). This is translated in English as the International Telegraph and Telephone Consultative Committee. One of the standards they developed was the X.400 Message Handling System (MHS) standard. Exchange uses some of the technologies of the X.400 standard.

Note ‚  

The CCITT is now a subdelegation of the International Telegraph Union (ITU), which is an agency of the United Nations. The State Department is the voting member from the United States.

The different versions of the X.400 standard are referred to by the year they were officially published and by a specified color . Versions to date are as follows :

• 1984 ‚“Red Book ‚½

• 1988 ‚“Blue Book ‚½

• 1992 ‚“White Book ‚½

  Note ‚  

  The Message Handling System (MHS) discussed in this section is not the same standard as the Novell- related Message Handling System (MHS).

X.400 is a set of standards that relates to the exchange of electronic messages (messages can be e-mail, fax, voicemail, telex, etc.). The goal of X.400 is to enable the creation of a global electronic messaging network. Just as you can make a telephone call from almost anywhere in the world to almost anywhere in the world, X.400 hopes to make that a reality for electronic messaging. X.400 defines only application-level protocols and relies on other standards for the physical transportation of data (e.g., X.25 and others).

X.400 Addressing: Originator/Recipient Address

Try to imagine what the American telephone system would be like if different parts of the country used different numbering schemes: different number lengths, different placement of the area code, etc. Obviously that would lead to a lot of complexity and problems; hence a standard numbering scheme exists. Electronic messaging also needs a standard addressing scheme to avoid the same sort of chaos.

You might think that you could simply list people ‚ s names in alphabetical order. But there are many problems with that scheme. The addressing scheme needs to be able to potentially scale to the entire world ‚ s population. An alphabetical list would be quite long. There is also the problem of what constitutes a last name ; different countries have different methods (e.g., Anwar el-Sadat, Willem de Kooning). A truly global addressing scheme needs to be totally unambiguous.

The addressing scheme that X.400 uses is called the Originator/Recipient Address (O/R Address). It is similar to a postal address in that it uses a hierarchical format. While a postal address hierarchy is country, zip code, state, city, street, and recipient ‚ s name, the O/R Address hierarchy consists of countries, communication providers (such as AT&T), companies or organizations, and other categories. Figure 1.9 and Table 1.2 present some of these categories, called fields .

Figure 1.9: X.400 Originator/Recipient Address example

The O/R Address specifies an unambiguous path to where the recipient is located in the X.400 network (it does not specify a path the message might take, only the path to where the recipient is located).

Note ‚  

In actual practice, this addressing scheme is not as standardized as Table 1.2 makes it seem, nor is it used in the standardized way. Although the address fields have always been specified, the order in which to write them was not specified until 1993. Consequently, you will see them written in different ways. Some X.400 implementations have modified the standard.

X.400 Message Format: Interpersonal Messaging (IPM)

X.400 also specifies the protocols for formatting messages. The most common one is called Interpersonal Messaging (IPM) and is used for e-mail messages. There are other protocols for other types of messaging, such as Electronic Data Interchange (EDI).

Table 1.2: X.400 Originator/Recipient Address Example

Field	Abbreviation/Example	Description
Country code	c=US	Country
Administrative Management Domain (ADMD)	a=MCI	The third-party networking system used (e.g., AT&T, MCI, Sprint, etc.)
Private Management Domain (PRMD)	p=WidgetNet	Subscriber to the ADMD (company name)
Organization	o=Widget	Name of company or organization
Surname	s=Wilson	Last name
Given name	g=Jay	First name

X.400 Message Routing: Message Transfer Agent (MTA)

Another very important X.400 protocol is Message Transfer Agent (MTA). MTA is the protocol that runs in the message routing machines (i.e., routers). MTA is like a local post office in that it receives and routes messages to their ultimate destinations. And just like a postal system (a snail -mail system), electronic messages can go through several MTAs before they arrive at their ultimate destinations. This type of delivery method is called store and forward. An MTA machine receives a message, stores it so it can calculate its next route, and then forwards it to either another MTA machine or its ultimate destination. This method eliminates the need for the sender ‚ s application and the recipient ‚ s application to perform any simultaneous actions in order to exchange data. A sender ‚ s message is simply packaged with all the necessary addressing information and is sent to the next store-and-forward MTA machine (i.e., router). That MTA can route it to the next MTA, and so on, until it reaches its final destination.

Other X.400 Information

While the X.400 standard does not define the protocols for the physical transportation of messages, it does specify what other standards it can use. They include the following OSI (Open Systems Interconnection) protocols:

• TP0/X.25

• TP4 (CLNP)

• TP0/RPC 1006 to TCP/IP

  Note ‚  

  TP stands for Transport Protocol.

Third-party X.400 networks that can be subscribed to include AT&T Mail, AT&T EasyLink, MCI Mail, Sprintmail, Atlas 400 (France), Envoy 100 (Canada), Telebox 400 (Germany), and Telecom Australia. Microsoft Exchange is an X.400 messaging product.

Note ‚  

Exchange Server 2003 does not support the TP4 protocol, unlike previous versions of Exchange.

CCITT X.500

The CCITT X.500 standard defines the protocols for a global directory service. A directory service is a database of information on resources. Resources can be user accounts, user groups, mailboxes, printers, fax machines, and many other items. These resources are officially referred to as objects. The information about an object, such as a mailbox, can include the owner of the mailbox and the owner ‚ s title, phone number, fax number, as well as many other types of information. The information about an object is referred to as its properties or attributes. A directory enables objects and their properties to be made available to users and administrators.

The directory ‚ s importance cannot be overstated. To use a telephone analogy, imagine the current global telephone system without telephone directories. The technology to make a call would be in place, but you would have a hard time locating a person ‚ s number to call. The creation of global electronic yellow pages could go a long way toward solving the ‚“I know it ‚ s out there, I just can ‚ t find it ‚½ problem.

To create a directory service, X.500 addresses two main areas:

Directory structure How resources should be organized

Directory access How one is able to read, query, and modify a directory

X.500 Directory Structure

The X.500 directory structure is hierarchical, which facilitates a logical organization of information. Figure 1.10 illustrates the X.500 directory structure, and Table 1.3 explains it.

Figure 1.10: X.500 directory structure example

Note ‚  

The X.500 terminology for the structure of a directory is the Directory Information Tree (DIT). The term for the information in the directory is Directory Information Base (DIB).

Table 1.3: Descriptions of X.500 Objects

X.500 Object	Abbreviation/Example	Description
Country	c=US	Country of the organization
Organization	o=Widget	Name of the organization
Organizational unit	ou=Chicago ou=Detroit	Subcategory of the organization
Organizational unit	ou=Sales ou=Education	Subcategories under the ou=Chicago
Common name	cn=JayWilson	Name of a specific resource (username, fax name, printer name, etc.)

To communicate the location of an object in the directory hierarchy, list the path to that object, starting at the top and moving down. This is called a Distinguished Name (DN). The DN of the example in Figure 1.10 is as follows:

c=US; o=Widget; ou=Chicago; ou=Education; cn=JayWilson

The differences between an X.500 address, the Distinguished Name (DN), and an X.400 address are due to their different purposes. A DN is the location of an object in the directory, whereas the X.400 address is the location of an object in a messaging system. Getting back to the telephone analogy, a DN is the location of a person in the phone book, and an X.400 address is where they are in the physical telephone system. This is illustrated by the fact that an X.400 address can include information about third-party messaging networks that are used to physically deliver a message, some examples being AT&T, MCI, and Sprint.

Note ‚  

The 1988 release of X.400 incorporated the use of a DN address instead of, or along with, an O/R address. Some implementations of X.400 also incorporated some of the X.500 fields, such as ou= x and cn= x .

A directory also puts a more natural interface on network resources. Many communication objects have long numeric identifiers that are hard to remember. A directory allows objects to be presented to users by a natural descriptive term. The directory then maps the descriptive term to the numeric identifier.

Note ‚  

X.500 has a 1988 version and a 1993 version.

Directory Access

Having a directory is only half the equation. Users and administrators must also be able to access it to read, query, and write to it. A user might query the directory for a printer on the fourth floor in the Sales department, and the directory could respond with the needed information about the printer. Other issues that must be addressed are security (e.g., who can access an object and modify its properties) and directory replication (a true global directory would need to be on more than one machine). These issues are addressed by directory access protocols.

The standard access protocol in the X.500 recommendations is the Directory Access Protocol (DAP). DAP is considered more of a model than a real-world protocol. This is because DAP is very computer-resource intense (i.e., heavy) on client machines, and the few implementations of it are proprietary. But a newer access protocol that is getting a lot of attention today is the Lightweight Directory Access Protocol (LDAP). LDAP is an Internet protocol derived from the X.500 DAP. One of the reasons LDAP is called lightweight is because it requires fewer computer resources on the client. While LDAP is an Internet protocol, it is designed to enable access to an X.500-type directory. Almost every major software vendor has pledged support for LDAP.