Daily Archives: 2007.01.21. 20:20

ExternalDataExchangeService és a WCA

A Workflow Foundationben a workflow példányok és a külvilág közötti kommunikáció megvalósítására használhatjuk a QueuingService-t, vagy még inkább az ExternalDataExchangeService-t (EDES). Rossz nyelvek szerint az EDES a SharePoint miatt került a WF-be (a WSS hosztolja a WF-t), amit ismerve a WSS-t simán el tudok képzelni, olyan is…

Az alapgondolat jó: a kommunikáció legyen interfész alapú, azaz egy interfész határozza meg a workflow példány és a külvilág számára is, hogy milyen üzenetek és adatok utazhatnak a két fél között. Csak mindennek az implementálása sikerült bonyolultra, legalábbis a WF közösség nagy része ezen a véleményen van. Elsőre tényleg bonyolult, de hozzá lehet (kell) szokni. Ahhoz, hogy egy workflow példány elküldje akár egyetlen változó értékét a hoszt alkalmazás számára (például egy jóváhagyási folyamatban) és az visszajelezzen, hogy oké vagy nem oké, a következő lépésekre van szükség:

1. A workflow meg tudja hívni a külvilág metódusait illetve tud reagálni bizonyos eseményekre, amelyek a "külvilágból érkeznek". Ezeket a metódusokat és eseményeket egy interfészen (vagy-ben?) kell definiálnunk, melyet el kell látnunk az [ExternalDataExchange] attribútummal.

2. Ahhoz, hogy egy eseménykezelő metódus esemény paramétereket kapjon (például bool oké vagy nem oké), szükség van egy saját EventArgs osztályra, amit kötelezően az ExternalDataEventArgs osztályból kell származtatnunk.

3. A workflow definíciónkba be kell építenünk legalább egy CallExternalMethod vagy egy HandleExternalEvent activity-t, melyeknek meg kell adnunk az interfészt és azon valamelyik metódus vagy esemény nevét.

4. A külvilágban (például a hoszt alkalmazásban) implementálnunk kell az interfészt, ez lesz az ún. local service osztályunk. Ebben tudjuk implementálni a workflow példány által meghívott metódusokat és tudunk gondoskodni arról, hogy az események elsüljenek (például az események elsütését egy-egy metódusba csomagoljuk).

5. A hoszt alkalmazásnak a megfelelő pillanatban el kell sütnie az eseményeket (vagy meg kell hívnia az elsütést burkoló metódusokat) és át kell adnia a saját esemény paramétereken kívül a cél workflow példány azonosítóját (GUID), amit tehát valahol a hoszt alkalmazásban nyilván kell tartani.

ExternalDataExchangeService

Lássuk be, mindennek a megvalósítása nem két perces feladat, sőt jó esélyünk van rá, hogy első alkalommal elveszünk valamelyik részletben. Nézzük például azt a részletet, hogy a workflow-ban szeretnénk felhasználni a saját ExternalDataEventArgs osztályunk hozzáadott tulajdonságát. Erre ugye jó esély van, hiszen valószínűleg ezért adtuk át…

Ha megnézzük a Visual Studio workflow designerét, azt fogjuk látni, hogy nem tudjuk külön kötni ezt a tulajdonságot, csak az egész EventArgsot, tehát még ennek felbontásával is küzdhetünk.

Egy kis segítséget jelenthet a Windows Vista SDK-ban található Workflow Communications Activity generator utility, a wca.exe. Ez a parancssoros alkalmazás képes megérteni az [ExternalDataExchange] attribútummal ellátott interfészt, és abból saját activity-ket generálni, melyek a CallExternalMethod és a HandleExternalEvent activity-kből származnak. Ezeket a workflow definícióba helyezve nem kell vacakolnunk az interfész beállításával és még az egyes EventArgs tulajdonságokhoz is tudunk más mezőket kötni. Az eszköz a megadott nyelven, a megadott névtérben és a megadott mappában forráskódot generál, amit természetes akár át is írhatunk. A program a C:Program FilesMicrosoft SDKsWindowsv6.0Bin mappában található és mindössze 51KB, tehát nyugodtan másolhatjuk a forráskódunk közelébe.

Érdemes használni ezt a kis segédprogramot, kényelmesebbé teszi az EDES használatát, de persze ettől még nem fogjuk szeretni…

 

Technorati tags: , ,
Advertisements

Foundations = Alapok

Mióta évekkel ezelőtt felröppent, hogy lesz Windows Presentation, Communication és Workflow Foundation gyakran találkozom azzal a kérdéssel, hogy vajon miért jó, miben segít, szükség van-e rá és hogy fogjuk-e vajon használni egyiket vagy másikat. Ha a szokásos Microsoft kommunikációt nézzük, akkor bizony azt a választ kaphatjuk, hogy naná, hiszen ezek forradalmasítják a szoftverfejlesztést. Na persze…

Ez persze bizonyos szinten igaz, azonban mindenképp meg kell értenünk, hogy mi is a bizonyos szint. A megfejtést rögtön megtalálhatjuk a technológiák elnevezésében: FOUNDATION = ALAP. Nem több, csak alap. Aztán ha megnézzük, hogy a W*F technológiák a .NET Framework 3.0 részeként jelentek meg, akkor megint közelebb kerülhetünk a megoldáshoz: FRAMEWORK = KERETRENDSZER. Nem eszköz, nem termék, csak csodafegyver, csak alap és keretrendszer.

Mint minden keretrendszernek, ezeknek is megvannak az előnyeik az egyedi megoldásokkal szemben: egységesség, kiterjeszthetőség, felhasználói közösség stb. Hátrányuk is van, nem titok: kompatibilitás, veriózás, komplexitás…

A legnagyobb hátrányt azonban mi magunk kreáljuk: túl sokat várunk tőlük.

Vegyük például a Workflow Foundationt. Ez a kis mostoha (erről majd egyszer máskor) mindössze három DLL, három .NET-es szerelvény. Akad hozzá ugyan egy-két segédprogram (majd erről is máskor), de akkor is csak jó sok osztály marad. A nyers osztályokat pedig nem lehet máshogy használni, mint hogy az ember kódot ír hozzájuk, amiben példányosít, tulajdonságokat állít és metódusokat hív. Ha mint runtime nézzük, akkor kódot kell írni már ahhoz is, hogy hosztoljuk a runtime-ot.

Ok, túl vagyunk a hosztoláson, építsünk workflow-t. Mi kell hozzá? Építőkocka, azaz activity. Van is néhány a Base Activity Library-ben. Néhány. Ráadásul azok is teljesen általános activity-k, azaz alap activity-k. (Ugye, alapok!) Hogyan fogunk tudni megépíteni egy folyamatot, amiben értelmes tevékenység (levélküldés, feldolgozás, adatbázis művelet stb.) is van? Építünk építőkockát, azaz készítünk saját activity-t. Hogyan? Létrehozunk egy osztályt, amit a WF egyik ősosztályából származtatunk. Azaz megint csak kódolunk.

Gondolkodjunk tovább. A WF segítségével kétféle típusú workflow-t lehet készíteni: szekvenciális és állapotgép típusú folyamatot. Az állapotgép egyik jellemzője, hogy események hatására megy át egyik állapotból a másik állapotba, azaz a workflow-nak tudnia kell eseményeket kezelnie. A megoldás a WF-ben található ExternalDataExchangeService. Aki már egy kicsit is foglalkozott a workflow és a külvilág közötti kommunikáció megvalósításával, biztos belefutott ebbe a szörnyszülöttbe. Ha esetleg az interneten olvasott fórumokat, akkor azt is biztosan látta, hogy ez az API a bonyolultsága miatt nagyon ellenszenves a fejlesztőknek. Persze van oka, amiért így alkották meg, a lényeg, hogy az egyszerű eseményküldéshez és kezeléshez megint csak kódolnunk kell.

Nézzünk egy speciális esetet: workflow hosztolása webalkalmazásban. Egy-két érdekességéről már írtam korábban, de most vegyünk egy gyakori példát: portál regisztráció jóváhagyását valósítsuk meg WF alapokon. Mi kell hozzá:

  • Workflow
  • Activity-k
  • Hosztolás
  • Kommunikáció
    • Saját EventArgs
    • ExternalDataExchange interfész…
    • és annak implementációja
    • Események elsütése

…és a sor még folytatható lenne. Ha ez az első workflow, amit beépítünk az alkalmazásba, akkor egy fél nap biztosan el fog menni, mire mindezzel végzünk.

Makó közelebb van Jeruzsálemhez, mint a WF a Rapid Application Developmenthez. Aki azt várja, hogy a WF (sőt, merek általánosítani: a W*F) segítségével egyszerűbb lesz az élete és gyorsabban fog fejleszteni, az szerintem csalódni fog és oda jut, hogy mindez gagyi. Pedig messze nem erről van szó, csak sokat várunk tőlük.