2007. január havi bejegyzések

Egyetlen gondolat a licencelésről: ASP.NET AJAX

Időnként előfordul, hogy megkeresnek licenceléssel kapcsolatos kérdéssel, pedig arra szinte biztosan nem fogok tudni válaszolni. Ahogy a Microsoft Regional Director levelezőlistán szokták emlegetni, "you need a PhD to understand Microsoft licensing".

Most azonban mégis akadt egy kivétel, mégpedig az ASP.NET AJAX megjelenése kapcsán. A Microsoftnál végre valaki észbekapott és sikerült egy oldalas licenc szövegeket írniuk!

Az ASP.NET 2.0 AJAX Extensions csomag immár forráskóddal együtt letölthető, és a forráskódra a Microsoft Reference License (Ms-RL) vonatkozik, ami tényleg csak 1 oldal. A lényeg: azért adta ki a Microsoft az Atlas forráskódját és a PDB fájlokat, hogy egyszerűbb legyen a fejlesztők élete, lehessen szépen debuggolni. (Sőt, még az is lehet, hogy éppen az ASP.NET AJAX-ot felhasználó fejlesztők találnak meg így olyan hibákat, amiket a product team nem vett észre :)) Magyarul bele lehet nézni, de nem szabad módosítani, terjeszteni vagy újrafordítani. Végre nem kell Reflectorozni!

Az Atlas másik része, a Microsoft AJAX Library szintén forráskóddal együtt elérhető (másként nem is lehet, hiszen JavaScript fájlokról van szó), ezekre a Microsoft Permissive License (Ms-PL) vonatkozik, ami szintén nem hosszú. Ahogy a nevében is benne van, ez megenged mindent: lehet módosítani a forráskódot és azt fel is lehet használni a saját alkalmazásainkban. Egyetlen feltétel van csak, kéretik megváltoztatni a névtereket, hogy egyértelmű legyen, mi az eredeti Microsoft implementáció és mi saját, illetve ami még fontosabb, ne legyen névütközés!

Az ASP.NET AJAX harmadik pillére az ASP.NET AJAX Control Toolkit, aminek a forráskódja szintén elérhető, hiszen ez nem más, mint egy közösségi projekt a CodePlexen. Ennek a kódnak a módosítása nem hogy engedélyezett, hanem szinte kívánatos, tessék beszállni a fejlesztésbe és gyártani az új, illetve javítgatni a már meglévő AJAX kontrollokat!

Hogy miért szabdalta a Microsoft három, sőt a Futures CTP-vel négy részre az Atlast? Hogy mire jók az egyes komponensek és hogyan lehet őket beépíteni a saját alkalmazásainkba? Minderről lesz szó részletesen a jövő heti MSDN Kompetenciák Egyetemén, lehet regisztrálni!

 

Technorati tags: ,

Amikor a bicska kinyílik a zsebben

A The New York Times január 27-én azt írta, hogy valakiknek ("group of rivals") megint nem tetszik, amit a Microsoft csinál:

The group said Microsoft’s XAML markup language — which it said was positioned to replace the current Web page language HTML — was designed “from the ground up to be dependent on Windows.”

“The very same practices the European Commission found to be illegal almost three years ago have now been implemented in Vista,” the group of rivals said.

Természetesen mindenkinek megvan a joga, hogy véleményt alkosson és eldöntse, hogy valami tetszik vagy nem tetszik neki. Sőt, hajrá, tessék csak kifejezni azt a kialakult egyéni véleményt és nem csak együtt folyni a tömeggel! Csak azt nem értem, hogy miért hőbörög valaki olyasmi miatt, aminek a hatása alól akár teljes egészében ki tudja vonni magát? Na és mi van akkor, ha egy cég valami olyat alkot, aminek köze van egy másik termékéhez? Nem kell használni egyiket sem, különösen, hogy vannak alternatívák. Ha a következő Forma 1-es szezonban a Renault kitalál egy új kormányt, ami csak a saját autóiba illik, akkor ezért fizessen büntetést a többi csapatnak vagy dobja kukába a fejlesztést?

Még soha nem hallottam, hogy a Microsoft a XAML-t szembe pozícionálta volna a HTML-lel. Ennek egyik oka valószínűleg az, hogy a HTML-től éppúgy nehéz lesz megszabadulni mint a HTTP-től vagy az IPv4-től, a másik pedig, hogy teljesen nyilvánvalóan a XAML-ben lényegesen több lehetőség van – de más területen. Ha már mindenképp a XAML-t akarjuk egy webes eszmecserébe bevonni, akkor a WPF/E lehet a mérleg másik oldalán, ami viszont megint csak teljesen nyilvánvalóan a Flash egy lehetséges alternatívája. Erre viszont már nem lehet azt mondani, hogy Windows specifikus lenne, hiszen már Mac-en is támogatott és a lista csak bővülni fog.

Az alternatívákban az a jó, hogy versenyeznek egymással. Magyarul, ha a XAML jó, hasznos, egyszerű akkor szeretni fogják a fejlesztők és megelőzi a már létező technológiákat és vezetni fog az újak előtt is. Ha pedig a XAML gagyi, akkor majd más viszi a pálmát. A versenyben pedig az a jó, hogy fejlődést eredményez, innovációt indukál, aminek egyértelműen a felhasználók, azaz mi leszünk a kedvezményezettjei.

Akkor meg mire ez a nagy felhajtás meg a "monopolista" szlogenek? Tessék alternatívát állítani a rajtvonalhoz és győzzön a jobbik!

 

Technorati tags: ,

Workflow Foundation alapozás

Véget ért a két napos Workflow Foundation Laborgyakorlat, melyet a novemberi MSDN konferenciához kapcsolódóan szerveztünk az MSDN Kompetencia Központban. Minden tanfolyam elején meg szoktam kérdezni a résztvevőket, hogy milyen a fejlesztői előéletük és hogy mit várnak ettől a tanfolyamtól. Jó volt hallani, hogy szinte mindenki ott volt a konferencián és hogy azért jöttek erre a képzésre is, mert felismerték, hogy rengeteg időt lehet azzal spórolni, hogy "több ezer oldalnyi könyv elolvasása helyett más kaparja ki a gesztenyét". Ez a hetedik év, hogy én személy szerint ebben a szellemben dolgozom, jó tudni, hogy van eredménye 🙂

Érdekes volt hallgatni mindkét nap végén, hogy ki hogyan fogalmazza meg magának a Workflow Foundation lényegét: ez nem egy rapid alkalmazásfejlesztési technológia! Ez persze elsőre csalódottságot ébreszt, de megismerve a platform alapszolgáltatásait, mindenki be tudja lőni magának, hogy mit várhat ettől a rendszertől és mit nem. A nap végén mindenki tisztába került azzal, hogy mivel jár a Workflow Foundation használata, mik az előnyei és mik lehetnek a fájdalmas pontjai. (Érdemes elolvasni Novák István első benyomásait.)

Persze sokan (én is) hajlamosak vagyunk a dolgok negatív oldalát látni, hív a sötét oldal: nehézkes a kommunikáció, kevés activity van a Base Activity Library-ben, a Visual Studioba integrálódó designer néha elhal, ráadásul rengeteget kell gépelni. Ezek tények, nem érdemes szépíteni, ez így van. Minél többet foglalkozik vele az ember, annál jobban így érzi.

De ezek mind csak elvárásaink miatt érződnek így – úgy látjuk, hogy a pohár félig üres. Ha sikerül onnan megközelítenünk a kérdést, hogy ez egy platform technológia, akkor már teljesen más lehet a kép – nézzük úgy, hogy a pohár félig tele van! Úgy vettem észre, sokan találkoztak már más workflow technológiákkal. Ha össze akarjuk hasonlítani ezeket a Workflow Foundationnel, akkor általában arra juthatunk, hogy a WF célközönsége az alkalmazásfejlesztő, a programozó, míg más technológiák gyakran másoknak készültek. Másként fogalmazva ez egy "megveszem vagy megcsinálom magamnak" kérdés. A WF nem ad adminisztrációs eszközöket, csili-vili jelentéseket, de még monitorozó alkalmazásokat sem. Ezeket mind nekünk kell megépítenünk, a platform legfeljebb API támogatást tud adni mindehhez. Megold alap problémákat és ad alap szolgáltatásokat, de semmi extra.

Újra és újra felmerül a kérdés, hogy ha ez ennyire "fapados", merjünk-e ráépíteni? A Microsoft egyértelműen ezt az irányvonalat akarja a követni, a SharePoint, a BizTalk, Speech Server, az MIIS és a Microsoft Dynamics következő verziói már biztosan ezt fogják használni. Sőt, az egyik legnépszerűbb workflow termék, a K2 is áttér Workflow Foundationre. Miért? Mert kihasználva egy stabil alaptechnológiát, képes lehet további szolgáltatásokat biztosítani a termékeiben, ami miatt érdemes lehet megvenni a K2-t.

Természetesen minél több felhasználója van egy frameworknek, annál érettebb technológiává növi ki magát. Még csak most jelent meg a .NET 3.0 és vele együtt a WF első kiadása, mégis kiváncsian várhatjuk, mi lesz a következő verzióban…

 

Technorati tags: , ,

Tényleg olyan egyszerű az AJAX?

Aki foglalkozott már az ASP.NET 2.0 AJAX kiterjesztésével, biztosan észrevette, hogy a tervezők kiemelt figyelmet fordítottak arra, hogy meglévő ASP.NET 2.0 alkalmazások egyszerűen kiegészíthetők legyenek az új funkcionalitással. Mindennek a lelke az új UpdatePanel kontroll, melybe beágyazva a meglévő adatkezelő kontrolljainkat, egy csapásra AJAXosíthatjuk az oldalunkat.

Valóban csak ennyiről van szó, ebből áll az ajaxosítás?

Közelítsük meg más oldalról a kérdést: ugyanúgy kell ezután is megterveznünk a webalkalmazásainkat, az oldalainkat és a funkcionalitást? Ugyanúgy kell ezután is használniuk a felhasználóinknak az alkalmazásainkat, ugyanarra a felhasználói tudásra van szükségük ahhoz, hogy eligazodjanak a webhelyünkön?

Szerintem nem! Csak néhány érdekesség a lehetséges problémák közül:

  • Kereső motorok: mivel egy AJAXos oldal nem teljes egészében frissül, ezért a részleges újratöltés után is változatlan marad az URL. Mit szólnak ehhez a keresőmotorok, mit kezd mindezzel a Google? És mit kezd majd az oldallal a felhasználó, amikor a Google-ben rákattint a találatra és mégsem lesz az oldalon a keresett szó?
  • Linkek: hogyan fogunk tudni hivatkozni egy olyan oldalra, vagy pontosabban egy oldalnak egy olyan állapotára, amely 4-5 részleges frissítés után alakult ki?
  • Forgalomszámlálás: mi számít ezek után egy megtekintett oldalanak? A menü és a hirdetések nem töltődnek újra, csak az oldal közepén a lényeg, de az sokszor. Akkor most ez hány page impression?
  • Böngésző gombok: hogyan értelmezzük ezek után a böngésző Back és Forward gombjait? Sőt, egyértelmű lesz egy átlagfelhasználó számára, hogy mi, fejlesztők, hogyan értelmezzük őket?
  • Használhatóság: hogyan lehet egyértelműen jelezni a felhasználók számára, hogy mi történik? Értik egyáltalán mindezt a felhasználók? Eddig az internet böngészés 1×1-e az volt, hogy rákattintunk egy aláhúzott szóra, majd nézzük a böngésző státuszsorát és várjuk, hogy az oldal töltődését jelző csík elérje a 100%-ot. És most mit tanítunk majd, mire kell figyelni? Léteznek-e egyáltalán usability és accessibility ajánlások AJAXos weblapokhoz?
  • Dizájn: honnan tudja majd egy webtervező, hogy milyen oldalt kell terveznie, ajaxosat, vagy olyat, ami hagyományos mosóport használ? És miután ez kiderül, tudni fogja egy dizájner, hogy miben más a felhasználó viselkedése, hogy ki kell tenni egy homokórát vagy egy figyelmeztető üzenetet valahova az oldalra?

Az AJAXos webalkalmazások tehát gyökeresen mások, mint a régi kérés-válasz protokollra épülő webek. Meg lehet nézni az MSN Soapbox-ot: egyetlen oldalon belül egyszerre lehet keresni, videót nézni és navigálni. Tehát nem csak arról van szó, hogy JavaScriptet, XmlHttp-t és DHTML-t építünk az alkalmazásunkba, hanem arról is, hogy felborítjuk az eddigi (mindegy, hogy jó vagy nem jó, de jól megszokott) rendet!

Persze lehet mindezt pusztán technikai szemmel, objektumok, osztályok és webszolgáltatások szintjén nézni, de azért nem árt, ha pontosan látjuk, milyen problémákat veszünk a vállunkra. Mint mindig, ezekről a hátulütőkről is lesz szó a következő MSDN Kompetenciák Egyeteme rendezvényen, amin a február 8-9-én az ASP.NET AJAX-szal foglalkozunk! De addig is, ha van véleményed, ragadj billentyűzetet!

Technorati tags: ,

Saját események WF activity-ben (kiegészítés)

Az előző hasonló című szösszenetből kimaradt egy dolog, így most ezzel a bejegyzéssel igyekszem leróni adósságomat: hogyan lehet elsütni egy olyan eseményt, ami saját EventArgs osztályt használ?

Az Activity osztálynak van egy RaiseEvent() metódusa, a legtöbb példában ezt találjuk. Ennél lényegesen szebb megoldás, ha a RaiseGenericEvent<T>() metódust használjuk:

protected internal void RaiseGenericEvent<T> (
  DependencyProperty dependencyEvent,
  Object sender,
  T e
) where T : EventArgs

Persze az MSDN (pardon, a Windows SDK, mert a .NET 3.0 dokumentációja persze külön van) nem sokat segít:

Type Parameters
T
The specified type.

Értsd: a T paraméterben kell megadni a saját EventArgs osztályból származtatott típus nevét, valahogy így:

protected override ActivityExecutionStatus Execute( ActivityExecutionContext aec )
{
  // …
  base.RaiseGenericEvent<WorkEventArgs>( MyActivity.OnWorkingEvent, this, new WorkArgs( … ) );
  // …
}

Na így már talán teljes a kép 🙂

Technorati tags: , ,

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: , ,

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.