Játék az Exchange 12 első Beta verziójával

Körülbelül egy éve várom a találkozást Exchange 12-vel. Amikor már megelégeltem a várakozást, elhatároztam, hogy biztosra megyek: levelet írok a télapónak, hogy hozza el karácsonyra! Természetesen a télapó valóra váltotta a kérésemet, sőt, még egy kicsit előbb is elhozta várva várt játékomat: az Exchange 12 Beta 1-es verzióját. A termék első „publikus” verziója December 14-én látott napvilágot, tesztelésére 1,400 partner/ügyfél vállalkozott saját környezetében. A publikus szót azért tettem idézőjelbe, mert ez a verzió csak ezen vállalkozó szellemű partnerek/ügyfelek számára áll rendelkezésre, na és persze „gyáron” belül a kíváncsi felfedezőknek. A végleges verzió várhatóan 2006 végén – 2007 elején fog megjelenni.

A cikkem célja nem az Exchange 12 új funkcióinak tételes leltára, inkább az érdekesebb újdonságok felfedezése, bemutatása. A cikket úgy írtam, hogy feltelepítettem a terméket, és kipróbáltam azon funkcióit, amelyek leginkább érdekelnek. Először a termék architekturális változásait mutatom be, majd pár egyéb új funkcióját, végül az új API-kkal kísérletezem.

Telepítés

A telepítéshez mindenek előtt .net Framework 2.0 és Windows Installer 3.0, valamint a legutóbbi javítócsomagok megléte szükséges. A tesztem Windows 2003 SP1-en zajlott.

Telepítéskor ki kell választanunk, hogy melyik server role-t (lásd alább) szeretnénk telepíteni a szerverünkre, valamint meg kell adni az útvonalakat a bin és storage file-oknak, és ezzel véget is értek teendőink. A telepítő ezután minden telepítési lépést server role-onkénti csoportosításban mutat a képernyőn, naplószerűen láthatjuk, hogy mi sikerült és mi nem a különböző szerepek telepítéséhez. A telepítő először egy intenzív ellenőrzést futtat, amely még a telepítés megkezdése előtt leellenőrzi a telepítés minden előfeltételét. Ha egy szerep telepítéséhez minden feltétel teljesül, zöld pipa jelenik meg a neve mellett, egyébként piros X, valamint az instrukciók, hogy mit tegyünk a dolog javításának érdekében. Nekem az NNTP service-t kellett leszednem, valamint az Active Directory-t kellett Windows 2000 vagy Windows 2003 Native mode-ra állítanom. Ezek után a telepítés gyönyörűen, körülbelül 40 perc alatt lefutott.

Server Roles

Az Exchange 12 Server szerepei sokkal jobban körvonalazódnak, mint Exchange 2003 esetében: telepítéskor megmondhatjuk, hogy a telepítendő szerverünkre mely szerepeket szeretnénk ruházni:

• Gateway (Edge) services
• Bridgehead services
• Mailbox services
• Client Access services
• Unified Messaging services

Mindezeket össze-vissza variálhatjuk, egyetlen megszorítással: Mailbox role-t, és Gateway role-t nem tudjuk együtt kiválasztani. Ennek biztonsági okai vannak: ne rakjuk ki az Exchange mailbox szerverünket az internetre!

Fontos megjegyezni, hogy az Exchange 12 csak 64 bites operációs rendszeren fog futni.

A következőkben bemutatom a különböző role-okat külön-külön, utána viszont csak a store körüli API-kkal foglalkozom. Íme az 5 role nagyvonalakban:

Gateway (Edge) Services

A szerep lényege egy SMTP service, amely az internetről érkező leveleket fogadja. A termék tervezésénél talán erre a szerepre koncentrálódott a legnagyobb figyelem: a spam-ek és vírusok kiszűrése a lehető legnagyobb pontossággal, valamint a biztonságos email küldés a legfontosabb funkciók közé tartozik. A talán leginkább figyelemre méltó újdonság az, ha az interneten két Exchange 12 gateway server találkozik SMTP levél továbbításánál, az első alkalommal létrehoznak egymás között egy „secure channel”-t, amelyet minden elkövetkező üzenet továbbításánál használnak. Ennek köszönhetően az interneten továbbított levelek teljesen biztonságosan utaznak. Az SMTP service után/mögött kifinomult email-folyamatirányító funkcionalitás található, amely a beérkezett levelek megfelelő helyre történő irányításáért felelős. Ennek a role-nak semmilyen kapcsolata nincs a belső hálózattal a levél továbbküldésén kívül (nem kell hozzá AD kapcsolat)

Fontos API változások ennél a role-nál: az EDK Gateway és Routing Objects API-k megszűnnek az Exchange 12-ben, helyettük az Exchange 12 Agent API, valamint egy managed transport API jelenik meg. Az Agent API egy interface gyűjtemény, amely használatával saját agent-eket (kiegészítéseket) írhatunk a gateway és bridgehead szerverekre. A transport és egyéb kiegészítő szolgáltatások is (pl. Journaling agent a Bridgehead-en) mint agent-ek futnak.

Bridgehead Services

Ugyanúgy mint a Gateway role, ez is email-ek továbbítására való, viszont a Bridgehead szerep feladata a belső email továbbítása és irányítása, míg a Gateway server az internetről beérkező levelekért felel. A routing funkcionalitáson kívül a belső email folyamatok irányításához fűződő funkciókat nyújtja: Disclaimer agent, Journaling agent. Transport szabályok segítségével feltételeket definiálhatunk, amelyek meghatározzák, hogy milyen üzenetekre mely agent-ek fussanak.

Mailbox Services

Ez egy úgynevezett storage role, amely email-ek és attachmentek tárolására szolgál. Az indexelés és kereső motor megújulásán kívül (levelek keresése egyszerre több levelesládában vagy több szerveren, gyorsabb keresés/indexelés, stb.) az email retention rules (elévülési szabályok) jött a képbe, és még sok-sok új szolgáltatás, amelyeket hosszú volna mind felsorolni.

Client Access Services

Ez a role az Exchange szolgáltatásait teszi elérhetővé különböző kliensek számára, például: Outlook, RPC – RPC over HTTP, OWA, ActiveSync. Nagy újdonság ezen kívül az Outlook Voice Access, amely telefonon keresztül teszi elérhetővé levelesládánkat. A felhasználó az inputot beszéd felismeréssel, vagy gombnyomásokkal adhatja, az „operátor” pedig felolvassa leveleinket úgy, mint ahogy a hangpostánkat hallgatjuk. Ez a funkció valószínűleg marad angol, ami elég mulatságos lehet magyar levelek felolvasásakor.

Unified Messaging Services

Hangposta és fax Inbox-ba irányítása, instant messaging. Az új vezérelv: legyen minden elérhető egy helyen! Elég legyen csak az Inbox-ba mennem, ha a bejövő üzeneteimet akarom elolvasni/meghallgatni, legyen az akár fax, hangposta vagy email.

Új architektúra

A termék legtöbb összetevőjét újrafejlesztették a .Net keretrendszer 2.0-s változatára építve (a store maradt JET és natív kód, viszont körülötte szinte mindent újraírtak). Emellett igyekeztek a terméket igazi 3 rétegű alkalmazássá varázsolni az eddigi meghatározhatatlan számú réteg helyett. Ez többek között azt is jelenti, hogy a termék üzleti logikai része egy helyre koncentrálódott (XSO Library). Ezzel együtt a termék API-jai is konszolidálódnak, ami bizonyos API-k megszűnését, és új API-k bevezetését jelenti.

Az Exchange Management újjászületése

Az Exchange management eszközei is teljesen megújultak. Az első, és legszembetűnőbb újuláson a System Manager (ezentúl Exchange Management Console) ment át, akit MMC 2.1-esre írtak át, és ezen kívül teljesen átszerveztek:

Nagy áttörés az összes management funkcionalitás Monad-osítása: a rendszergazdák álma, hogy minden Exchange management funkció ami System Manager-ből végezhető, elérhető legyen parancssoros parancsokon, scripteken keresztül is. Ez most megvalósult, az Exchange 12 Monad cmdlet-ek bevezetésével.

Pár szó a Monad-ról: a Monad a Windows platform scripting funkcionalitásának forradalmasítása, amely már a Windows Vista része, valamint feltelepíthető a korábbi operációs rendszerekre is. A Monad parancssoros script írás helyett egy managed interface gyűjteményt és keretrendszert ad „cmdlet”-ek (parancssoros management tool-ok) készítéséhez. Minden parancsot egy külön .Net osztály valósít meg, a Monad alrendszer pedig a különböző parancsok hívását a megfelelő .Net osztályba irányítja, valamint a paramétereket átalakítja property-k vagy member-ek értékadására, az ouput-ot pedig megjeleníti a felhasználó számára. A különböző Monad parancsok variálhatóak mind egymással, mind a megszokott parancssori utasításokkal és kapcsolókkal (pl. | more, stb.).

A Monad parancsok általános felépítése a következő (elnézést a tükörfordításért):

ahol az ige a művelet neve, a főnév pedig annak a Monad osztálynak a neve, amellyel a műveletet végezzük. Például:

amely az Exchange szerveren lévő mailbox-ok listáját adja vissza. A get a parancs „ige” része, a Mailbox pedig a Monad osztály neve. A következő parancs:

viszont csak az Administrator user postaládájára szűkíti az eredményt. Fontos, hogy nem minden osztályon végezhető el minden „ige” (pl. nem létezik disable-MailboxStatistics, míg létezik disable-Mailbox).

Lássunk pár Exchange admin feladatot, Monad-dal: a következő képernyőn az látható, ahogyan lekérdezem a szervezet összes disztribúciós listáját (DL-jét), majd átírom mindegyik disztribúciós lista elsődleges email címének host részét (@ jel után) blabla.com-ra úgy, hogy az alias rész megmarad:

A foreach parancs végigiterál a get-DistributionGroup eredmény rekordjain, és végrehajtja a kapcsos zárójelben lévő parancsot annak minden elemén. A Monad utasításkészlete teljesen komplettnek mondható, típusos script nyelv, amely a .Net keretrendszer típusaival dolgozik, és a további funkcióinak bemutatása egy külön cikket igényelne. A Monad Shell Beta 3 Documentation pack (általános Monad dokumentáció és referencia) és maga a Monad „motor” letölthető a http://www.microsoft.com/downloads címről, a „monad” kulcsszó beírásával.

Tovább játszva a Monad-dal: nagyon hasznos a get-MailboxStatistics parancs, amely a szervezetben lévő összes mailbox pár legfontosabb állapotát mutatja:

Az Exchange admin toolok súgójában található egy Monad referencia, amelyben server role-onként, és azon belül alfunkciónkénti bontásban olvashatók a különböző Exchange Monad parancsok. Itt találtam a get-ExCommand parancsot, amely az Exchange 12 cmdlet-jeinek listáját adja vissza. A már jól ismert foreach parancs további gyakorlásaként összeszámolható a feltelepített 4 server role-om (Client Access, Storage, UM és Bridgehead) parancsainak száma:

Mindez szép és jó, viszont a Monad bevezetésével megszűnik jópár management API:

• Backup and Restore API (ESEdbcli2)
• CDO for Exchange Management (CDOExM),
• Queue Viewer API
• Exchange WMI osztályok

A megszűnt API-k teljes funkcionalitása (és még jóval több) viszont elérhető Monad cmdlet-eken és managed kódon keresztül, tehát érdemes a Monad-ot már most elkezdeni böngészni!

Érdekes, hogy a Beta 1-ben még vannak Exchange WMI osztályok, lehet hogy véletlen maradtak benne, vagy voltak még belső függőségek, amelyek meghosszabbítják az életét. Egyébként a WMI névtértől és „provider”-től függetlenül, a get-WmiObject Monad paranccsal akár WMI objektumokat is le tudunk kérdezni, pl:

Outlook Web Access

Óriási hangsúly került az OWA továbbfejlesztésére, mivel rengetegen használják elsődleges email kliensként is, melynek szolgáltatásai mostanra nagyon megközelítik az Outlook-ét. Pár snitt:

Ez történik egy címzett beírásakor:

Gyorsabb és hatékonyabb keresés, immár az Exchange kereső motorját használva (minden mappa fejlécénél van egy keresősor, amelybe bepötyögve a keresendő szöveget szinte azonnali eredményt kapunk):

Ha helyet szeretnénk megtakarítani, a bal oldali navigációs rész lekicsinyíthető egy oszlopra, a << gombra kattintva. Menjünk tovább a naptár és találkozó szervezés funkciókhoz: íme az új naptár kinézete:

Ezt láthatjuk, ha duplán kattintunk egy belső címzett nevén:

Intelligens találkozó szervezés: több résztvevős találkozóknál nagyon hasznos a jobb alsó sarokban lévő, közös szabad időpontok listája. A Free/Busy functionalitás is nagy újuláson ment keresztül: ezentúl a foglalás Free/Busy adatok, a foglaláskor pedig egy valódi ellenőrzés alapján történik, köszönhetően az intelligens „Scheduling assistant”-nek. A találkozó szervezés mostantól az Exchange Server támogatásával működik a szerver oldalon, ezáltal kiküszöbölve az inkonzisztens naptár állapotokat, és különböző Outlook verziók okozta problémákat több résztvevős találkozók esetén. Íme az új OWA találkozó szervezés ablaka:

Új „Dark” skin:

... és még sok más okos és szép újítás, amelyet ha mind bemutatnék itt, képeskönyvet varázsolnék a Tech.net magazinból. Még pár említésre méltó funkció:

• TOP 1: OWA-ból megnyithatóak belső SharePoint site-ra mutató dokumentum linkek (az OWA elvégzi a letöltést a belső site-ról), valamint böngészhetőek belső megosztások
• Accessibility
• Aláírás beállítás
• Külső/belső OOF üzenet beállítás
• Webpart kiegészítések (!!!) fejleszthetők OWA-hoz
• TODO bar (még egy függőleges panel a jobb oldalon, az aktuális találkozókkal, feladatokkal, stb-vel, nagyon hasznos, de még nem implementálták a Beta 1-ben)
• ActiveSync konfiguráció: a Beállítások oldalon megtekinthetjük, hogy a levelesládánk milyen mobil eszközökkel van/volt szinkronban, eltávolíthatjuk ezeket, illetve „remote wipe”-ot indíthatunk, amely a következő szinkronizáláskor az eszköz az adatok szinkronizálása helyett letöröl minden ActiveSync információt a telefonról: hatásos lehet telefon elvesztése esetén.

Exchange API konszolidáció és új API-k

Örömmel jelenthetem be, hogy az Exchange 12 megjelenése a programozók számára is nagy áttörést jelent, tele kihívásokkal.

Az első és legnagyobb örömet okozó áttörés az, hogy az új Exchange API-k mind .Net alapúak. Ez igen nagy szó az Exchange programozó társadalom számára, ugyanis a harmadik .Net framework kijöveteléig kellett várnunk, hogy natív .net támogatást kapjanak az Exchange-hez kapcsolódó alkalmazásaink.

Ugorjunk is gyorsan a közepébe: rossz hír, hogy pár API megszűnik, pár ebben a verzióban éli utolsó korszakát, viszont jó hír, hogy ezek helyett olyan API-kat kapunk, amelyekre mindig is vártunk:

• Exchange Web Services: web service metódusok hívásával végezhetünk üzleti logikai műveleteket!
• XSO: egy magasabb szintű API, amely az Exchange/Outlook üzleti logikai funkcionalitását nyújtja a szerver oldalon (!). Lefedi a teljes üzleti funkcionalitást, ami pl. Outlook-ból elérhető. Ezt az API-t sajnos még nem tudom bemutatni.
• MAPI.net: managed, az Extended MAPI-hoz nagyban hasonlító API, amely alacsony, adatelérési réteg-szintű hozzáférést biztosít az Exchange store-ban tárolt elemekhez.

Tovább erősít bizalmamban, hogy belül az Exchange is az új API-kat használja.

A megszűnt API-k: CDO for Workflow, Workflow Designer, 5.5 Event Service, ExIFS (M: drive), WSS Forms.

Azok az API-k, amelyet támogatása nem folytatódik a következő Exchange verzióban (Exchange 13-ban), viszont még teljes értékűen használhatóak az Exchange 12-ben: CDO 1.21, CDOEx, ExOLEDB, OWA URL commands, Store Events, WebDAV. Ezeket mind a Web Services for Exchange API váltja majd ki.

Web Services for Exchange 12

Lássuk csak, kell itt lennie pár web service-nek: a legegyszerűbb módszer ennek felfedezésére az IIS böngészése: a jól megszokott Exadmin, Exchange, ExchWeb és Public virtual directory-kon kívül van itt még kettő, ami történetesen tartalmaz asmx file-okat: „EPI” és „UnifiedMessaging”. Nagyon előrelátóan ezeket a directory-kat külön Application Poolok-ra állították. Nézzük csak, milyen web metódusok vannak az EPI directory alatt: Négy asmx file van itt: Availability.asmx, Folder.asmx, Item.asmx és Util.asmx.

Nézzünk bele az Util.asmx-be: ExpandDL és ResolveNames. Ez jó lesz kezdésnek! Whidbey indít, C# projekt, web service-ek keresése „localhost”-on, és már meg is van. Próbáljuk ki a ResolveNames-t. A következő projekt kissé keserves összerittyentése után végre sikerült szóra bírni:

A ConsoleApplication1.localhost namespace a Util webservice importjait tartalmazza. Az output pedig a következőképpen néz ki:

Hát ez nagyszerű! Régóta nagy hiány volt Exchange üzleti logikai webszolgáltatásokban! Az egészben az a forradalmi, hogy az üzleti logikát megvalósító kód a szerveren fut, és bármilyen platformról, bármilyen környezetből hívható, Http kérések formájában. Exchange 2000 és 2003 esetében az ilyen jellegű műveleteket vagy az Outlook Library, vagy CDO 1.21 használatával, vagy a CDOEX libraryval végezhettük (a Microsoft terméktámogatás által) „támogatott” módon. A mostani Exchange verziókkal általános hiba, hogy a programozók WebDav hívások formájában végeznek mindenféle üzleti logikai műveletet, és persze egy csomó hibába futnak, ugyanis az Exchange Server és WebDav provider nem ismeri az Outlook üzleti logikai műveleteit (pl. találkozó elfogadása), ezeket csak jópár WebDav tulajdonságok „hackelésével” lehet elvégezni. Az Exchange Server csak item-eket és azok tulajdonságait látja, nem érti a magasabb szintű műveleteket. De ennek vége az Exchange 12 WebServices megjelenésével!

Tovább böngészve olyan web metódusokat találok, mint GetUserAvailability, ami Free/Busy lekérdezésre alkalmas, klasszisokkal inteligensebb módon, mint az eddigi Http lehetőségeink (WebDav/OWA Http command), valamint GetUserOofSettings és SetUserOofSettings, amelyek OOF Autoresponse lekérdezésére/beállítására szolgálnak.

Megjegyzés: amellett, hogy WebDav-val lehetőségünk adatik Exchange 2000 és 2003 esetében is OOF üzenet módosítására, ne tegyük, mert a store belül cacheli az OOF üzeneteket, és az eredmény az lesz, hogy két OOF üzenetet kap a küldő (a régi és új szöveggel). A megoldás az Exchange service-ek újraindítása. Ugyanez vonatkozik az OOF üzenetek törlésére is.

A következőkben elhagyom a C# kódot, csak a SOAP kérést mutatom be. Íme egy CreateItem kérés:

Mindez rendelkezésre áll a FrontEnd (Gateway) szerveren is, tehát ez a funkcionalitás elérhető akár az internetről is. Különböző fórumokon ígértek még jópár Outlook funkcionalitású web metódust, pl. Meeting request elfogadását, stb., de ezeket most nem találom, vagy mert nem nézem elég közelről, vagy majd a következő Beta-ban ...

Managed Mapi: Mapi.net

Hosszú idők óta megy a huzavona különböző levelezőlistákon, hogy miért nem lehet az Exchange legalacsonyabb szintű és leghatékonyabb API-ját, az Extended Mapi-t managed kódból hívni. Helyesbítek: lehet, de nem támogatott (különböző threading és GC non-managed gubancok miatt). Volt egy lelkes programozó, aki megírta a teljes wrappert .net-ben, majd ledöbbent a Q813349 cikk láttán, ahol kiderült, hogy feleslegesen dolgozott, sajnos. Nos, örömmel jelenthetem be, hogy a probéma megoldódott: a srácok Redmondban kitettek magukért, és elkészítették a mapi.net library-t, így ezentúl Extended Mapi szintű kódot írhatunk managed alkalmazásból! A dolog nagy előnye továbbá, hogy míg a library valóban az Extended Mapi hétákonyságát örökölte (sőt, még jóval többet), a használata sokkal egyszerűbb! Lássunk egy példát:

A fenti kód belép a megadott felhasználó postaládájába, majd annak Bejövő levelek mappájába, lekérdezi az első levelet és kiírja a konzolra annak tárgy mezőjét. Legalább annyira egyszerű, mint az Outlook vagy CDO 1.21 Library, nem?

Gyors magyarázat: a belépési pont a MapiStore objektum, amelynek az OpenMailbox() statikus metódusa a paraméterben megadott szerveren lévő szintén megadott felhasználó postaládáját nyitja meg és adja vissza MapiStore osztály egyedként. Hosszú időbe telt, míg rájöttem, hogy nem felhasználónév, se nem AD distinguished name, hanem az AD user legacyExchangeDn tulajdonsága használandó itt (a harmadik paraméterben a delegation infó gyanánt meg kell adni ugyanazt a Dn-t). A másik lehetséges belépési pont az OpenPublicStore(), amely a nyilvános mappák store-ját nyitja meg a postaláda helyett.

A MapiStore objektumból tovább haladva, a GetInboxFolder() az inbox mappát adja vissza. A GetContentsTable() metódus ismerős azoknak, akik Extended Mapi-ban járatosak: a mappa tartalmát adja vissza IMapiTable (mapi.net esetében MapiTable) osztályként. A QueryOneRow() egy új függvény (Extended Mapi-ban nincs ilyen), a tábla következő rekordját adja vissza (jelen esetben az elsőt): az első paraméterben definiálhatunk szűkítést (de mi nem definiálunk), a második paraméterben pedig megadhatjuk a mezőket, amelyekre kíváncsiak vagyunk (én a Subject mezőt adtam meg).

A standard Mapi tulajdonságok gyűjteménye a PropTag enum-ban van (1-2 száz), és sajnos nem a PR_... formátumban, hanem az Outlook mező választóhoz hasonló barátságos elnevezéssel (Subject). Nem-standard PropTag-ek a PropTagHelper osztály statikus PropTagFromIdAndType metódusával készíthetőek (ezek is PropTag enum-ok lesznek, amelyet megadhatunk pl. a QueryOneRow() metódusnak).

Böngészgetve a Visual Studio object browserében azt látom, hogy elég sok könnyítést eszközöltek a fejlesztők, pl. A GetCalendarFolder() és OpenAlternateMailbox() metódusok, amelyek megvalósítása oldalakban mérhető Extended Mapi-val, C-ből vagy C++-ból, itt pedig csak egy sor kód.

Vissza az architektúra részhez: tény, hogy Extended Mapi köré nem lehet .net wrappert írni, különböző memóriakezelési és threading problémák miatt (újra Q813349). Így 3 megoldás marad: vagy egy natív wrappert készítünk az Extended Mapi felé, ami elfedi a „wrappelhetetlen” funkcionalitást és erre készítünk egy managed wrappert, vagy újraírjuk az egészet .net-ben, vagy pedig részletesen újraírjuk az Extended Mapi-t C-ben (úgy hogy másképp kezelje a nem-managed memóriát és thread szinkronizációt), és erre készül a wrapper. A product group ez utóbbit választotta: kiemelték az Extended Mapi Exchange-es funkcionalitását (eddig emsmdb32.dll volt, az Exchange Server Store, Transport és Address Book providere), és e köré írt egy managed wrappert. A kiemelt funkcionalitást tartalmazó DLL neve: exrpc32.dll. Az átalakítás sok helyen meggyorsította a Mapi műveleteket, valamint eltörölt olyan funkcionalitásokat, amelyek nem szükségesek többé ezen átalakítás után, pl. a profile-ok kezelését és tárolását (!!!!).A mapi.net tiszta Exchange elérésre született, és nem helyettesíti az Extended MAPI-t. Ezt mutatja a mapi.net Exchange architektúrában való elhelyezkedése is: a szerver oldalon történő „magasabb szintű” műveletek (content indexing, virus scanning, transport, XSO library, stb.) is mind mapi.net-et használnak a store-ral való kommunikációhoz. Egy 3 rétegű alkalmazásban a mapi.net számít az adatelérési rétegnek.

Hatékonyságán és egyszerűségén kívül megannyi hasznos tulajdonsággal látták még el: jobb teljesítmény, thread safe műveletek, data caching, connection pooling, hatékony RPC hívások (késleltetett – összegyűjtött – műveletek).

Konklúzió

A fő konklúzióm az, hogy az első belegondolásra rengetegnek tűnő 6 oldal (ami mostanra 7 lett) nagyon hamar betelt, és még a felét sem tudtam kifejteni annak, amit szerettem volna. A termékkel kapcsolatban: egy nagyon szuper Exchange verzió van születőben. A fejlesztők a termék minden funkcióját teljesítményt, biztonságot és használhatóságot alaposan megfontolva terveztek és fejlesztettek, rengeteg tapasztalat és adat ismeretében. Fejlesztői szemmel nézve az API-k architekturálisan nagyon jól pozícionáltak. Ezen kívül nagyon jó hogy minden API managed környezetből hívható, és nem 2 wrappelésen keresztül, vagy nem támogatott módon. Amit a következő publikus verziónál is jobban várok, az már csak a fejlesztői dokumentáció.