Microsoft Exchange is based on industry standard technologies, ensuring an
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. |
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
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
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
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
While MAPI deals with instructions, the
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.
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
A
remote procedure call
is similar to a local procedure call in that it
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.
The Remote Procedure Call protocol is based on a protocol created by the standards
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
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. |
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
| 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
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-
|
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
Try to imagine what the American telephone system would be like if different
You might think that you could simply list people ‚ s
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
| 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
|
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).
|
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 |
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
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. |
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
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
|
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
| 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. |
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