Exchange ActiveSync–de hol a hiba?

Egy napon belül kétszer kellett elmesélnem ezt a történetet két kollegámnak. Egy héten belül háromszor mondtam el és két ügyfelemnél is elojött ez a kérdés így ma megfogadtam, hogy a nap addig nem ér véget számomra, amíg ezt nem írom ki magamból. Miért? Azért, hogy hatékonyabb lehessek, elég legyen csak az újabb érdeklodoket a blogomra irányítani. Illetve azért, hogy a telefonok kiválasztásának amúgy sem egyszeru szempontrendszerét további dimenzióval egészíthessem ki.

Egyszer volt, hol nem volt, volt egyszer egy Exchange Server. Az Exchange Server adatbázisában volt sok postaláda. A postaládákban sok elem. A zsebünkben pedig volt egy telefon. Néhány kollegámnak eszébe jutott a ’90-es évek végéhez közeledve, hogy a leveleket, a naptárat a névjegyeket egyaránt szinkronizálhatnánk a postaládánkkal. Ráadásul úgy, hogy ahhoz nem kellene asztali gép, nem kellene Outlook kliens. Interneten keresztül, közvetlenül az Exchange Server-el. Így aztán sok fejlesztés után elkészült, dobozoltuk, majd árultuk a Microsoft Mobile Information Server (MMIS) terméket. Létezett ebbol a termékbol több verzió is, a történelmét ennek nem írom most le, de egy évtizede már létezett (a Microsoft-ban az elso nagyobb munkáim egyike az MMIS-hez kapcsolódik). Az MMIS termékben már az ActiveSync protokollt használtuk arra, hogy a mobil készülék és az Exchange kiszolgáló között szinkronizálni tudjuk az adatokat. Nincs ez másként ma sem. Az ActiveSync protokoll azóta a szokásos evolúción ment keresztül. Fejlodött, bovült, szabványosodott. Ahogy ez lenni szokott. Az MMIS termék megszunt, de nem jogutód nélkül, bekerült a termék az Exchange kiszolgálóba így lényegesen egyszerubbé téve a szlogen megvalósítását: „Information Anytime, Anywhere, from any device”. Tehát a protokoll szabvány lett. Adott egy szabványos protokoll, de mire jó ez? Valójában az ActiveSync protokoll arra és csak arra szolgál, hogy a telefonkészüléken futó e-mail kliens és az Exchange kiszolgáló között az adatátvitelt biztosítsa. Hogy egy telefonkészüléken futó levelezést, naptárkezelést, névjegykezelést futtató alkalmazást a protokollon keresztül megkapott adatokkal mit csinál valójában, azokat hogy dolgozza fel, az már nem a protokoll hatókörébe tartozó kérdés. Napjainkban ez sok problémát okoz és az ido elore haladtával egyre többet fog okozni.

Réges-régen ez nem jelentett problémát. Mert az ’ActiveSync = Windows Mobile’ készülék egyenlet igaz volt. Ma azonban ez már nem igaz. A készülékek százai, a gyártók tucatjai, az operációs rendszerek sokaságában ott van az ActiveSync protokoll. De mindegyik készüléken ugyanaz a levelezo kliens fut? Mindegyik készüléken ugyanazok a funkciók vannak implementálva? Az összes készüléken a levelezo kliens hibátlanul muködik? A válasz sajnos az, hogy nem. Problémák tucatjait okozza az, hogy a különbözo eszközök másként kezelik a naptár, az email, a névjegy bejegyzéseket a postaládánkban, majd a szabványos és helyesen muködo protokollon keresztül az szinkronizálódik a postaládánkba. A protokoll a hibás? Csak annyira, mint amennyire egy képzeletbeli világban a a postás hibáztatható lenne azért, ha egy meggondolatlan pillanatban írt levelet elviszi a postára, majd egy másik postás azt a címzetthez juttatja. Ahogy a postás sem hibáztatható, az ActiveSync protokoll sem vonható felelosségre. Csak teszi a dolgát és továbbítja a tartalmat a készülék és az Exchange Server között.

„Technikaibban” megfogalmazva, a „Business Logic Layer” készülékenként eltér. Az elemek kezelésének implementációja ebben a rétegben történik. Így ha ebben a rétegben hiba van, nem konzisztens, akkor annak hatása súlyos és érzékelheto. Minél több „Business Logic Layer” implementáció létezik, annál több problémával szembesülhetünk és sajnos szembesülünk is. A leggyakoribb problémák:

• Nem szinkronizál a készülék
• Elvesznek, összekeverednek a névjegyek
• Naptárbejegyzések területén a legkülönlegesebb hibák tapasztalhatóak (n meghívott után eltunnek, ismétlodo bejegyzések módosításakor nem konzisztens, hogy melyik bejegyzésen mit állítunk)
• Levelek újraküldése örökké
• Nem megy az AutoDiscover
• Stb.

A biztonságtechnika számomra az örök kedvencek egyike. Így nem állhatom meg, hogy legalább egy gondolat erejéig ne térjek ki ennek a biztonsági vonzatára. A biztonsági beállításokat minden esetben a Business Logic Layer hajtja végre. Az Exchange Server az ActiveSync protokollon keresztül elküldi a biztonsági házirendet (PIN kód kötelezo, PIN kód hossza, Local Wipe stb.). A Business Logic Layer azt a protokollon keresztül fogadja, majd:

• a helyes implementáció a beállításokat alkalmazza és visszajelzi a protokollon keresztül az Exchange kiszolgálónak, hogy sikeresen alkalmazta azt.
• a helytelen implementáció fittyet hány a házirendre, de visszajelzi a protokollon keresztül az Exchange kiszolgálónak, hogy sikeresen alkalmazta azt.

Kell-e ezt tovább magyarázni? A különbség a két metódus között nem csak látszat.

A megoldás önmagát kínálja. Ráadásul több is létezik. A leggyorsabb és legegyszerubb megoldás az, hogy készítsünk egy a megfeleloséget tanúsító nyílt programot. Normalizáljuk a készülékeken futó alkalmazásokat és tudjuk biztosítani azt, hogy az egyes implementációk, bár eltéroek, mégis egy közös funkciókészletet biztosítanak és azt ráadásul helyesen teszik. Mi, a Microsoft ezt a programot létrehoztuk. A program neve: Exchange ActiveSync Logo Program. A komplikáltabb elméleti megoldásról egy késobbi bejegyzésben majd írok.

Így biztosak lehetünk abban, hogy a logo program alatt muködo készülékek nem fognak problémát okozni a rendszereinkben, a postaládáinkban, az értékes információinkban. Minden más lutri. Nem szeretnék kitérni a gyártókra és azok megoldásaira. Beszéljenek a tények a program oldalán. Eszközválasztásnál vegyük fel ezt is a szempontrendszereink közé.

Zárszóként csak annyit, hogy ha furcsa jelenségeket látunk a postaládánkban, vagy furcsa jelenségeket jelentenek be hozzánk, akkor gyanakodjunk, és ne hagyjuk ki a számításból a telefonkészülékek vizsgálatát sem. A következtetést mindenki vonja le maga. A gyártók pedig javítsák ki a termékeiket!