MAPI et RCP sur HTTP

Dernière rubrique modifiée : 2005-05-23

Lorsque le service de transport Exchange Server est configuré dans Microsoft Outlook, Outlook utilise MAPI pour communiquer avec le service de banque d'informations d'Exchange. Ces appels MAPI reposent tous sur le RPC. Bien que les appels RPC fonctionnent parfaitement dans un environnement LAN (réseau local) ou WAN (réseau étendu), leur utilisation est généralement déconseillée sur Internet à cause du pare-feu et d'autres mécanismes de sécurité. Avec les versions précédentes d'Exchange, les utilisateurs Outlook externes qui souhaitaient obtenir un accès MAPI à Exchange devaient d'abord établir des connexions VPN au réseau privé de leur organisation.

Le serveur proxy RPC s'exécute sur un ordinateur IIS. Il accepte les demandes RPC provenant d'Internet, se connecte efficacement via Internet aux programmes du serveur RPC et exécute des appels de procédure distante sans exiger une connexion VPN au préalable. Il effectue également des opérations d'authentification, de validation et de vérification d'accès sur ces demandes sans ouvrir plusieurs ports sur votre pare-feu. Le tout à l'aide d'un intermédiaire appelé proxy RPC sur HTTP ou proxy RPC.

Si la demande réussit tous les tests, le proxy RPC transfère la demande au serveur RPC qui se charge du traitement effectif. Avec RPC sur HTTP, les serveur et client RPC ne communiquent pas directement. Ils utilisent un intermédiaire : le proxy RPC.

RPC sur HTTP permet aux programmes clients d'utiliser Internet pour exécuter des procédures qui sont fournies par les programmes serveur sur des réseaux distants. RPC sur HTTP achemine ses appels via un port HTTP établi. Par conséquent, ses appels peuvent traverser les pare-feu réseau sur les réseaux aussi bien client que serveur. Le proxy RPC est situé sur le réseau du serveur RPC. Le proxy RPC établit et gère la connexion au serveur RPC. Il sert de proxy, en distribuant les appels de procédure distante vers le serveur RPC et en renvoyant les réponses du serveur via Internet au programme client.

RPC sur HTTP a des exigences aussi bien côté serveur que côté client, qui sont détaillées dans le tableau suivant.

Lorsque le programme client émet un appel RPC et utilise HTTP comme transport, la bibliothèque d'exécutables RPC sur le client contacte le proxy RPC. Selon qu'il a été demandé au client RPC d'utiliser HTTP ou HTTPS, c'est respectivement le port TCP 80 ou TCP 443 qui est utilisé. Le proxy RPC contacte le programme du serveur RPC et établit une connexion TCP/IP. Le client et le proxy RPC maintiennent leur connexion HTTP ou HTTPS via Internet.

La connexion HTTP ou HTTPS du client au proxy RPC peut, le cas échéant, passer à travers un pare-feu (sous réserve des autorisations d'accès appropriées). Le serveur peut alors exécuter l'appel RPC et utiliser la connexion via le proxy RPC pour répondre au client.

Si le client ou le serveur se déconnecte pour une raison ou une autre, le proxy RPC détecte que la connexion a été interrompue et met alors fin à la session RPC. Tant que la session se poursuit, le proxy RPC maintient ses connexions avec le client et le serveur. Il achemine les appels RPC du client vers le serveur et transmet des réponses du serveur au client.

Le programme client RPC peut acheminer ses appels RPC via Internet en créant une liaison de chaîne au format suivant :

[object_uuid@]ncacn_http:rpc_server[endpoint,HttpProxy=proxy_server:http_port,'rpcproxy'=rpc_proxy:rpc_port]

Où :

• object_uuid spécifie un identificateur unique universel de l'objet RPC.
• ncacn_http sélectionne la spécification de la séquence de protocoles pour RPC sur HTTP.
• rpc_server est l'adresse réseau de l'ordinateur exécutant le processus du serveur RPC. L'adresse du serveur doit être spécifiée dans un format visible et compréhensible, non pas pour le client mais pour l'ordinateur proxy RPC. Dans la mesure où le client ne se connecte pas directement au serveur, il ne résout pas le nom du serveur et n'établit pas de connexion avec celui-ci. Le proxy RPC établit la connexion au nom du client. Par conséquent, rpc_server doit être un nom reconnaissable par le proxy RPC.
• endpoint spécifie le port TCP/IP que le processus du serveur RPC écoute pour les appels RPC.
• HttpProxy spécifie facultativement un serveur proxy HTTP sur le réseau du client RPC, comme Microsoft Proxy Server. Si un serveur proxy est sélectionné, aucun numéro de port n'est spécifié, le stub RPC utilise le port 80 par défaut si le protocole SSL n'est pas demandé et le port 443 si le protocole SSL est spécifié.
• RPCProxy spécifie l'adresse et le numéro de port de l'ordinateur IIS qui agit en tant que proxy pour le compte du serveur RPC. Vous ne devez spécifier ceci que si le processus du serveur RPC réside sur un ordinateur différent du proxy RPC. Si vous ne spécifiez pas de numéro de port, un stub client RPC utilise par défaut le port 80 si le protocole SSL n'est pas spécifié et le port 443 si le protocole SSL (HTTPS) est spécifié.

Bien que RPC sur HTTP soit une fonctionnalité de Windows Server 2003 et non une fonctionnalité des services IIS, elle est implémentée en tant qu'extension ISAPI (Internet Server Application Programming Interface) qui s'exécute dans un serveur virtuel de protocole. Le répertoire virtuel RPC est créé sous Site Web par défaut lorsque le service proxy RPC est installé. Vous devez utiliser SSL en association avec l'authentification de base.

Si RPC sur HTTP est implémenté en tant que serveur virtuel de protocole, ExIPC n'est pas impliqué dans le processus de communication. Les clients Outlook utilisant RPC sur HTTP sont traités comme des clients MAPI classiques et ils communiquent avec le service de banque d'informations de Microsoft Exchange via l'interface MAPI de la banque d'informations d'Exchange.