다음을 통해 공유

MAPI HTTP

  • 아티클

Egy új protokollal gazdagodunk az Exchange Server 2013 SP1-ben. A részleteket lásd ebben az írásban.

Exchange Server 2013 esetében az Outlook kliens csak az úgynevezett Outlook Anywhere protokollon keresztül képes csatlakozni a szerverhez. Az Outlook Anywhere korábbi neve az RPC over HTTP, ami technikailag jobban kifejezi azt, hogy valójában mirol is van szó.

Az RPC over HTTP kapcsolódás során van egy RPC over HTTP kliens és szerver. Ez a protokoll alapvetoen nem Exchange szerver exkluzív protokoll. A Windows NT 4.0 Optiona Pack-al jelent meg eloször a szerver oldali komponens. Ez egy RPC proxy komponens, ami egy virtual directory valójában az IIS-ben. Ez fogadja a bejövo HTTP kéréseket és az rpcproxy.dll az RPC forgalmat kibontja és továbbítja a szerver RPC rétegén keresztül az RPC üzenet címzettjének. Ez egy teljesen általános proxy protokoll, amit bárki más is implementálhatott volna. Az Exchange és Outlook csapat a lehetoségre lecsapott és implementálta. Kevés más implementációról tudok, ilyen szélesköru megoldásról nem.

Az Outlook és Exchange szerver esetében az RPC over HTTP egészen új megoldás volt. Végre nehézkes VPN kapcsolat nélkül is teljes Outlook hozzáférést tudtunk és tudunk ma is biztosítani a felhasználóknak. Míg a 2000-es évek elején ez komoly gondot okozott - elérhetové tegye Internetol a teljes Outlook funkcionalitást - a helyi rendszerek üzemeltetojének, addig napjainkban a felho alapú technológiai megoldások esetében a felho üzemeltetoknek jelent komoly kihívást a teljes Outlook szolgáltatás biztosítása. De annyira nem, hiszen itt van az RPC over HTTP.

Az RPC over HTTP esetében az Outlook az RPC kliens. Az Exchange kiszolgáló pedig egy RPC szerver. Az Outlook az Exchange szerverrel -hogy még komplikáltabb legyen a kép-, valójában MAPI protokollon keresztül kommunikál. Ebben a környezetben tehát az RPC kliens valójában egy MAPI kliens, az RPC szerver pedig egy MAPI szerver. A feladat az, hogy a MAPI klienstol a MAPI szerverhez eljusson a kérés és vissza a válasz, mindez biztonságosan az Interneten keresztül. Ez ma a következo módon muködik:

  • A MAPI kliens elkészíti a MAPI kérést
  • A MAPI kérést egy RPC csomagba tesszük
  • Az RPC csomagot egy HTTP csomagba helyezzük és így küldjük át az RPC Proxy szervernek, ami az Exchange esetében a CAS vagy Front-End verziótól függoen
  • Az Exchange szerveren az IIS fogadja a kérést
  • Az rpcproxy.dll feldolgozza a kérést
  • Továbbítjuk az RPC csomagot a Mailbox vagy Back-End szervernek
  • Az RPC csomagból kiszedjük a MAPI kérést és azt feldolgozza az Exchange kód

Nagyvonalakban kb. ez történik. Persze a http transzport során még az SSL encrypt/decrypt megtörténik.

A megoldás kreatív, jól muködik. Azonban túl sok a komponens amit használunk. Ebben történik most lényegi és egyben architektúrális változás. Elkészült egy új protokoll aminek a neve a MAPI HTTP. Ennek a protokollnak a célja az, hogy a MAPI kliens közvetlenül HTTP-n keresztül legyen képes a MAPI szerverrel kommunikálni. Ezzel az RPC réteget szerver és kliens oldalon egyaránt kihagyva.

A szerver oldalon az új protokoll az Exchange Server 2013 SP1 berzióval jelenik meg. Az engedélyezheto és tiltható lesz Exchange organizáció szinten. Implementálva két új IIS virtuális directory formában lesz. Kliens oldalon a támogatás eloször az Outlook 2013 SP1 verzióban lesz az új megoldás.

Az Outlook Anywhere (RPC over HTTP) továbbra is változatlan módon muködik SP1 után is. Az új protokollt ismero kliens a Autodiscover kérésben jelzi azt, hogy ismeri a MAPI HTTP-t. Ezt a kérést érto Exchange szerver verzió az Autodiscover válaszában visszaküldi a MAPI HTTP beállításokat. Ebbol látható, hogy a régi kliens-új szerver és az új szerver-régi kliens verzió muködése nem okoz problémát.

Az új protokollról bovebb információ:

Comments

  • Anonymous
    January 01, 2003
    Az félmegoldás volt. ;)
  • Anonymous
    January 01, 2003
    Hello Balázs, Outlook 2010-hez is lesz implementáció. Az első video kb. 10 perc körül ott az info. ?? Ami a teljesítményt illeti: még nincsenek pontos mérőszámok. Gyorsulás sok módon elérhető, gyorsabb kapcsolódás, lekapcsolódás, kevesebb erőforrás használata stb. Ami jelenleg biztos, hogy a hálózati forgalom nő, de nem radikálisan. Ami szintén látszik, hogy a komplexitás csökken és a működés konzisztensebb. HTTP szempontból ma egy EWS vagy ActiveSync-hez képest az OA egészen máskéntműködik. Ha megy az OWA és az EWS és IIS szinten minden rendben van, ez még nem jelenti azt, hogy az OA is megy. A MAPI/HTTP-vel ehhez közelebb kerülünk. A legfontosabb tervezési célok: - komplexitás csökkentése - kisebb kitettség a hálózati szakadásoknak (pl. Wifi és LAN váltás) - új Authentikációs megoldások támogatása - tisztán meghatározható timeout értékek és viselkedés, szabványos kommunikáció Direkt módon ezt ígynem adod el a felhasználóknak. Ez egymérnöki termék. Áttételesen jobb lesz: gyorsabb kapcsolódás, konzisztens működés (a telefonom megy, az Outlook miért nem?). Remélem ez segít.
  • Anonymous
    January 30, 2014
    Gondolom esély sincs rá, hogy Outlook 2010 SP3-be belekerüljön. Ezzel kb mekkora gyorsulás érhető el, vagy van valami különbség a felhasználó szempontjából?
  • Anonymous
    February 01, 2014
    A törzsfejlődésből kihagytad a Secure RPC-t, de gondolom direkt :)
  • Anonymous
    February 25, 2014
    Exchange
  • Anonymous
    February 25, 2014
    A Microsoft letöltő központban elérhető az Exchange Server 2013 SP1. Exchange Server
  • Anonymous
    March 01, 2014
    Korábban már írtam arról, hogy az Exchange Server 2013 SP1 megjelenésével
  • Anonymous
    March 01, 2014
    Korábban már írtam arról, hogy az Exchange Server 2013 SP1 megjelenésével