JavaCard Classic

Volt egy projekt egy-két hónapja, amiben JavaCard technológiát használtunk. Most már teljes a skála, JavaCard-tól MIDP-n és Standard Edition-on keresztül a J2EE-ig mindent programoztam Java-ban. Igaz, a JavaCard-nak éppenhogy csak karcoltam a felszínét, de arra ez is elég hogy rálátás legyen. Most csak konyhanyelven írom le hogy megy ez a dolog:

Gyakorlatilag java-t kell programozni, de az osztálykönyvtár irdatlanul le van csupaszítva és csak 2 bytes-os adatszerkezetek vannak, tehát tele van az egész kód short kasztolásokkal és tömbműveletekkel. Úgynevezett javacard appleteket kell programozni, amiknek saját primitív tranzakciókezelésük és belső security managementjük van, lényegében perzisztens szerkezetűek és byte alapú módon kell kommunikálni velük. A kártyában pár kilobájt EEPROM áll rendelkezésünkre a programhoz és az eltárolt adatokhoz. Egy kártyára több appletet is installálhatunk. Sok firkálás után a kártya szépen tönkremegy.

A kártya valójában nem igazi bájtkódot futtat, hanem speckó eszközzel kell lefordítani a java forrást egy jobban megemésztett formátumra. Például a standard java-val ellentétben a linkelési információk nem kerülnek be a lefordított bináris állományba, hanem azokat egy másik állományban tárolják kb. név, index párokként. Az eszköz és a doksik letölthetőek a netről, van valami plugin Eclipse-hez (JCOP) ami szimulálni tudja a kártyát és kommunikálni tud magasabb szinten a géphez csatlakoztatott kártyaolvasókkal.

Az appletnek van egy belépési metódusa, ami egy az egyben megkapja azokat a bájtokat, amiket a kártya vett a külvilágtól akár a felületre integrált csatlakozási pontok, akár egyéb átviteli módszerrel. Pl. vannak RFID-vel vagy NFC-vel kommunikáló kártyák. Az RFID egyébként hasonlóan működik mint egy trafó. Váltakozó áram indukálódik a kártyában, ami egyben magát az adatot is jelenti, emellett a kártya áramellátását is megoldja arra az időre amíg az adatok feldolgozódnak. vicces nem?

Visszatérve a bájt tömbre: van egy viszonylag kötött formátumú fejléce, amit a kártya mini oprendszere kiértékel. Ez az első körben max kb 256 byte hosszú bájtsorozat használható az authentikációra, új applet telepítésére, törlésére, kiválasztására, befixálására. Megfelelő számú partizán kísérlet után a kártyát jól le lehet tiltani örökre. Ugyanezt a bájtsorozatot használhatjuk az appletben a saját protokoll kialakításához. Hosszabb bájtsorozatokra van valami összeillesztős mechanizmus.

A konvencionális java SE programokkal ellentétben a javacard applet mezőváltozói perzisztensek, azaz ha valamit beállítok az úgy is marad magától. Tehát mezőváltozóban lehet tárolni ilyeneket, hogy hányszor használták a kártyát. Ha jól emlékszem van valami commit-szerű művelet is, amivel gondoskodni lehet (kell?) róla, hogy a beírt értékek valóban perzisztálódjanak, és ezt ráadásul egyszerre tegyék. A változtatásokat a javacard egy kb 256 byte-os RAM pufferben gyűjti és a commit-nál beírja az EEPROM-ba. Ha túl sok változtatást akarunk csinálni, a puffer túlcsordul és hibát kapunk.

A kimenet szintén egy bájtsorozat. Össze kell rakni és elküldeni. PC oldalon vannak driverek, amikkel meg lehet hajtani mindenféle csatlakoztatott kártyaolvasókat, de most hirtelen nem is tudom milyen interfész van hozzájuk.

Ahogy a Sun Java Cafés postban írtam, a 3-as JavaCard verzióban bevezetnek egy új programozási módot, amiben magasabb szinten, szervletekkel (ezek sem igazi szervletek) lehet programozni a kártyákat. Ezt nevezik Connected Edition-nek.

Amiről én írtam az még a régebbi spec, amit meghagytak és Classic Edition-nek hívják.

Eredményhirdetés

Köszi hogy 31-en nyilvánítottatok véleményt! A végeredményt idemásolom, hogy akkor is látható legyen, amikor az oldal széléről majd eltűnik és a múlt homályába vész:

• 7 ember (22%) 100%-ban szXrt lapátol.
• 10 ember (32%) 80%-ban szXrt lapátol, de 20%-ban király dolgokkal foglalkozik.
• 9 embernél (29%) fele-fele ez az arány.
• 1 embernél (3%) inkább a király dolgok felé dől a mérleg, 80%-ban ezzel foglalkoznak.
• 3-an (9%) folyamatosan király dolgokat csinálnak profi csapatban.
• 1 szavazó pedig nem szoftverfejlesztő.

Mivel ez egy egyszerű közvéleménykutatás volt, nem derülnek ki bizonyos dolgok, például:

-Milyen szakterületekre koncentrálódik a lapátolás nagy része? Azt gyanítom, hogy főként az ügyviteli és banki szoftverekre. Technológiai és akadémiai/kutatás témakörben készült szoftvereket gondolom jobban összeraknak. Például több idő van a tesztelésre. Emellett úgy gondolom az open source szoftverekben kevesebb a szégyellendő, rejtegetnivaló megoldás.

-Milyen programnyelvre koncentrálódik a gányolás nagy része? Igaz hogy C-ben, C++-ban életveszélyesebb dolgokat lehet összehozni mint Java-ban vagy PHP-ben, de talán pont ezért a C, C++ programozóknál precízebb munkára van szükség. Modernebb nyelveknél/platformoknál, vagy legalábbis a Bábel torony felsőbb emeletein nagyvonalúbban dobálóznak rétegekkel, konverziókkal, magasszintű komponensekkel. Felhígul a társaság, divat van, nincs meg az elhivatottság. Nem utolsósorban műszakilag műveletlenebb megrendelőkkel konfrontálódnak ezen a szinten a fejlesztők és jobban beleszól a politika a tervezésbe ami kimondja mikor mit kell használni -függetlenül attól hogy az eszköz alkalmas-e az adott feladatra. Itt már visszakanyarodunk lassan a szakterületekre.

-A válaszok nyilván szubjektívek és önkritikán alapulnak. Az is lehet hogy valaki bepipálta hogy király dolgokat csinál profi csapatban, közben pedig a TheDailyWTF-nek kimeríthetetlen témaforrást tudna biztosítani. A fordítottját nehezebben tudom elképzelni, hogy egy elégedetlen munkásember valójában egy nagyon irigylésre méltó team-ben dolgozik. Ki mennyire becsüli meg a melóját? Erről is szólt ez a szavazás.

-Ha valaki szXrt lapátol, miért nem koccol le? Ez csak költői kérdés. Pár dolog közrejátszhat a maradásban. Pl. lojalitás (muhaha), pénz, van aki hisz benne hogy jobbra fordul a helyzet, a következő projekt jobb lesz és ne titkoljuk: van aki belekényelmesedik a helyzetébe.

-Végül ahol király csapatban profi dolgokat csinálnak az emberek az vajon melyik cég lehet és keresnek-e mostanában náluk munkaerőt? És vajon lehet-e itt a blogon privát üzenetet küldeni nekem ezügyben? :)

Eclipse J2EE támogatás

Kipróbáltam az Eclipse 3.3 J2EE edition J2EE alkalmazás támogatását. Nem nagyon találtam róla épkézláb leírást és csak 1-2 órányi kísérletezés után sikerült kitalálni, hogy milyen sorrendben kell csinálni a dolgokat és tulajdonképpen mi micsoda. A help-ben sokminden van, de egy lényegretörő leírás nincs, hogy "figyelj, így kell összerakni egy móricka-szintű J2EE alkalmazást", ezért most lepötyögöm ide.

Figyelj, így kell összerakni egy móricka-szintű J2EE alkalmazást:

Először is az Eclipse J2EE edition támogatja appszerverek vezérlését az IDE-n belül. Glassfish V2-t választottam játszásra, ami alapból nincs a támogatott szerverek között, de le lehet tölteni a modult. A konzol view-eknél van egy új fül Servers névvel. Lokális és távoli szervert is fel lehet venni, én lokálban próbálom. Gyakorlatilag elindítani és leállítani tudja a szervert, nem veszi észre a fenn lévő alkalmazásokat és ha Eclipse-n kívül indítom el akkor is zavarba jön. Azt hiszi hogy nincs elindulva és nem találtam olyan funkciót amivel frissíteni lehetne az állapotot - pedig nagyon meg tudnám becsülni. Szóljon aki tud ilyet! Ezen kívül megjelenik az appszerer logja egy konzol ablakban. Ja igen és debugolni is lehet az enterprise alkalmazást.

Leírom nagyjából hogyan néz ki egy ilyen J2EE alkalmazás belülről. EAR-ban vannak JAR-ok, WAR-ok és különböző XML-ek. (EAR, WAR, JAR: kb zip formátum.) Ezt kell bedobni az alkalmazás szerverbe. Ezenkívül lehet külső kliens, ami sima Java, csak még gondoskodni kell egy közös osztálykönyvtárról ami a külső kliens és az Enterprise App közti interfészeket tartamazza. Ez tipikusan egy jar, ami a kliensnél és a szerveren is megvan az EAR fájlban.

Csináljunk J2EE alkalmazást!

New J2EE application project
Target runtime, configuration - maradhat default, de később is még felajánlja. EJB3-as alkalmazást akarok csinálni.
J2EE modules to add - ha vannak más moduljaink. Generate deployment descriptor - csekkeljük be jól jön az.
Van itt egy olyan gomb hogy New module. Érdemes megnyomni mert rögtön felajánlja hogy csináljon-e client, ejb, web és connector modulokat. Engem most a web és a konnektor nem érdekel, azt nem csekkeltem be.
Rögtön létre is hozza a két projektet. (XXXEARClient, XXXEAREjb) Az EAR kliens alatt az én értelmezésemben pl. egy desktop alkalmazást értek *, ami cseszeregteti az EAR-t. JUnit teszteknek kiválóan alkalmas.
Finish. Megcsinálta az EAR-t is, átváltódunk J2EE perspektívába. Ha jól látom nem csinált szabványos ejb-jar-t, -hiába ikszeltem be- csak sun-ejb-jar-t.

Az EJB projekt context menüjében a J2EE menüpont alatt ki lehet választani a create EJB Client jar-t. Ezzel létrehozunk egy újabb projektet, amiben az EJB interfész osztályait tároljuk: business interfészek, kliens és szerver között mozgatott adatszerkezetek, utility osztálok kerülnek ide. Az EAR kliens projektben a J2EE module dependencies-ben be kell állítani, hogy lássa az EJB kliens projektet.

Új EJB3-at csak kézzel lehet létrehozni jelenlegi tudásom szerint.

-Az EJB kliensbe kell felvenni tehát egy interfészt ami a lokális vagy remote interfész lesz. Alaphelyzetben az ejbModule a forrásfolder. Tessék egy business interfész:

public interface ISample51 { //51: ötödik próbálkozásom első interfésze
String helloWorld();
}

-Az EJB projektben új osztály létrehozása Session Bean-nek. A felajánlott interfészeknél láthatóak az EJB kliensben létrehozott interfészek. (Ha elkezdjük írni.)
-Implementálni kell a metódusokat és fel kell annotációzni az osztályt pl. így: @Stateless @Remote public class SLSB1 implements ISample51 { ... } Azért remote, mert az appszerveren kívülről szólítjuk meg.
-Csinálni kell egy kliens osztályt. Már lehet hogy csinált egy Main-t a default package-be, ezt is használhatjuk. Egy ejb megkeresés és hívás így néz ki, ez kerül mondjuk a main belébe:

javax.naming.Context ctx = new javax.naming.InitialContext();
ISample51 hw = (ISample51)ctx.lookup(ISample51.class.getName());
System.out.println(hw.helloWorld());

Ha most futtatjuk a kliens osztályt jól elcsattan NameNotFoundException-nel, mert nem találja a bean-t. Miért is találná, nem deployoltuk. Ha nem lett volna elindítva az appszerver indítsuk el az Eclipse-en belül. Servers fül, play gomb. Deployoljuk: server view, context menü, add and remove project. Átnyomjuk az EAR projektünket a bal oldalról a jobbra, finish. A konzolon egy rövid Ant log jelenik meg. Nálam átlagos gépen 7 másodpercig tart a fenti bonyolultságú alkalmazás telepítése. Ha mindent jól csináltunk hibaüzenetek nélkül ÉS "Application Deployed at..." üzenettel. Vigyázat, ha valójában nem sikerült a deploy, akkor is képes kiírni a deployed üzenetet. Ha most futtatjuk a kliens osztályt, akkor már csinálja a dolgát.

Változtassunk bele az EJB-be minimálisan, buildeljünk újra. Ilyenkor az alkalmazás automatikusan újradeployolódik.

Ha az automatikus buildet beállítjuk, akkor kb. minden mentésnél megtörténik az újradeploy, ami nem valami szerencsés úgyhogy ezt az opciót érdemes kikapcsolni. Vannak még további lehetőségek is a build-deploy kapcsolatban, de ez most ezen a szinten nem érdekes.

Ha az interfészt megváltoztatjuk mondani kell egy olyat az EJB projeknek (a context menü J2EE részében) hogy update EAR libraries. Úgy emlékszem hogy bizonyos beállítások mellett erre nem volt szükség. Igen: Az EJB projektben a J2EE module dependencies-ben ki kell ikszelni a client-jar projektet.

* A Wizard által generált EARClient nem biztos hogy az aminek gondoltam, mert ha beleváltoztatok az maga után von egy újradeployolást. Márpedig ha a külső klienset változtatom miért kellene újra deployolni a szerver alkalmazást? Inkább csináltam egy új sima java projektet a külső kliensnek, amibe beimportáltam a J2EE library-t és felvettem függőségnek az EJBClient projektet. Így már jobban működik.

Dióhéjban ennyi. Közben még találtam egy hasonló -képekkel is illusztrált- leírást itt, JBoss-hoz. Ha pedig kinyitom a csapot, az jön belőle hogy hogyan kell Netbeans-szel Glassfish alá J2EE alkalmazásokat csinálni. Homokozásra jó ez az Eclipse-be integrált módszer, de semmiképpen nem ajánlanám komolyabb alkalmazások fejlesztéséhez. Többször is okozott meglepetéseket az IDE ha véletlenül összekavartam a dolgokat, pl. nem volt hajlandó buildelni. Tekintve hogy integrált buildelésről volt szó, nem tudtam mit csinálni csak találgatni vagy új workspace-t nyitni. Ant-os fejlesztésnél ilyenkor megjavítom a build scriptet és kész. Az Eclipse-ből kiemelve a projektek használhatatlanok, mert nincs bennük semmiféle build script. Próbáltam így importálni külső J2EE projekteket igazán kevés sikerrel. Ha már itt tartunk meg kell említeni a Maven plugint, amit viszont lehet használni komolyabb J2EE alkalmazásokhoz és a hierarchikus Maven projektek importálása is kiválóan működik.

A javalistán is éppen lett egy hasonló témájú thread az elmúlt napokban, konkrétan JBoss-ra kihegyezve.

EJB3 szakirodalom

Elkezdtem foglalkozni a címben említett témával és hogy értsem és ismerjem a lehetőségeket utánanéztem a fellelhető anyagoknak.

Tudomásom szerint nincs magyar nyelvű nyomtatott EJB3-mal foglalkozó könyv. A híres zöld-sárga J2EE útikalauz az EJB2-t tárgyalja, ami a hasonló alapelvek ellenére határozottan elavultnak számít az EJB3-hoz képest. Részletesebb netes írásokról sem tudok magyarul, legfeljebb mindenféle fórumokról és kiegészítésre váró wiki bejegyzés-ekről. Update 2008.06.23: Ahogy a kommentek között írtátok mégiscsak van magyar nyelvű könyv a témában. Imre Gábor: Szoftverfejlesztés Java EE platformon.

A szoftverfejlesztők szerencsére tudnak angolul.

Szinte minden angol nyelvű netes java médiumnak megvan a saját kis bevezető EJB3 cikke, így például: Javaworld, dev2dev (BEA), developer.com (Packaging EJB3 application), stb. Az alapkoncepciókat gyorsan bemutatják ezek az irományok, alapvető HelloWorld programokat meg lehet írni a segítségükkel, de az EJB3-nak nagyon nagy mélységei vannak. Ezeknek a mélységeknek a megismeréséhez elő kell venni vaskosabb anyagokat is.

A speckókat (JSR-220 egyébként a másik neve) a Sun-tól lehet leszedni. Aki online akarja a javadoc-ot böngészni az itt megtalálja, aki pedig a deployment descriptor xsd-jéért lelkesedik az ide kattintson. De nem a Javadoc-ban és az XSD-ben vannak az igazán nagy okosságok, hanem a JSR220 pdf dokumentumokban. Egyből három doksit kapunk: Az ejb3_0-fr-spec-simplified.pdf 59 oldalon futja át az EJB3 tulajdonságait. EJB2 tudás előnyt jelent az olvasáskor. Az ejb3_0-fr-spec-ejbcore.pdf egy bő lére eresztett 500+ oldalas szárazanyag, aminek persze az eleje 30 oldal rizsa. Meglepő módon szerintem hiányos is, legalábbis bizonyos információkat indirekte, másokat pedig egyáltalán nem tudtam megszerezni belőle. A perzisztencia a harmadikban, a ejb3_0-fr-spec-persistence.pdf-ben van taglalva.

A Mastering EJB3 4th Edition-t éppen most töltöttem le (ServerSide regisztráció szükséges hozzá, ingyenes 721 oldalas pdf, forráskód külön letölthető). Még csak éppen beleszagoltam. Egyes témák nincsenek túlzottan kifejtve benne, például az interceptorokról szégyenletesen kevés írást találtam, de egyébként nagyon impresszívnek és részletesnek látszik. Ez és a ejb3_0-fr-spec-ejbcore.pdf látszik a befutónak. Ezeket kéne olvasgatnia szvsz egy tisztességes EJB3 J2EE fejlesztőnek.

Sun Java Café

Update 2008.05.19 Ahogy írtam az eredeti post-ban, kiegészítettem még néhány link-kel, sőt néhány gondolattal is ami azóta jutott eszembe. Dőlt betűsek.

Leugrottam ma a címben nevezett rendezvényre. Leírom miket hallottam / láttam mielőtt elfelejtem, aztán később kiegészítem majd a post-ot linkekkel is. Alapvetően JavaOne-os és CommunityOne-os mesélésből és videónézésből állt a meeting. A videók a netről voltak, azonkívül blogok meg ilyen lab session-ök, amik leírják hogy egy adott technológáit hogyan kell összerakni, dolgozni vele nagyjából.

Szóval a Sun-os srácok kinn voltak, mesélték hogy rengeteg holland volt, Amszterdamban tele volt a helyi JUG-osokkal a reptér. Brazilok voltak még sokan, mert Brazíliában államilag rákattantak az open source szoftverekre. A hely monumentális. JavaCard technológiát használtak a beléptetéshez, az előadásokra már jó előre (1 hét) kellett jelentkezni, mert a jobbakra beteltek a helyek. Jelentkezés nélkül is be lehetett jutni ha maradt még hely, de ott komoly sorbanállások voltak. Éjszakába nyúltak az előadások.

Bemelegítésnek egy videón bemutatták a ZFS (fájlrendszer) hibatűrő képességeit egy kalapács és egy kézifúró segítségével.

Volt néhány SOA-s, workflow engine-es téma de azok engem nem annyira fognak meg, vagy legalábbis addig a szintig érdekelne, hogy én rakjak össze egy ilyen rendszert az alapjaiból. Amikor már dobozokat kell összehúzogatni, XML-eket, bean-eket összepároztatni, de leginkább formokat kitöltögetni ott már kezdem fölöslegesnek érezni a programozástechnikai tudásomat. Ez egy másik szint, nem tudom.

Volt még látványos és meggyőző JavaFX hájpolás. 3D-ben transzformált filmeket mutattak sokat egyszerre, mondjuk százat, immár kihasználva a videókártya képességeit. JavaFX-es alkalmazás böngészőben, ami kicsit lefagyott néha, mert nem tesztelték a valósan leterhelt környezetben. A JavaFX alkalmazást ki lehetett emelni a böngészőből. Volt JavaFX Androidon -hohó! Kitalálták hogy csinálnak JavaFX támogatást MIDP-re és így nem mittudomén 3 milló JavaFX-es mobilt csinálnak, hanem 1 milliárdot. Én csak azért vagyok szkeptikus, mert rengetegszer találkoztam már a 64k-s problémával, mármint hogy sok telefonban 64kbyte áll rendelkezésre a midletek futtatásához ami néha igencsak kevés. Namost ha eleve betuszkolunk egy JavaFX motort az alkalmazás mellé az eleve elfoglal elég sok helyet. Kíváncsi vagyok a megoldásra. Egyébként meg a Java SE is fog tartalmazni JavaXF supportot. Update 2007.05.21: Említettek még olyan magic-et, hogy Adobe Photoshop-pal rajzolt képekből lehet JavaFX kódot konvertálni egy bizonyos eszköz segítségével. Erre itt is utalnak.

Neal Gafter closure proposal-ját néztük meg. Engem meggyőzött róla hogy hasznos dolog, bár a példa (mérjük meg a metódusok mennyi idő alatt futnak le) inkább valami AOP-os megoldásért kiáltott érzésem szerint. De itt most nem az volt a cél. Exception | Exception szintaktika, Map iteráció, egyebek.

Megemlítették, hogy az új portlet specifikáció már kicsit bonyolult lesz. Hát ja.

Valami D-vel kezdődő technológia, (DTrace, köszi!) ami Java programok követését teszi lehetővé. Az elmondás szerint egyik gépen ott Space Invaders-ezett a tag, a másik gépen pedig trace-elték a programot. Eddig ez nem nagy kunszt, sima Remote Debug is lehetne, de külön Java API lesz a trace-eléshez amivel nem tudom mit lehet majd megcsinálni, de biztos izgalmas dolgokat.

Szó volt a desktop alkalmazás vs. webalkalmazás témáról egy hamvába halt vitaindítóval. "Szégyenlős voltam", ezért nem jelentkeztem, de van egy véleményem a dologról: Mostanában a böngészők egyre jobban kezdenek hasonlítani egy menedzselt alkalmazás futtató környezethez. Gondoskodnak az alkalmazások frissítéséről, a sandbox modelről, security-ről, plugines a szerkezetük. Ha értelmes desktop alkalmazást akar írni valaki, igazából majdnem ugyanazokat a funkciókat meg kell csinálni mint amit egy browser nyújt. Csak az a fránya javascript ne lenne. De nem is kell, mert a browser szerepe ma már, hogy futtatókörnyezetet nyújtson a különféle plugineknek, pl. Flash, Java. Sőt, ha valahogy kiütöm a toolbar-okat a böngészőn, vizuálisan nem is lehet megkülönböztetni egy desktop alkalmazástól.

Megjelent a JavaCard technológia 3-as verziója -illetve meg fog jelenni- ami valami embedded webszerveres téma már. Volt egy verseny, hogy tankokat kellett vezérelni ilyen JavaCard-ra írt programokkal. Kétféle megközelítés van: a classic a v2-es spec hagyományait viszi tovább, azaz embedded applet-ek, aminek semmi köze nincs a browser-es appletekhez biteket vadásznak byte tömb alapú I/O segítségével. Erről lehet hogy majd írok még majd egyszer. A másik megközelítés a connected, amiben egy szervlet motor dolgozik és nagyjából szervleteket kell írni az igencsak megnyirbált Java SE osztályrendszert használva. Nincs floating point support meg ilyesmik.

Ami nagyon tetszett, az a toll, ami speciális pöttykóddal ellátott papírt használva rögzíti amit írok, felveszi a hangomat, vissza tudja játszani és ilyesmik. Volt olyan program (demószinten) ami leírt szöveget visszamondott mindenféle nyelven. Hoztak is a srácok egy ilyen tollat meg füzetet hozzá.

Java-t futtató kis lapka ami rádióval kommunikál. A videón labdákat dobáltak a teremben, a kivetítőn pedig mutatták hogy hol vannak éppen a labdák. Gondolom háromszögeléssel és időméréssel oldották meg a feladatot, de ilyeneket használtak széndioxid szint mérésre, JavaCard leolvasásra és mindenfélére.

Néztünk pár JavaOne újságot és voltak könyvek mutatóban. Biztos kihagytam valamit, de majd megírják. Addig is itt egy tűzközeli blog. És akkor jövök még majd linkekkel. -Akkor ez letudva.

Június 16.-án lesz a Sun-os fejlesztői konferencia külföldi előadókkal, gondolom sok SOA-val.