A JBoss kibocsátotta a nyílt forráskódú BPEL projektjének, a Riftsaw-nak a 2.0-ás verzióját. Ennek kapcsán beszélgetett a DZone a Riftsaw két fejlesztőjével, Gary Brownnal és Kurt Stammel. A Riftsaw projekt célja egy WS-BPEL motor előállítása volt. A motor alapként szolgál SOA környzetek BPEL orkesztrációval történő fejlesztéséhez. A motor JBoss alkalmazásszerver-konténerben történő futtatáshoz lett optimalizálva, az Apache Ode-ra épül, illetve azt ki is bővíti. A Riftsaw 2.0 a projekt által kibocsátott első stabil verzió.

 

A Riftsaw hogyan illeszkedik bele a JBoss projektek, Apache projektek illetve más projektek által használt technológiák ekorendszerébe?

A JBoss eddig az alkalmazásszerveréről, a Hibernate-ról, illetve újabban a SOA Platformjának alapját képező ESB-jéről volt ismert. Az Enterprise Service Bus (vállalati szolgáltatássín; ESB) fő célja, hogy elősegítse az alkalmazáskomponensek, illetve a szolgáltatások közötti összekapcsolhatóságot, ami azért fontos, mert a komponensek gyakran eltérő üzenetformátumokat vagy technológiákat használnak. Az ESB a szállítási protokollok közötti mediációt, üzenettranszformációt, útvonalválasztást és orkesztrációt kínál a különféle szolgáltatási technológiák közötti interoperabilitás megteremtése érdekében.

jboss.org Application Server = Enterprise Application Platform

jboss.org ESB = Enterprise SOA Platform

Bár az ESB-nek nincsen általánosan elfogadott definíciója, az szintén elterjedt nézet, hogy egy ESB-nek szabványokon alapuló orkesztrációs képességet kell nyújtania a WS-BPEL folyamatnyelv alapján. Bár a jBPM projekt kínál folyamatorkesztrációs képességet, amelyet sikerrel be is vetettek ilyen céllal az ESB számos telepítésében, a jBPM mégis inkább a JPDL és POJO orkesztrációval foglalkozott elsősorban, és nem annyira a WS-BPEL-lel, és a webszolgáltatásokkal vagy az XML-lel.

Ezért úgy határoztunk, hogy a JBoss ESB-nek WS-BPEL-alapú orkesztrációs megoldásra van szüksége. Ez vezetett ahhoz a döntéshez, hogy a széleskörben használt Apache ODE BPEL motort a SOA Platformba integráljuk. Így született meg a RiftSaw. A félreértések elkerülése végett meg kell jegyeznünk, hogy a RiftSaw az Apache ODE JBoss platformokba való integrálásra szolgáló projekt, nem pedig egy újabb nyílt forráskódú BPEL motor.

Ami az Apache technológiák szélesebb ekorendszerét illeti, a JBoss az Apache CXF, a jUDDI és a Tomcat projektekben is aktívan közreműködik. 



 

Mitől új és egyedi a Riftsaw?

Az Apache ODE egy WS-BPEL motor remek minőségű nyílt forráskódú kivitelezése. Ugyanakkor, JBoss Enterprise Application Platformon és SOA Platformon alapuló üzemeltetési környezetben történő futtatás esetén, bizonyos területeken hiányosságai ütköznek ki. Ezen hiányosságok orvoslására hivatott a RiftSaw projekt.

Az első ilyen hiányosság akkor merül fel, ha egy JBoss platformon belül kívánjuk telepíteni az Apache ODE-t. A RiftSaw előtti időkben ehhez meg kellett változtatni a JBoss és az Apache ODE környezeteket, mert csak így tudott a két alkalmazás gördülékenyen együtt működni. 


Egy további terület a JBoss ESB projekttel való szoros integráció, amely lehetővé tette BPEL folyamatok (futásközbeni) gyorstelepítését egy ESB konfiguráció részeként.

Az Apache ODE jelenleg két szállítási protokoll opciót kínál, az egyik a webszolgáltatásokhoz kapcsolódó Axis2, a másik a JBI. A RiftSaw projekt az Axis2 integrációt JAX-WS támogatással helyettesítette. Ennek eredményeként egy JAX-WS-nek megfelelő szállítási réteg jött létre, úgy, hogy lehetőség van az Apache CXF-et üzenetküldési rétegként használni. Azon leszünk, hogy kiderítsük, hogyan lehetne a lehető legjobban visszavezetni ezt a további szállítási réteget az Apache ODE projektbe.

A többi érintett terület a RiftSaw projekt jövőbeni csapásirányaihoz kapcsolódik. Az ODE-hoz tartozó alapkonzolt egy GWT-alapú konzolra cseréltük le. A jelenlegi kiadásban ez ugyan nem kínál további funkcionalitást, viszont olyan erős alapot nyújt, amelyre a jövőben BAM (Business Activity Monitoring) képességeket építhetünk.

Egy további terület még a klaszterelés és a failover támogatás. Bár jelenleg még nem támogatjuk ezeket, a jövőben ezekre a területekre is kíván összpontosítani a RiftSaw.

Máris hozzájárultunk a Maven build támogatásához, amely az esetleges hozzájárulók szélesebb köre számára nyitja meg az Apache ODE közösségben való részvételt. 



 

Milyen módokon lehet a Riftsaw-t telepíteni?

Amikor a RiftSaw projektet útjára indítottuk, az elsődleges célunk az volt, hogy szabványalapú orkesztrációs támogatást nyújtsunk a JBoss ESB részeként, hogy alkalmazzuk a motort és az új folyamatmeghatározásokat egy JBoss tárolón belül – és hogy ezáltal optimalizáljuk az Apache ODE-t a JBoss végfelhasználói számára.

Így, bár szoros integráció áll fenn az ESB-vel, ahhoz, hogy az ESB szolgáltatások közvetlenül együttműködjenek a BPEL folyamatokkal a SOAP felesleges használata nélkül, a RiftSaw a JBoss konténeren belül önállóan is futtatható.

 

Mely technológiákhoz hasonlítható a Riftsaw?

Talán szerencsésebb lenne úgy feltenni ezt a kérdést, hogy mely más technológiák hasonlítanak az Apache ODE-hez.

Nyílt forráskódú WS-BPEL 2.0 támogatásnak ott van az Apache ODE, az OW2 Orchestra és egy, a Sun által szponzorált projekt, amely az OpenESB-t és a Glassfish-t támogatja. Ezen kívül még számtalan kereskedelmi gyártó is van, akik a termékeik részeként WS-BPEL képességeket is kínálnak.

 

Jelenleg milyen szakaszban fut a projekt? Milyen célok elérését tűztétek ki a projekt számára? Sokan használták már a RiftSaw-t?

A projekt keretében kiadtuk az első stabil verziót. Ez a verzió jó alapot kínál egy olyan SOA fejlesztéséhez, amely a BPEL orkesztráció számára beépített támogatást kínáló JBoss technológiákat használ.

Miután ezt a verziót kibocsátottuk, elsődlegesen arra fogunk összpontosítani, hogy további telepítési képességeket kínáljunk, illetve, hogy javítsuk a konzolról elérhető funkcionalitást.
Arra a kérdésre, hogy hányan használták már a RiftSaw-t nehéz válaszolni, egy nyílt forráskódú projekt esetében ugyanis sosem könnyű megbecsülni, hogy vajon hányan használják. De visszatérve a projekt céljára, mivel a JBoss környezetbe integráljuk az ODE-t, ezért bárkit, aki az ODE-t egy másik alkalmazásszerverről használja, csupán egy rövid migrációs út választja el attól, hogy BPEL folyamatát a JBoss platformján használhassa.

 

A BPMS mozgalmat az utóbbi években a JBoss és az Intalio vezette. Hogyan illeszkedik be a Riftsaw ebbe a mozgalomba?

Bár a JBoss is jelen volt a BPMS küzdőterén a jBPM projekt révén, mi mégis az Intalio jelentős hozzájárulását emelnénk ki, amelyet a szabványalapú nyílt forráskódú BPMS területén fejtett ki az Apache ODE projekthez kapcsolódóan, illetve más hasonló projektekkel kapcsolatban (lásd pl. az Eclipse BPMN modellező), valamint a BMN2 továbbfejlesztése kapcsán.

Mi, a RiftSaw csapat tagjai nagyon szeretnénk aktívan hozzájárulni ezeknek a projekteknek a sikeréhez, és több olyan csapatunk is van, amelyek olyan különböző területeken dolgoznak, amelyek remélhetőleg a jövőben majd az ODE projekt részeivé válnak. Egyébként a közelmúltban az egyik csapattagunk, Jeff Yu az ODE projekt hozzájárulója lett, ezúton is gratulálunk neki!
Jeff első hozzájárulása committerként többek között a következőeket nyújtotta: egy maven build struktúra felállítása a jelenlegi építési struktúra alternatívájaként, illetve az perzisztencia réteg teljes JPA megfelelőséghez való átalakításán is dolgozott, így lehetővé téve a JPA szolgáltatók közötti választást (legyen ez akár OpenJPA, Hibernate vagy egy másik kivitelezés).

 

A Riftsaw 2.0 jelenleg a következő jellemzőket támogatja:

• WS-BPEL 2.0 OASIS szabvány és a hagyományos BPEL4WS 1.1 specifikáció.
• JBossWS Native és CXF Web Service stack támogatás.
• BPEL végpontok UDDI regisztrációja és UDDI végpont visszakeresés technológiaelőzetesként
• Vállalati szintű GWT-alapú BPM konzol a folyamatmeghatározások és folyamatpéldányok kezeléséhez.
• Magas szintű, motorhoz tartozó API, amely lehetővé teszi, hogy a folyamatkezelő magot gyakorlatilag bármilyen kommunikációs réteggel integráljuk.
• JBoss alkalmazási architektúra, lehetővé téve a gyorstelepítést (hot deployment).
• Olyan kompilált a BPEL megközelítés, amely részletes elemzést és validációt nyújt a parancssorból vagy az alkalmazási ponton.
• Rövid élettartamú illetve hosszú lefutású folyamatvégrehajtások.
• Folyamatáperzisztencia és visszaállíthatóság.
• Folyamat verziókezelés.
• Ant-alapú telepítés.
• JBoss ESB-vel való integráció.
• Eclipse-alapú BPEL tervező és telepítés, JBoss Tools-on keresztül történő támogatással.
• JBoss Cluster-ben is futtatható.
• Remek példatár, köztük a BPEL Blueprint példáival, amely a kezdeti nehézségek gyors átidalásához nyújt segítséget.