jTechnics

JBI 1.0

Thursday, January 1st, 2009 | Uncategorized

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

No comments yet.

Leave a comment