jTechnics

JMX és JBI

Sunday, January 4th, 2009 | Uncategorized | No Comments

Ott hagytam abba múltkor, hogy milyen jó, hogy a JBI specifikáció beszél a deployolás és menedzsment témaköréről is, és ANT taskokat valamint JMX bean-eket definiál. (Vesd össze EJB specifikációt, ahol minden menedzsment funkció gyártófüggő).

Nagy örömömben akartam is írni egy egyszerű eszközt, ami alapműveleteket tud elvégezni bármilyen JBI konténeren. Beleástam magam a JBI és a JMX bugyraiba, és rögtön jöttek is a gondolok:

A JBI specifikáció definiálja az MBean interface-eket, amiket implementálni kell, de azt nem, hogy az MBean-eket milyen domain alá kell regisztrálni, így mindenki a saját domain alá regisztrálja a JMX fában a szabvány szerint implementált MBean-jeit. Az lenne a jó, ha lenne egy olyan JMX metódus, amivel egy adott interface-t megvalósító MBean-eket kérem le, de ezt a funkciót sehogyan sem sikerült életre keltenem.

Elvileg van egy isInstanceOf metódus az MBeanServerConnection osztályon (amit a Query API is használ), de ennek a dokumentációja elég körmönfont:

Returns true if the MBean specified is an instance of the specified class, false otherwise.

If name does not name an MBean, this method throws InstanceNotFoundException.

Otherwise, let
X be the MBean named by name,
L be the ClassLoader of X,
N be the class name in X’s MBeanInfo.

If N equals className, the result is true.

Otherwise, if L successfully loads both N and className, and the second class is assignable from the first, the result is true.

Otherwise, the result is false.

Azaz ClassLoader-től függ, hogy mit ad vissza. OpenESB-nél úgy néz ki, hogy a szabványos MBean interface-t leszármaztatja egy com.sun-s interface és annak van implementációja. A com.sun-os interfacre működik az isInstanceOf alapú keresés de ami lényeg lenne a javax.jbi.management-re nem lehet, úgy tűnik azért mert különböző ClassLoader-ek töltik be a com.sun és a javax.jbi osztályokat.

Elvileg találtam utalásokat, hogy a Java 7-ben ez meg lesz jobban oldva (heló 2010). Láttam nyomait továbbá egy valaha létezett JBI Maven pluginnek (forrását nem sikerült elérni), ami deployolni is tudott. Nagyon érdekelne, hogy ott hogy sikerült megoldani a problémát. A ServiceMix-hez szállított ANT taskok forrását megnéztem, ott hardcode-olva vannak a ServiceMix-es MBean-ek címei.

Tags: jbi, jmx

JBI 1.0

Thursday, January 1st, 2009 | Uncategorized | No Comments

Olvasgatom a Java Business Integration specifikációt, nem egy könnyű olvasmány: pl. az EJB specifikáció véleményem szerint sokkal olvasmányosabb (annak ellenére könnyebb átlátni, hogy háromszor annyi oldal).

Akik nem ismernék, annak tájolásképpen: egy SOA-s szabványról van szó, ami az Enterprise Service Bus (ESB) mintát valósítja meg. Lényegileg egy közös üzenetet közvetítő busz köré lehet komponenseket telepíteni. Ebből logikailag két fajta van: Binding Component (BC) és Service Component (SC). A BC-k tipikusan a külvilágból jövő kéréseket konvertálják belső XML-es üzenetekké (tipikus BC-k: SOAP, REST, Email, FTP, XMPP,…), az SC-k pedig általában e buszon szaladgáló üzeneteket alakítgatják vagy a business processt irányítják (tipikus SC-k: XSLT, BPEL, EJB, Scripting). Ezeket lehet össze drótozni a busz mentén, sőt a komponensekbe még lehet deployolni további adatokat (pl. XSLT processorba XSLT-t, BPEL motorba BPEL fájlt, stb).

Számomra a jelenleg problémás részek (én ezeket olvastam ki, de javítsatok ki, ha nincs izagazam).

1. Ha jól értem, akkor a komponensek routolása egyáltalán nem található ki sehonnan. Bár lehet a jbi.xml-ekben routing adatokat megadni, ez egyáltalán nem kötelező. Sok helyen láttam, hogy a a BC-kbe és SC-kbe amikor beledeployolunk akkor egy WSDL-t is deployolunk (A fent elmlített XSLT, BPEL, stb.-k mellett), és ebben a WSDL-ben definiáljuk, hogy milyen endpointot hív meg a komponenes / milyen címen hívható meg. Ez a deployolás azonban teljesen komponenes függő, semmilyen API nincs, amiből utaná kideríthető lenne a routolás.

2. ESB-ről van szó, tehát egy közös buszon közlekednek az üzenetek. Az üzenetet fel lehet küldeni a buszra, valamit ki lehet róla olvasni az üzenetet, de a kiolvasás nem valami listener jellegű interface-en keresztül megy, hanem pollozással. Emiatt ha több szálon szeretnénk feldolgozni az üzeneteket jó eséllyes valami saját thread pooling megoldást kell implementálnunk.

Message reception always follows the “pull” model: the JBI component MUST pull the message exchange instance from the DeliveryChannel, using its own thread of execution. Components MAY use more than one such thread, allowing concurrent message reception by the component. The JBI implementation MAY satisfy multiple accept() requests from a single component in arbitrary order.
(JBI 1.0 spec, 44. oldal)

Továbbá a Future Directions fejezetből (205. o.):

Adoption of a work manager (from another JSR) to allow components to not have to manage their own threads.

Erre persze az a megoldás, hogy minden JBI gyártó csinál saját könyvtárat, ami a JBI nagyon alacsony szintje fölött még egy kényelmesebb absztrakciós szintet ad. (Pl. az OpenESB-nél ezt nevezik Component Toolkit-nek).

Mindent összevetve a JBI mint specifikáció még nem győzött meg. Ha nem lenne adottság lehet, hogy alaposabban megismerkednék az előző bejegyzésekben ajánlott Mule-val, ami szabványt nem implementál, de cserébe okos és egyszerű eszköznek tűnik.

Bár az is lehet, hogy ha tovább elmélyedek a JBI-ben nég változik a véleményem. Az például nagyon jó benne, hogy JMX alapú management API-t ad komponenesek telepítéséhez, deployolásához, stb.

Tags: jbi

JBI próbákozások

Saturday, December 27th, 2008 | Uncategorized | 3 Comments

Régebben egyszer már volt egy ESB-s/JBI-s korszakom, de most úgy tűnik, hogy a munkám is erre fog kanyarodni a jövőben. Elkezdtem hát nézegetni újra az OpenESB-t és más alternatív JBI implementációkat.

(Figyelmeztetés: a következő megjegyzések nem tükrözik az egyes szoftverek minőségét, csupán olvasónapló szerű megjegyzések találkozásokról.)

OpenESB: előszőr evvel próbáltam gyorsan képbe kerülni. Ha jól értem GlassfishESB-néven fut kitüntetett és terjesztett változat, és most van belőle RC. Régen volt egy olyan vonulat, hogy command line-ból is futtatható legyen, ennek aktuális változatát nem találtam. Gondolom a következő generációs OSGIre épülő változat, majd tudni fogja, és addig már nem nagyon. A Fuji viszont ha jól értem a 2009-es J1-re lesz csak Technology Preview, tehát nem lesz aktuális a kövekező időszakokban.

Nemrég tanuja voltam, ahogy valaki próbál konzolból forgatni egy OpenESB-s alkalmazást (alapból ezt a hozzá kapott NetBeans-szel lehet). Hát a szokásos ANT-os library varázslatok kellettek hozzá, csak a Jar filok egy része ráadásul a NetBeans része volt, és onnan kellett volna előbányászni. A mai világban, amikor a CI már elég alap dolognak számít, azért elvárnám, hogy ne kelljen vért pisálni a konzolos fordításhoz.

Még -1: NetBeans 6.1-et adnak alapból az ESB-hez, mert ahhoz vannak jól meg a pluginek (nem NB hívőknek: 6.5 az aktuális verzió)

ServiceMix: Apache projekt. Ehhez már nem kell alkalmazás szerver, futtatható konzolból is. A 3-as verziójú család támogatja a JBI szabványt, a 4-es az OSGi-t. A 4.1-es fogja mindkettőt. Tehát egyelőre a 3-asnál maradok.

Elfog a kisördög, és megpróbálom tesztelni a JBI kompatibilitását úgy, hogy az OpenESB-be deployolom a részeit. Sajnos a shared library komponens nem tartalmaz mindent (a ServiceMix classpath-ában benne van a commons-logging, de ez nem várható el minden JBI konténertől), ezért nem futnak a BC-k OpenESB-n. Egy minusz pont. A legegyszerűbb példa alkalmazás szintén nem JBI kompatibilis, mert a jbi.xml leíró nincs rendesen legenerálva: -2.

Ezekel a kellemetlen dolgokat leszámítva nem néz ki rosszul a dolog, van hozzá pl. sok barátságos Maven plugin, és elég részletes dokumentáció.

PEtALS, ez meg OW2 projekt. Erre jutott még a legkevesebb idő, (=ezzel foglalkozom éppen most) de ez is kedves kis cuccnak tűnik. A komponenesek általában tartalmazzás az összes függőségüket is, simán sikerült depoyolnom az OpenESB-be egyet. Van hozzá webes konzol és onnan is lehet deployolni.

Következő feladat: újra átfutni a JBI speckót. (Illetve utánanézni, hogy mikor lesz már JBI 2.0).

Tags: esb, jbi, openesb, petals, servicemix

Unitils EJB3 modul

Monday, December 22nd, 2008 | Uncategorized | No Comments

Az Unitils-ről szerintem már volt szó itt is: egy nagyon szimpatikus teszt keretrendszer, ami a JUnit és a TestNG tesztek írását tudja nagyon kellemesen megtámogatni. Különböző modulok vannak hozzá (dbunit, Hibernate, JPA EasyMock, Spring) és ezek teszteléséhez egy nagyon használható környzetet ad, ahol annotációk könnyítik meg az életünket.

Most az egyik projektünk a vége felé jár, amiben ezt használtuk EJB3 tesztelésre, és mivel ez a része a projektnek általánosabb a többinék kifaktoráltunk open sourcenak.

A lényege a modulnak, hogy a teszt osztályokat nagyjából úgy lehet használni, mint egy EJB osztályt. Lehet bennük használni a @EJB-t, a @PersistenceContext-stb. és a modul elintézi, hogy az EJB-k ott is legyenek beleinjektálva a teszt lefutása előtt.

A projekt státusza stabil béta: kb. egy éve használjuk egy projektben nagy megelégedéssel: ami implementálva van az stabilan működik, ami nincs implementálva benne (pl. tranzakciós annotációk) azok stabilan nem működnek.

Unitils EJB module a google code-on.

Tags: ejb3. test, junit, unitils

SnipSnap2XWiki migráció

Sunday, November 30th, 2008 | Uncategorized | No Comments

Van még egy mellékszál: a JHacks-et jó lenne XWiki-re migrálni. Egyelőre csináltam egy kis projektet, ami a SnipSnap dump-ból csinál XWiki dumpot, amit utána egy laza importal be lehet rakni az XWiki-be.

Jelenlegi eredmény itt:

http ketőspontperper dev pont jhacks.anzix.net:9080/xwiki

A migrációba segíteni itt lehet:

http://code.google.com/p/snipsnap2xwiki

Tags: migrator, snipsnap, wiki, xwiki

Single Sign On keresés

Saturday, November 29th, 2008 | Uncategorized | No Comments

Kéne egy SSO megoldás, ami:

1. Cross-domain SSO-t is tud, azaz ha van két teljesen különböző domainem, és az egyik alatt belépek, a másikon is automatikusan be legyek.

2. Lehessen kapcsolni hozzá teljesen különböző alkalmazásokat is, pl. Apache httpd alapú SVN szervert. (Erre elvileg az is megoldás, hogy ha LDAP-ba tárolja a felhasználó adatokat az SSO).

3. Legyen valami felület, ahol a felhasználó tud: regisztrálni (default jogokat kap), jelszót változtatni, elfelejtett jelszóhoz emlékeztetőt kérni, stb.

Ahol tartok:

1. OpenSSO

Glassfish Prelude alá nem ment fel*.

Glassfish V2 alá felment, viszont nagyon kevés jó tutorialt találok hozzá. Lehet hogy az a baj, hogy nagy a zaj a kereséseimre: teleptésí leírás sok van, de, hogy a fenti célokat hogy tudom elérni, az egyelőre rejtély. Valószínű végig kell nyálazni a Sun-os Access Manager doksikat. Illetve a opensso wiki-ben belinkelt cikkeken kéne végig menni.

Mindehhez tartozik, hogy az egész cucc 270Mb (ebből a deployolandó war 80Mb), tehát nem egy pehelysúlyú megoldás.

Amit eddig láttam belőle: 1-2-t tudni fogja, de a 3-at még nem láttam benne.

2. Josso

Csak a weboldalát nézegettem eddig, de úgy tűnik ehhez 3-as web felületet nekem kell csinálni. A dokumentáció szerves része, hogy végeláthatatlan config fájl példákat idéznek. Le kéne tölteni, és megnézni közelebről.

3. CAS

Még annyit sem foglalkoztam vele, mint a Josso-val. Azzal kéne kezdeni, hogy 1-et tudja-e.

* Két gépen (Hardy / Intrepid) is próbáltam, az egyiken Glassfish V2 alá gond nélküld felment. Amikor nem megy, akkor a jó jelszóval belépés után ugyanaz a belépőfelület jelenik meg mindenféle hibaüzenet nélkül (a logban se találtam semmit). Ha rossz jelszóval próbálkozom, akkor kiírja az autentikációs hibát.

Tags: cas, josso, opensso, sso

Cont.

Wednesday, November 26th, 2008 | Uncategorized | 2 Comments

A legnehezebb mindig hosszabb kihagyás után felvenni a posztok fonalát.

A helyzet tehát a következő:

1. Mostanában alig látok kódot, egyfolytában specifikációt írunk. Viszont az XWiki, amibe írjuk viszonylag jól muzsikál. Megérne egy posztot. Megint kedvet kaptam a jhacks snipsnap2xwiki migrációval egy kicsit szöszölni.

2. Volt JUM (erről is kellett volna egy külön poszt). Röviden: sok mindent nem sikerült a terem mizéria miatt megcsinálni amit terveztünk (moderálás, előadói értékelés), számomra mégis az utóbbi idők legreménykeltőbb alkalma volt. Nem az előadások miatt, hanem mert úgy tűnt, hogy mégis csak életképes az egész kezdeményezés, és vannak mások is (azokon kívül, akikkel eddig szerveztük) akiket érdekel az egész, és hasonlóan gondolkodnak. (Elég jók voltak a kommentek és a beszélgetések is az alkalom alatt)  .

Arról nem is szólva, hogy már most függőben van 2-3 megígérte előadás, egy ajánlat teremre, és egy szinte biztos angol előadás az Adobe-től Flex + Java integrációról. Ilyen eddig még sohasem volt.

3. Most már biztos, hogy megyek Devoxx-ra. Jó lenne Géza Java One-os közvetítéséhez hasonló (illetve természetesen annál jobb (: ) dolgot is csinálni közben. (Mégjobb lenne másokkal együtt. Vajon ki megy még Magyarországról?)

Ötleteim vannak hozzá, de egyelőre sehogyan sem sikerült laptopot szereznem (nekem nincs), és pénzem sincs nagyon, amiből venni tudnék. Kölcsönözni kb. 50 ezer forint. Még az jöhet szóba, hogy interneten rendelek egyet, és a törvényi szabályozás értelmében 8 munkanapon elállhatok a szerződéstől, tehát visszaviszem és megkapom a pénzt, de ez is csomó kockázatot rejt.

Viszont a hétvégéig ki kéne találni, hogy mi lesz, mert jó lenne előzőleg már felhúzni egy blogot/honlapot neki.

(Tavaly a TSS európai szimpóziumán az volt a metódus, hogy nap közben jegyzeteltem, és este az internet caféból írtam bejegyzéseket, de ahogy néztem itt azért bőven lesznek este 22-kor végződő programok, és a helyszín is elég messze lesz az ifjúsági szállástól).

DependencyFinder

Friday, October 3rd, 2008 | Uncategorized | No Comments

Elkövettük azt a hibát, hogy a hónapok során egyre inkább függő lett a GWT kódunk egy GUI könyvtártól. Szép menük, gombok vannak benne, amit nagyon sok helyen használunk, de most már úgy látjuk, hogy jó lenne kicserélni egy másik library-ra, de még inkább egy független wrapperre, ami mögött cserélgethetnénk a megvalósításokat.

De vajon mennyire függ a kódunk a library-tól. Kéne valami függőség felmérő, ami kiírja, hogy milyen nehéz lenne kitakarítani a kódunkból az idegen osztályokat. A JDepend-ben, és társai-ban sajnos nem találtam olyat, ami ilyet csinálni, csak mindenféle mérőszámokat kaptam.

Végül a dependency finder programra találtam rá. Csúnya oldal, csúnya GUI, kicsit átláthatatlan felület, de kis nyomogatás után ki írta ami kellett: egy adott szöveggel kezdődő csomagoktól milyen osztályaim függenek.

Kezdődhet a takarítás.

Tags: code, dependency, refactor

PureMVC

Friday, September 26th, 2008 | Uncategorized | No Comments

Egy nagyon alap MVC keretrendszer (kihitte volna a neve alapján) egy csomó nyelv alá implementálva (eredetileg Flash/Action Script-re készült), én úgy találtam rá, hogy épp most készült egy GWT port hozzá. Nagyon kicsi (az alap Java-s változat, ami J2ME-vel is kompatibilis ~17kb), nagyon egyszerű, és képileg nagyon szép architekturális diagramja van.

A lényege, hogy van egy nagy Singleton, amikbe beregisztráljuk a View, Commander és Model osztályokat. A View osztályokat Mediátornak hívja, és igazából nem ez maga a View, hanem csak egy ragasztó osztály a meglévő felülethez. Hasonlóan a Modelhez Proxy osztályokkal ragasztunk dolgokat, a Controller rész meg sok kis Command-ot jelent.

Az egész egy nagy Design Pattern állat kert. Az objektumok közötti kommunikáció Observer minta alapján megy, különböző névre lehet beregisztrálni, és neveken keresztül üzennek egymásnak a Mediátorok, Commandok és Proxyk.

Egy kicsit gyanús benne ez a túl nagy egyszerűség, meg a sok Singleton, de elvi ellenérveket még nem nagyon találtam ellene.

Az a terv, hogy kipróbálom az épp aktuálisan futó J2ME projektemen (BKV menetrend és útvonaltervező, a bétánál is bétább). Elég kicsinek tűnik, hogy hasznos legyen, és a segítségével valószínű egyszerű lesz többfajta felületet gyártani a kódhoz. (pl. egy primitív CLDC 1.0/MIDP 1.0-sat, és egy kicsit okosabb LWUIT-osat.).

Meglátjuk.

Tags: framework, mvc, patterns

XWiki a házban

Tuesday, September 23rd, 2008 | Uncategorized | 2 Comments

Az XWiki-vel már többszőr próbálkoztam, de valahol mindig elvérzett a dolog. Az UTF-8 támogatásnak pl. nagyon sokáig ellenált, az pedig, hogy a XXI. században valaki alapból ISO-8859-1-es alkalmazást fejleszt, eleve gyanús. (A jelek szerint franciák fejlesztik.)

Néhány hete újra tettem egy kísérletet, és nagyon kellemesen csalódtam. Végre nem kellett sárkányokkal küzdeni, hogy ékezetekkel együtt felmenjen. Néhány config fájl szerkesztés, deploy, és megy.

A wiki oldalak sebessége is kezd barátságos lenni, a felülete viszonylag okos. Vannak még ugyan dolgok, amire nem jöttem rá (pl. hogy lehet kis template darabokat írni Groovy-ba, hogy azok minden oldalon elérhetőek legyenek include nélkül), de különben remekül muzsikál. Csak ajánlani tudom másoknak is.

Tags: xwiki