Már régóta fontolgattam, hogy be kéne szereznem egy Android-os telefont. Kicsit körbenéztem az elérhető eszközök között, és a választásom a Samsung Galaxy Spica-jára esett. Ez a telefon ugyanis rendelkezik minden tudással, amivel a nagyok (WiFi, GPS, elviselhető teljesítményű processzor), az ára viszont kb. fele annyi (Extreme Digitálnál röpke 60 000 Ft). Mikor hozzájutottam, bekapcsolás után az első gondolatom az volt, hogy a telefonnal szállított 1.5-ös oprendszert 2.1-esre kellene cserélni. Kicsit utánaolvasgattam, és március környéki híreket találtam arról, hogy a Samsung hamarosan hivatalosan is elérhetővé teszi a 2.1-es firmware-t telefonjaira. Gyorsan fel is pakoltam a telefonhoz adott CD-ről a Samsung Kies nevű kezelőprogramját, és megpróbálkoztam a frissítéssel. Első körben a cucc fel sem ismerte a telefont, aztán valami modell adatbázist nem talált. Próbálkoztam a PC suite különböző változataival, a Kies-ből is töltöttem frisset, végül kb. fél napi tömény szenvedés után feladtam. Ezzel a telefon upgrade dologgal valahogy nincsenek a helyzet magaslatán. Végül úgy döntöttem, lesz ami lesz, felülvágom a firmware-t, mert nekem 2.1-es Android kell, ha a fene fenét eszik is.
A frissítést a http://forum.androidhungary.com/topic/samsung-galaxy-spica-android-21-flashing-utmutato alapján végeztem. Az Odin-t és a drivereket könnyen be tudtam szerezni, a firmware-hez kicsit szenvedni kellett, mert ilyen hülye fájlmegosztó oldalakról kellett lebányászni, amik mindenféle várakoztatásokkal próbálják rávenni az embert, hogy dobjon be némi pénzt. Mennyivel jobban örültem volna egy szimpla torrent linknek, de mindegy, leszenvedtem a firmware-t. Megnyomkodtam a gombokat, beállítottam a letöltést, betallóztam a fájlokat, aztán vártam, de nem történt semmi. Rájöttem, hogy a Kies még fut a háttérben. Lelőttem, újraindítottam az Odin-t, de a letöltő csík meg sem mozdult. Na, gondoltam, most vágtam tönkre a telefont, ugyanis kikapcsolni nem lehetett, a leírásban meg az ember lelkére kötik, hogy ne szakítsa meg a folyamatot. Végül aksi ki-be, bekapcsoltam a telefont, és hamar meg is könnyebbültem, mert simán bebootolt az eredeti 1.5-ös Android. Ezen kicsit fel is bátorodtam, hisz ebből látszott, hogy azért nem olyan könnyű tönkre vágni a telefont. Újra elindítottam a feltöltést az Odin-ből, de most valami cache fájl miatt nyavajgott. Végül rájöttem, hogy az Odin mellé csomagolt ops fájlban van a hiba, és a helyről, ahol a firmware-t is letöltöttem, letöltöttem az új ops-t. Felülvágtam a régit, elindítottam a frissítést, és minden smakkolt. Végigfutott a progress bar, telefon kikapcs-bekapcs, és az új 2.1-es Androidom fogadott. A beállításoknál visszaváltottam a nyelvet magyarra, és végre birtokba vehettem az újdonsült telefonomat.
Amúgy magával a telefonnal eddig nagyon meg vagyok elégedve, a Google szinkronizálás (címjegyzék, levelezés, gTalk, stb.) alap. A WiFi-t is rögtön belőttem, hogy ne is próbálkozzon 3G-n, mert nem szeretnék következő hónapban 10 000-es számlát kapni az adatforgalom miatt. Telepítettem még a market-ből egy eBuddy nevű üzenetküldő alkalmazást, ami kb. a Pidgin Androidos megfelelője (MSN, ICQ, stb. támogatás), és egy Skype Lite Beta-t. Talán még egy IGO hiányzik róla, hiszen a GMap-nak netkapcsolat kell, és utazás közben általában nem jut az ember WiFi-hez, a mobilnet pedig dárga.
UPDATE: A későbbiekben néhányszor próbáltam belőni a 3G-t, de nem jártam sikerrel. A megoldást végül egy kolléga segítségével sikerült megtalálni. Ahhoz, hogy a telefon csatlakozzon a 3G hálózatra, a Beállítások/Vezeték nélküli beállítások/Mobilhálózatok/Hozzáférési pontok neve menüpont alatt hozzá kell adnunk a szolgáltatóhoz tartozó APN-t, amiről itt találhattok egy listát. A beállítást követően remekül működik a 3G. A megoldás megtalálásáért külön köszönet Kercza Ádámnak.
2010. június 22., kedd
2010. június 8., kedd
Üzenet alapú programozás - Entourage és ErraiBus
Az utóbbi időben az ActiveMQ kapcsán kicsit mélyebben utánaolvastam az üzenet alapú rendszereknek. Nem annyira az ESB megoldások érdekeltek, hanem inkább az, hogy léteznek-e üzenet alapú web-es keretrendszerek. A közelmúltban 2 nagyon jó projektet is találtam. Ezek a címben is szereplő Entourage és ErraiBus.
Az Entourage az Appcelerator egyik alprojektje. Maga az Appcelerator egy olyan keretrendszer, melynek segítségével mobil és desktop alkalmazásokat készíthetünk HTML és JavaScript segítségével. Maga a futtató környezet egy beágyazott böngésző, valamint egy általános API gyűjtemény, amin keresztül JavaScript-ből hívhatóak az adott platform natív funkciói. Így ha egyszer összeraktuk a HTML/Javascript alkalmazást, azt minden változtatás nélkül futtathatjuk Android telefonokon, IPhone-on, és készülhet belőle desktop alkalmazás is. Igazából a rendszer önnmagában is megérdemelne egy saját post-ot, így többet nem is mondok róla, inkább az Entourage-re koncentrálok. Az Entourage egy JavaScript library, amelynek alapja egy üzenet sor (message queue). Az üzenet sorba üzeneteket rakhatunk be JavaScript-ből, illetve funkciókat ültethetünk rá egy-egy üzenetre. Ez így önmagában nem nagy dolog, az izgalmas igazából az, hogy a keretrendszer mi mindent ki tud hozni ebből az egyszerű architektúrából.
Az Entourage üzenetsorra épül az Entourage Expressions, ami tulajdonképpen egy HTML-be ágyazható DSL, aminek segítségével JavaScript nélkül valósíthatunk meg AJAX-os működést. Egyszerűen az adott HTML tag-et kell ellátnunk egy
attribútummal. A condition rész tulajdonképpen egy esemény/üzenet az üzenet sorból, amit vagy mi tehetünk oda JavaScript segítségével, vagy a felhasználótól jöhet pl. click, hover, stb. Az action pedig ugyanúgy lehet egy újabb esemény küldése, vagy pedig valamilyen előre definiált működés pl. class attribútum cseréje, stb. Ezzel az egyszerű rendszerrel már eleve nagyon sok mindent meg lehet valósítani, mindezt JavaScript programozás nélkül egyszerű attribútumok használatával.
A következő szint az Entourage UI, ami tulajdonképpen egy az alsóbb szintekre épülő widget gyűjtemény. Itt egy control attribútum hozzáadásával definiálhatjuk a widget típusát és paramétereit, és annak szerkezetét általában a tag-ben szereplő HTML kód határozza meg (pl. ul/li tagok egy lista esetén). Ezzel az eszközzel már tulajdonképpen teljes AJAX-os felhasználói felületek építhetőek némi HTML tudással JavaScript ismerete nélkül.
Az utolsó komponens a Service Brokers, ami nekem a leginkább tetszett. A Service Broker-ek segítségével tulajdonképpen teljesen transzparens módon hozzákapcsolhatjuk a szerver oldali kódot az Ertourage alkalmazáshoz. A megoldás mindössze annyi, hogy a message queue-t úgy konfiguráljuk, hogy bizonyos üzeneteket a szerver felé továbbítson. JavaScript oldalról ez teljesen transzparens módon történik, hiszen ugyanúgy tudunk üzenetet küldeni a szerver felé, mint egy másik helyi komponens felé, ráadásul az egyszerű protokollnak köszönhetően szinte akármilyen programozási nyelven (Java,.NET, PHP, Python, stb.) és környezetben (Spring, Google App Engine, Pylons, stb.) készülhet a szerver oldal. Összességében tehát egy olyan rendszert kapunk, ahol - ha megelégszünk az alap készlettel -, JavaScript nélkül fejleszthetünk webalkalmazásokat úgy, hogy a szerver oldali keretrendszer teljesen szabadon választható.
A másik rendszer, ami az Entourage-hez hasonlóan üzenetkezelésen alapul, a JBoss egyik alprojektje, az ErraiBus. Az ErraiBus egy teljesen Java alapú rendszer. A rendszer kliens oldalát GWT-vel készíthetjük el, a szerver oldal futtatásához pedig valamilyen Java Servlet Container szükséges. A két oldal között egy üzenetsor segítségével kommunikálhatunk, tulajdonképpen ezt hívjuk ErraiBus-nak. Ha az előző megoldással hasonlítjuk össze, úgy hátrányának az mondható, hogy szorosan kötődik a Java nyelvhez (a GWT és a szerver oldal miatt is), ugyanakkor az előző light weight megoldáshoz képest ez igazi hard core megvalósítás, ugyanis az üzenetsor comet kapcsolaton keresztül működik, így tiszta kétirányú kommunikáció lehetséges. Nincs szükség külön poll-ozásra, és hasonló trükkökre, ugyanazzal az egyszerűséggel küldhetünk a szerverről a kliens oldalra, mint fordítva. Ez az architektúra tehát valóban real-time alkalmazásokat tesz lehetővé. Ha ehhez hozzágondolom, hogy GWT-ben már Quake-et is írtak, akkor látható, hogy egy ilyen rendszerrel a lehetőségek száma szinte végtelen. A transzparens működést pedig itt is az üzenet sor alkalmazása hozta.
A fentiek alapján úgy látom, hogy az üzenet alapú rendszerek előtt még nagy jövő áll, és sok esetben jelenthetnek nagyon kényelmes megoldást heterogén környezetben. Szerver oldalon az ESB és az ActiveMQ, kliens szerver kapcsolat esetén pedig az Entourage és ErraiBus jellegű alkalmazások. Én személy szerint szívesen látnék valamilyen egységes service bus megoldást, ami ezen rendszerek előnyeit egyesíti, tehát a buszra ugyanúgy "aggathatnánk" kliens oldali GWT alkalmazásokat, Appletteket, Flex, JavaScript, stb. alkalmazásokat, mint szerver oldali Java, PHP, .NET, stb. feldolgozókat, mindig az adott igényeknek megfelelően, sőt egy ilyen rendszerben sokkal szabadabban mozgathatnánk az egyes komponenseket, így ugyanazt a rendszert használhatnánk desktop környezetben (minden komponens a gépre kerül), webes, vagy mobil környezetben (bizonyos komponensek a szerveren maradnak).
Az Entourage az Appcelerator egyik alprojektje. Maga az Appcelerator egy olyan keretrendszer, melynek segítségével mobil és desktop alkalmazásokat készíthetünk HTML és JavaScript segítségével. Maga a futtató környezet egy beágyazott böngésző, valamint egy általános API gyűjtemény, amin keresztül JavaScript-ből hívhatóak az adott platform natív funkciói. Így ha egyszer összeraktuk a HTML/Javascript alkalmazást, azt minden változtatás nélkül futtathatjuk Android telefonokon, IPhone-on, és készülhet belőle desktop alkalmazás is. Igazából a rendszer önnmagában is megérdemelne egy saját post-ot, így többet nem is mondok róla, inkább az Entourage-re koncentrálok. Az Entourage egy JavaScript library, amelynek alapja egy üzenet sor (message queue). Az üzenet sorba üzeneteket rakhatunk be JavaScript-ből, illetve funkciókat ültethetünk rá egy-egy üzenetre. Ez így önmagában nem nagy dolog, az izgalmas igazából az, hogy a keretrendszer mi mindent ki tud hozni ebből az egyszerű architektúrából.
Az Entourage üzenetsorra épül az Entourage Expressions, ami tulajdonképpen egy HTML-be ágyazható DSL, aminek segítségével JavaScript nélkül valósíthatunk meg AJAX-os működést. Egyszerűen az adott HTML tag-et kell ellátnunk egy
on="[condition] then [action]"
attribútummal. A condition rész tulajdonképpen egy esemény/üzenet az üzenet sorból, amit vagy mi tehetünk oda JavaScript segítségével, vagy a felhasználótól jöhet pl. click, hover, stb. Az action pedig ugyanúgy lehet egy újabb esemény küldése, vagy pedig valamilyen előre definiált működés pl. class attribútum cseréje, stb. Ezzel az egyszerű rendszerrel már eleve nagyon sok mindent meg lehet valósítani, mindezt JavaScript programozás nélkül egyszerű attribútumok használatával.
A következő szint az Entourage UI, ami tulajdonképpen egy az alsóbb szintekre épülő widget gyűjtemény. Itt egy control attribútum hozzáadásával definiálhatjuk a widget típusát és paramétereit, és annak szerkezetét általában a tag-ben szereplő HTML kód határozza meg (pl. ul/li tagok egy lista esetén). Ezzel az eszközzel már tulajdonképpen teljes AJAX-os felhasználói felületek építhetőek némi HTML tudással JavaScript ismerete nélkül.
Az utolsó komponens a Service Brokers, ami nekem a leginkább tetszett. A Service Broker-ek segítségével tulajdonképpen teljesen transzparens módon hozzákapcsolhatjuk a szerver oldali kódot az Ertourage alkalmazáshoz. A megoldás mindössze annyi, hogy a message queue-t úgy konfiguráljuk, hogy bizonyos üzeneteket a szerver felé továbbítson. JavaScript oldalról ez teljesen transzparens módon történik, hiszen ugyanúgy tudunk üzenetet küldeni a szerver felé, mint egy másik helyi komponens felé, ráadásul az egyszerű protokollnak köszönhetően szinte akármilyen programozási nyelven (Java,.NET, PHP, Python, stb.) és környezetben (Spring, Google App Engine, Pylons, stb.) készülhet a szerver oldal. Összességében tehát egy olyan rendszert kapunk, ahol - ha megelégszünk az alap készlettel -, JavaScript nélkül fejleszthetünk webalkalmazásokat úgy, hogy a szerver oldali keretrendszer teljesen szabadon választható.
A másik rendszer, ami az Entourage-hez hasonlóan üzenetkezelésen alapul, a JBoss egyik alprojektje, az ErraiBus. Az ErraiBus egy teljesen Java alapú rendszer. A rendszer kliens oldalát GWT-vel készíthetjük el, a szerver oldal futtatásához pedig valamilyen Java Servlet Container szükséges. A két oldal között egy üzenetsor segítségével kommunikálhatunk, tulajdonképpen ezt hívjuk ErraiBus-nak. Ha az előző megoldással hasonlítjuk össze, úgy hátrányának az mondható, hogy szorosan kötődik a Java nyelvhez (a GWT és a szerver oldal miatt is), ugyanakkor az előző light weight megoldáshoz képest ez igazi hard core megvalósítás, ugyanis az üzenetsor comet kapcsolaton keresztül működik, így tiszta kétirányú kommunikáció lehetséges. Nincs szükség külön poll-ozásra, és hasonló trükkökre, ugyanazzal az egyszerűséggel küldhetünk a szerverről a kliens oldalra, mint fordítva. Ez az architektúra tehát valóban real-time alkalmazásokat tesz lehetővé. Ha ehhez hozzágondolom, hogy GWT-ben már Quake-et is írtak, akkor látható, hogy egy ilyen rendszerrel a lehetőségek száma szinte végtelen. A transzparens működést pedig itt is az üzenet sor alkalmazása hozta.
A fentiek alapján úgy látom, hogy az üzenet alapú rendszerek előtt még nagy jövő áll, és sok esetben jelenthetnek nagyon kényelmes megoldást heterogén környezetben. Szerver oldalon az ESB és az ActiveMQ, kliens szerver kapcsolat esetén pedig az Entourage és ErraiBus jellegű alkalmazások. Én személy szerint szívesen látnék valamilyen egységes service bus megoldást, ami ezen rendszerek előnyeit egyesíti, tehát a buszra ugyanúgy "aggathatnánk" kliens oldali GWT alkalmazásokat, Appletteket, Flex, JavaScript, stb. alkalmazásokat, mint szerver oldali Java, PHP, .NET, stb. feldolgozókat, mindig az adott igényeknek megfelelően, sőt egy ilyen rendszerben sokkal szabadabban mozgathatnánk az egyes komponenseket, így ugyanazt a rendszert használhatnánk desktop környezetben (minden komponens a gépre kerül), webes, vagy mobil környezetben (bizonyos komponensek a szerveren maradnak).
2010. június 5., szombat
ActiveMQ, MorbidQ - üzenet alapú aszinkron kommunikáció heterogén rendszerekben
Nem olyan régen egy projekt kapcsán a következő problémába ütköztem: kényelmi szempontból egy heterogén rendszert készítettem, aminek voltak web-es PHP-s részei, néhány időzített offline PHP script, meg néhány Java-s komponens. Alapvetően egy weblapról van szó, ahol az ügyfél termékeket rendelhet meg (web-es PHP rész), majd a megrendelések alapján egy időzített Java process előállítja a felhasználó számár elkészült csomagot (Java komponens), végül egy offline időzített PHP script e-mailben elküldi a csomagot a felhasználónak (offline PHP rész).
Mivel a lehetőségek elég szűkösek voltak, valami nagyon egyszerű megoldást kellett találnom a kommunikáció megvalósítására. A megoldás szinte adta magát, a megrendeléseket tároló adatbázis tábla szolgált az adatok átadására. A webes alkalmazás felvette a megrendelést a táblába, aztán cron-al néhány percenként elindítottam a Java process-t, ami ellenőrizte, hogy van-e új megrendelés. Ha volt, legenerálta a csomagot és átbillentette a rendelés állapotát. Végül az ugyancsak cron-ból futtatott PHP process ellenőrizte, hogy van-e postázni való. Ha volt, elküldte e-mailben, és átbillentette az állapotot. A rendszer egész jól működik is, de azért nem hagyott nyugodni a gondolat, hogy hogyan lehetne ezt még hatékonyabban megcsinálni. Az egyik ötlet, hogy a PHP engine és a Java VM betöltődési overheadjét elkerülendő mindkét process-t démonként kellene futtatni cron nélkül. Így sok erőforrást lehetne megspórolni, hisz nem kell minden esetben újra elindítani a JVM-et/PHP script engine-t, és betöltögetni az osztályokat/scripteket. Ez viszonylag egyszerűen kivitelezhető. A másik dolog, ami már inkább gondolkodóba ejtett, hogy amit csináltam, az tulajdonképpen egy primitív message queue. A web alkalmazás bedobja a megrendelés üzenetet, amit a Java alkalmazás feldolgoz, majd bedob egy postázás üzenetet, ami pedig az időzített PHP process-nek szól. Ezt biztos lehetne valahogy általánosítani. Egy olyan queue megoldás körvonalazódott a fejemben, aminek célja több alkalmazás aszinkron kommunikációja, ahol az egyes komponensek bármilyen környezetben készülhetnek, így a megoldás teljesen platform független. Adatbázisban gondolkodtam, schedulerekben, és valami cross-platform (mondjuk JSON) kommunikációban. Végül ahogy szokott, kiderült, hogy nem én vagyok az első, akinek megfordult a fejében egy ilyen rendszer gondolata.
Olyannyira, hogy már nevet is adtak neki, Enterprise Service Bus-nak (ESB) hívják, és a célja pont az amit az előbbiekben felvázoltam. Egy közös üzenet soron alkalmazások lógnak, és minden típusú kommunikációhoz külön szál (topic) rendelhető. Ha az egyik komponens akar valamit a másiktól, egy üzenetet helyez az üzenetsorba, amit a másik feldolgoz, és persze a dolog működhet két irányban, tehát a feldolgozó komponens egy másik üzenet soron vissza üzenhet a feladónak. A megoldás nagy előnye, hogy ha az üzenetek valamilyen általános formában mozognak, a Service Bus-t kényelmesen használhatjuk valamilyen heterogén környezetben (mint pl. az általam vázolt rendelési rendszer). A másik nagy előny az aszinkron jelleg. Azt ugyanis nem említettem, hogy a megrendeléshez tartozó alkalmazás csomag generálása igen erőforrás igényes folyamat. Tehát nem csak azért kellett ezt a megoldást használnom, mert a PHP webalkalmazásból nehézkes Java-t hívni, hanem azért is, mert a generálás miatt könnyen timeout-olhatott volna a PHP script, vagy ha több megrendelés van egyszerre, azt nem biztos, hogy bírná a szerver. Így az üzenetsor nem csak a heterogén rendszerben történő kommunikációra, hanem az erőforrások elosztására is kiváló eszköz. A fentebb vázolt probléma általános megoldása tehát odáig egyszerűsödött, hogy találjuk meg a megfelelő üzenetsor megoldást.
Olyan megoldás kell tehát, ami a legtöbb programozási nyelvben támogatott, nincs túl nagy erőforrás igénye, mégis megfelelően sokoldalú. Némi kutakodás után rátaláltam a STOMP protokollra. Ez a legtöbb programnyelvben támogatott üzenet protokoll, így ha heterogén rendszerekben (PHP, Java, Python, .NET, C++, stb.) működni képes megoldást keresünk, az nagyjából annyit tesz, hogy a megoldás legyen STOMP kompatibilis. Jelenleg két ilyen megoldást találtam, ezek között hezitálok.
Az ActiveMQ egy Java alapú megvalósítás, ami szinte mindent tud, amit egy ilyen üzenetsor megvalósítástól elvárhatunk. Klaszterezhető, JMS kompatibilis, támogatja a STOMP-ot (PHP, Python, stb. kompatibilis), ráadásul van hozzá egy Camel nevű valami, ahol DSL-ekkel leírt szabályok segítségével összekötögethetünk üzenet sorokat, újra rendezhetjük őket, broadcastolhatjuk az üzeneteket, stb., tehát konfigurálhatjuk az üzenet sort, és így különösebb programozás nélkül integrálhatjuk a komponenseket. A feature-öket tekintve nagyon szimpatikus megoldás, kérdés hogy mennyire erőforrás igényes.
A másik megoldás a MorbidQ ez Python-ban íródott, de STOMP kompatibilis, tehát ugyanúgy alkalmas heterogén komponensekből álló rendszer integrálására. Sokkal kevesebbet tud, mint az ActiveMQ, amire a honlapon is felhívják a figyelmet, hisz itt a lényeg az volt, hogy egy abszolút pehely súlyú megoldást nyújtsanak. Ez az erőforrás használat miatt lehet szimpatikus, de közelebbit nem tudok róla mondani, hisz nem próbáltam még ki, és nem hasonlítottam még össze az ActiveMQ-val.
Összefoglalva tehát ha a rendszerünk heterogén komponensekből épül fel, aszinkron üzenetkezelésre, erőforrás elosztásra van szükségünk (akár időben - soros végrehajtás, akár térben - klaszterezés), akkor ideális megoldás az üzenet sorok használata. Ilyen esetekben mindenképp érdemes számba venni ezek használatát, melyekből professzionális open source megoldások léteznek, mint pl. az ActiveMQ.
Mivel a lehetőségek elég szűkösek voltak, valami nagyon egyszerű megoldást kellett találnom a kommunikáció megvalósítására. A megoldás szinte adta magát, a megrendeléseket tároló adatbázis tábla szolgált az adatok átadására. A webes alkalmazás felvette a megrendelést a táblába, aztán cron-al néhány percenként elindítottam a Java process-t, ami ellenőrizte, hogy van-e új megrendelés. Ha volt, legenerálta a csomagot és átbillentette a rendelés állapotát. Végül az ugyancsak cron-ból futtatott PHP process ellenőrizte, hogy van-e postázni való. Ha volt, elküldte e-mailben, és átbillentette az állapotot. A rendszer egész jól működik is, de azért nem hagyott nyugodni a gondolat, hogy hogyan lehetne ezt még hatékonyabban megcsinálni. Az egyik ötlet, hogy a PHP engine és a Java VM betöltődési overheadjét elkerülendő mindkét process-t démonként kellene futtatni cron nélkül. Így sok erőforrást lehetne megspórolni, hisz nem kell minden esetben újra elindítani a JVM-et/PHP script engine-t, és betöltögetni az osztályokat/scripteket. Ez viszonylag egyszerűen kivitelezhető. A másik dolog, ami már inkább gondolkodóba ejtett, hogy amit csináltam, az tulajdonképpen egy primitív message queue. A web alkalmazás bedobja a megrendelés üzenetet, amit a Java alkalmazás feldolgoz, majd bedob egy postázás üzenetet, ami pedig az időzített PHP process-nek szól. Ezt biztos lehetne valahogy általánosítani. Egy olyan queue megoldás körvonalazódott a fejemben, aminek célja több alkalmazás aszinkron kommunikációja, ahol az egyes komponensek bármilyen környezetben készülhetnek, így a megoldás teljesen platform független. Adatbázisban gondolkodtam, schedulerekben, és valami cross-platform (mondjuk JSON) kommunikációban. Végül ahogy szokott, kiderült, hogy nem én vagyok az első, akinek megfordult a fejében egy ilyen rendszer gondolata.
Olyannyira, hogy már nevet is adtak neki, Enterprise Service Bus-nak (ESB) hívják, és a célja pont az amit az előbbiekben felvázoltam. Egy közös üzenet soron alkalmazások lógnak, és minden típusú kommunikációhoz külön szál (topic) rendelhető. Ha az egyik komponens akar valamit a másiktól, egy üzenetet helyez az üzenetsorba, amit a másik feldolgoz, és persze a dolog működhet két irányban, tehát a feldolgozó komponens egy másik üzenet soron vissza üzenhet a feladónak. A megoldás nagy előnye, hogy ha az üzenetek valamilyen általános formában mozognak, a Service Bus-t kényelmesen használhatjuk valamilyen heterogén környezetben (mint pl. az általam vázolt rendelési rendszer). A másik nagy előny az aszinkron jelleg. Azt ugyanis nem említettem, hogy a megrendeléshez tartozó alkalmazás csomag generálása igen erőforrás igényes folyamat. Tehát nem csak azért kellett ezt a megoldást használnom, mert a PHP webalkalmazásból nehézkes Java-t hívni, hanem azért is, mert a generálás miatt könnyen timeout-olhatott volna a PHP script, vagy ha több megrendelés van egyszerre, azt nem biztos, hogy bírná a szerver. Így az üzenetsor nem csak a heterogén rendszerben történő kommunikációra, hanem az erőforrások elosztására is kiváló eszköz. A fentebb vázolt probléma általános megoldása tehát odáig egyszerűsödött, hogy találjuk meg a megfelelő üzenetsor megoldást.
Olyan megoldás kell tehát, ami a legtöbb programozási nyelvben támogatott, nincs túl nagy erőforrás igénye, mégis megfelelően sokoldalú. Némi kutakodás után rátaláltam a STOMP protokollra. Ez a legtöbb programnyelvben támogatott üzenet protokoll, így ha heterogén rendszerekben (PHP, Java, Python, .NET, C++, stb.) működni képes megoldást keresünk, az nagyjából annyit tesz, hogy a megoldás legyen STOMP kompatibilis. Jelenleg két ilyen megoldást találtam, ezek között hezitálok.
Az ActiveMQ egy Java alapú megvalósítás, ami szinte mindent tud, amit egy ilyen üzenetsor megvalósítástól elvárhatunk. Klaszterezhető, JMS kompatibilis, támogatja a STOMP-ot (PHP, Python, stb. kompatibilis), ráadásul van hozzá egy Camel nevű valami, ahol DSL-ekkel leírt szabályok segítségével összekötögethetünk üzenet sorokat, újra rendezhetjük őket, broadcastolhatjuk az üzeneteket, stb., tehát konfigurálhatjuk az üzenet sort, és így különösebb programozás nélkül integrálhatjuk a komponenseket. A feature-öket tekintve nagyon szimpatikus megoldás, kérdés hogy mennyire erőforrás igényes.
A másik megoldás a MorbidQ ez Python-ban íródott, de STOMP kompatibilis, tehát ugyanúgy alkalmas heterogén komponensekből álló rendszer integrálására. Sokkal kevesebbet tud, mint az ActiveMQ, amire a honlapon is felhívják a figyelmet, hisz itt a lényeg az volt, hogy egy abszolút pehely súlyú megoldást nyújtsanak. Ez az erőforrás használat miatt lehet szimpatikus, de közelebbit nem tudok róla mondani, hisz nem próbáltam még ki, és nem hasonlítottam még össze az ActiveMQ-val.
Összefoglalva tehát ha a rendszerünk heterogén komponensekből épül fel, aszinkron üzenetkezelésre, erőforrás elosztásra van szükségünk (akár időben - soros végrehajtás, akár térben - klaszterezés), akkor ideális megoldás az üzenet sorok használata. Ilyen esetekben mindenképp érdemes számba venni ezek használatát, melyekből professzionális open source megoldások léteznek, mint pl. az ActiveMQ.
Feliratkozás:
Bejegyzések (Atom)