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