Mióta megjelentek a JBoss Enterprise Platform termékek, sokan felteszik a kérdést, hogy miért is fizessenek elő, és alkalmazzák a vállalati platformokat, mint például az Enterprise Application Platformot vagy az Enterprise SOA Platformot, ahelyett, hogy egyszerűen csak letöltik ezeket a jboss.org projektjeiként, és ingyen használják őket?
Ez a kérdés jogos, melynek előtörténete is van: az eredeti termékmodell szerint minden, a jboss.org-on megjelent termék támogatott volt, melyekhez termék-előfizetést lehetett vásárolni. Azzal, hogy a JBoss kétféle kiadást hozott létre, ami alapján vannak közösségi JBoss kiadások, melyek nem a fizető ügyfeleknek szólnak, némelyek fejében nagy lett a zűrzavar. Miért is alakult ez így?
Az egyik legnagyobb probléma, mellyel az ügyfelek szembenéztek, a stabilitás volt. A régi termékmodellben még az al-, sőt al-al verzióváltások esetén is voltak nagyobb változtatások, vagy jellemzőbeli bővítések, ami az ügyfelek alkalmazásainak stabilitását veszélyeztette. Ez jelentette az elsőszámú problémát a JBoss ügyfelei számára, és ezt meg kellett oldani. Emellett más problémák is vannak, melyek az új termékmodell irányába vezették a JBoss-t, de a stabilitás volt a fő ok. Sok ügyfél olyan terméket akar, melyet alkalmazni tud, és tudja róla, hogy a kompatibilitás sok éven át garantált. A régi modell ezt nem nyújtotta. Ezt alapul véve mi is a különbség az Enterprise Platform és a jboss.org közösségi kiadása között?
Vegyük például a JBoss Application szervert és az Enterprise Application Platformot. A JBoss AS projekt esetén a nyílt forráskódú projekt részét képző két tesztelési procedúra után jelentetik meg az új verziót (egységtesztek és kompatibilitási mátrix tesztek). Miután elkészült az összes, az adott kiadásba szánt jellemző hibajavítása és implementációja, melyek 100%-ban átmentek a fenti két teszten, a JBoss megjelenteti a kódot a közösség számára. A tesztelési fázisok lényegesek, mivel közel 4000 tesztet foglalnak magukban. A teszteket egyetlen JVM-en, a Sun 1.5 JVM-én, illetve egyetlen operációs platformon (ami történetesen Red Hat Enterprise Linux, és ez már évek óta így van, még a Red Hat JBoss felvásárlást megelőzően is) futtatják. Most pedig nézzük meg, hogy mi történik az Enterprise Application Platform esetén!
Ebben az esetben szintén a fent említett tesztelési procedúrákon esik át a termék, de már JVM-ek és operációs rendszerek kombinációján. Például EAP 4.3 esetén a teszt procedúrákat a következő JVM és operációs rendszer kombinációkon futtatták:
1. BEA JRockit 1.5 JVM RHEL 4 x86-on
2. BEA JRockit 1.5 JVM RHEL 4 x86_64-on
3. BEA JRockit 1.5 JVM RHEL 5 x86-on
4. BEA JRockit 1.5 JVM RHEL 5 x86_64-on
5. BEA JRockit 1.5 JVM Windows 2003 x86-on
6. BEA JRockit 1.5 JVM Windows 2003 x86_64-en
7. HP 1.5 JVM HP-UX 11i IA64-en
8. HP 1.5 JVM HP-UX 11i PA-RISC-en
9. Sun 1.5 JVM RHEL 5 x86-on
10. Sun 1.5 JVM RHEL 4 x86_64-en
11. Sun 1.5 JVM Solaris 9-en
12. Sun 1.5 JVM Solaris 10-en
13. Sun 1.5 JVM Windows 2003 x86-on
14. Sun 1.5 JVM Windows 2003 x86_64-en
15. Sun 1.5 JVM RHEL 4 x86-on
16. Sun 1.5 JVM RHEL 4 x86_64-en
Ez a platformok első szintje, és az enterprise platformok kiadása után folytatódtak a tesztelések, további kombinációkkal, mint például az IBM 1.5 JVM (az EAP 4.3 2008. januárban jelent meg). Ez a tesztelés a tesztelő környezettel, illetve a kóddal kapcsolatos problémákat is felfedi, ez a kód azonban már nem kerül az ügyfelekhez. Ezen tesztelés mellett néhány egyedi komponens teszt procedúra is bekerül, mint például a következők:
- EJB 3
- JBoss Web Services
- JBoss Remoting
- Hibernate
Ez egy nagy minőségi előrelépést jelent, de ez még nem minden. További teszt procedúrák is létrejöttek a teljesítmény és a méretezhetőség tesztelésére, az alábbiakhoz:
- EJB 3
- JBoss Seam
Ez az Enterprise Application Platform két legfontosabb része teljesítményi szempontból az ügyfelek számára. Ezért a JBoss fejlesztői biztosítani akarják, hogy nincsenek eredendő teljesítményi és méretezhetőségi problémák a platform ezen jellemzőivel kapcsolatban. Ezeket a teszteket a megbízhatóság tesztelésére is használják tartós terhelési tesztek formájában.
A tartós terhelési teszt 24-36 órán át folyik. Ez lehetővé teszi a tesztelők számára, hogy megbizonyosodjanak arról, hogy már nem lépnek fel olyan problémák, melyek az ügyfelek alkalmazásainak rendelkezésreállását befolyásolja. De ez még nem minden. A Hibernate esetén az alábbi adatbázisok kerülnek a tesztpadra:
1. Microsoft SQL Server 2005
2. MySQL 5.0
3. PostgreSQL 8.2
4. Oracle 9i
5. Oracle 10g
Ezek mellett a J2EE 1.4 TCK adatbázis részét is használatos tesztelésre, annak érdekében, hogy a JBoss EJB 2.x implementációja megfelelően működjön ezeken az adatbázisokon is. Ez ugyanúgy az adatbázisok első szintje, mint a JVM vagy az operációs rendszer kombinációk. Az első enterprise kiadás megjelenése óta DB2-n és Sybase-en is folynak tesztek. De még ez sem minden. Emellett olyan klaszterezési technológiák környezete is tesztelésre kerül, mint például a következők:
- HTTP Session Replication
- JMS Clustering
- JMS Fail-over
Az EAP 4.3 megjelenésével a JBoss Messaginget most már klaszterezési és failover képességek is jellemzik, melyek nem voltak a régi JBoss MQ-ban, ezért nagyobb hangsúlyt fektetnek a tesztelésre, különösen az új képességek tesztelésére. Végül, van a teszteknek egy olyan készlete is, ami a telepítésre és a kezelésre vonatkozik. Ide tartoznak például a következők:
- GUI telepítő
- JBoss Operations Network (JON)
- RPM tesztelés
A fentiek alapján látható, hogy az új Enterprise Application Platform esetén a régi termékmodellben nem tapasztalt, kiterjedt tesztelés valósul meg, ami csak a platform termékekre vonatkozik. Mi történik majd az ebből a tesztelésből származó hibajavításokkal? A hibajavítások közvetlenül a vállalati platform megfelelő ágába kerülnek be, illetve a közösségi ágba is. Természetesen azon hibajavításokhoz, melyek a közösséghez kerülnek, nem kapcsolódnak SLA-k, valamint a kód elágazások lényegesen különböznek egymástól. Emellett a közösségi jboss.org kiadások szintén rendelkezhetnek olyan új jellemzőkkel, melyek nem részei a vállalati platformoknak. A vállalati platformok megjelentetése után negyedéves kumulatív frissítések is megjelennek, és idővel, mivel nem kerül hozzájuk új jellemző, a kód továbbra is különbözik majd a közösségi jboss.org kiadástól. Ez pedig az ügyfelek által igényelt stabilitást eredményezi, és ezeket a platformokat olyan minőségi szint jellemzi, ami nem volt jelen a régi modellben.
Ha stabil platformra van szükségünk az alkalmazásaink fejlesztéséhez, mely idővel nem válik inkompatibilissé az alkalmazásainkkal (három év teljes támogatás, két év biztonsági hibajegyzék támogatás), akkor mindenféleképpen nekünk szól a JBoss Enterprise platformok ajánlata.