Payara, aneb zmrtvýchvstání aplikačního serveru Glassfish

SunOne7

Glassfish má za sebou dlouhatánskou cestu ... první, s čím jsem přišel do styku, byl SunOne7. Ten vznikl jako výsledek spolupráce s Netscape a Oracle stále ještě udržuje jakousi stařičkou dokumentaci.

Jeho výhodou byla jedna z prvních podpor EJB (což se ukázalo i nevýhodou, jelikož tato technologie, tj. EJB2 byla prakticky nepoužitelná) a administrační GUI, které naopak použitelné bylo. Z něj se daly konfigurovat a spouštět i vypínat instance aplikačního serveru, čili na tu dobu šlo o vskutku "enterprise" řešení, které v té době nemělo obdoby.
Výhod bylo víc, například integrace JMS a dalších J2EE technologií, aktuálních v roce 2003.
Největší výhodou byla ovšem výborná stabilita. Tenhle aplikáč nám snad nikdy nespadnul, pokud nebudu počítat memory leaky v našich vlastních aplikacích.

Mezi nevýhody patřilo využívání nativních knihoven a tudíž možnost spuštění pouze na OS Solaris, Windows a RedHat 7.2. Rozchodit monstrum jinde vyžadovalo náhodné vyměňování nativních knihoven, než se administrátor "trefil" do konstelace, která fungovala.
A jedna nevýhoda fatální - zapomeňte na zdrojáky nebo artefakty ve veřejných úložištích.
No, pryč od toho ... užili jsme si dost srandy :-)

Sun Java Application Server 8

V roce 2005 přišly specifikace JEE5, JDK5, EJB3, JPA a další, díky kterým se stal starý aplikáč v podstatě mrtvou technologií. Sun se do toho vrhnul po hlavě, část implementací integroval od jiných autorů, část napsal sám - práce odvedl mnoho a velmi rychle, byť s diskutabilní kvalitou.

Tou dobou se už začínala probouzet konkurence - z největších aktuálních jmenujme WebSphere, WebLogic, TomEE, WildFly/JBoss, Jetty, a další. Mírně zastarávající seznamy s malým srovnáním viz wiki nebo wiki.

Přiznávám, že s touto verzí jsem neměl moc zkušeností, jen si pamatuji, že to byl takový mezičlánek, ve kterém byla spousta nedodělků a chyb. V principu to fungovalo, ale ...

Sun Java Application Server 9 aneb Sun Glassfish Enterprise Server 2

SJAS8 byl v podstatě prototyp. SJAS9, později přejmenován na SGES2, znamenal dotažení technologií do konce. Velké problémy byly s JMS (OpenMQ), což byl server provozovaný v serveru, při chybné konfiguraci se prostě zasekl. Důvody jste museli hledat mimo Glassfish, přičemž trvalo dlouho, než jste přišli na to, v čem je přesně problém.
Komunikace mezi GF a MQ probíhala přes porty, a variant konfigurací bylo mnoho, snad ani autorům původně nedošlo, jakou variabilitu jim to dává. To je ale námět spíše na jiný blog - stručně - triviální varianta je "embedded", resp. "zapouzdřený" server, složitá a škálovatelná varianta je "remote" server ...

SJAS9 přišel v roce 2007, zkraje se ještě stávalo, že "zůstal viset" právě díky JMS, později ale byly i tyto chyby vyřešeny a poslední verze SGES2.1.1 byla velmi stabilní a bezproblémová (pokud jí nedestabilizovaly vaše chyby ve vašich aplikacích ;-) ).

Hlavní výhody proti dřívějším verzím:

• podpora clusteringu - bylo možné provozovat n instancí na m strojích, mezi nimiž se replikovaly sessions uživatelů a bylo možné např. postupné nasazení nové verze, aniž by došlo k výpadku (to samozřejmě mělo svá pravidla, o tom zase jindy).
• žádné nativní knihovny - kde běží JDK5/6, běží Glassfish (jen občas narazíte na problémy např. s Windows).
• propracovaná dokumentace
• kompletní podpora JEE5

Glassfish3

V roce 2010 Oracle koupil Sun a všechno se změnilo. Již předtím jaksi "v ilegalitě" vznikl tzv. Embedded Glassfish, na který jsem narazil prakticky náhodou - kupodivu ve veřejných úložištích, a začal ho používat k integračním testům. Ano, stačil mi JUnit, abych mohl testovat EJB3 s JMS, JPA a se vším všudy!
Embedded Glassfish je totiž přebalené vydání Glassfishe3 do jediného jar souboru. Chybí mu pár XML, která se dají snadno dotáhnout z jiných závislostí a jedete - tak málo stačilo k odstranění největší výtky vůči "enterprise aplikačním serverům"!

Glassfish3 náš tým nakonec přeskočil, ale pomohl nám díky zpětné kompatibilitě se SGES2 právě s testováním.
Embedded Glassfish byl nakonec opět pohlcen Glassfishem a stal se součástí jeho buildu a repository.

V roce 2011 Oracle oficiálně vydal Glassfish3 jako referenční implementaci JEE6. Vzápětí se ale probral JBoss a prakticky Glassfish3 převálcoval.

Byrokracie Oracle navíc silně rozladila některé vývojáře a byla poslední kapkou k jejich přestupu - kam jinam - často k JBoss.
Po vyjádření Oracle o ukončení komerční podpory Glassfishe a o vyčlenění "clusteringu" pouze do komerční verze to vypadalo, že Glassfish prostě skončí, zemře, je konec. Jenže se ukázalo, že tak snadné to mít Oracle nebude ...

Glassfish4 - smrt ... NEBUDE!

Oracle totiž narazil na pár háčků. Nápad s clusteringem vyprovokoval poměrně hlučnou odezvu vývojářů i mimo Oracle, takže od něj bylo ustoupeno. Nápad s ukončením komerční podpory sice Oracle dotáhl do konce, ale nikoho to zase tak moc netrápilo, protože i má osobní zkušenost s komeční podporou Sun/Oracle byla velmi špatná (a je doposud).
Licence Glassfishe ale umožňovala alespoň pasivní přístup ke zdrojákům, a bylo otázkou času, kdy dojde k tomu, kdy je někdo vyžene na GitHub (ano, byl jsem to já, ale ukázalo se, že nejsem první, viz níže :D).

Druhý háček spočíval v tom, že komunita JEE stále potřebuje referenční implementaci a nikdo si jí nemohl jen tak přivlastnit a zamezit přístupu k ní ostatním.

No a poslední háček - všechny implementace JEE7 používají komponenty svých konkurentů. Weld vyvíjí JBoss. EclipseLink vyvíjí Eclipse+Oracle. Catalinu vyvíjí Apache. Pokud by Oracle "zařízl" Glassfish, patrně by nevydal už víc jak jednu jedinou verzi WebLogic, vývoj by se zbrzdil.

A tak v roce 2013 Oracle vydal Glassfish4 jako referenční implementaci JEE7. Změn nebylo mnoho oproti GF3, spoustu práce odvedli externí programátoři, Oracle se zjevně snažil investovat minimum. Čím více chyb v GF, tím lépe pro WebLogic.

Přišel rok 2014 a náš zákazník nakonec souhlasil s "upgrade". Udělali jsme skok z JEE5+JDK6+GF2.1.1 rovnou na GF4+JDK8. Ukázalo se, že to není až tak snadné díky chybám, které ve zdrojácích zevlovaly už od Glassfishe3, čili často 5 i více let.

Payara

Začal jsem zkoumat licence a možnosti, jak se dostat do SVN. Po dnech a nocích, kdy se exporty po různu zasekávaly a padaly díky vadné integritě dat v SVN Oracle, se mi to nakonec podařilo. Nakonec jsem posílal patche přímo do JIRA ... a odezva ... na přijetí jsem čekal nějaké 3 měsíce.

To mě moc nebavilo a proběhla komunikace s šéfem Glassfishe Rezou Rahmannem - pravda, překvapilo mě už, že se se mnou baví, ale ještě víc mě překvapilo, že mě nasměroval na Steva Millige z C2B2 a Payaru.
Po další komunikaci byla moje oprava přijata během 3 dnů do Payary.

Po zastavení komerční podpory Glassfishe se totiž Steve rozhodl, že jí tudíž začne poskytovat sám. Udělal stejný krok jako já, převedl SVN na GitHub, domluvil se s Rezou, a postupně se k němu přidali další a další lidé z komunity, včetně mě.

Tým Payara a jeho přispěvatelé od té doby opravili spoustu chyb a jen tak mezi řečí pomalu posouvají Payaru dál ke specifikaci JEE8. Objevily se požadavky pro podporu Javy IBM, podporována je i Oracle JDK8 (původně 7), opravy se promítají zpětně do Glassfishe od Oracle a samozřejmě - existuje placená podpora, které bych vytkl jen to, že její ceny jsou typicky "enterprise", leč konkurenti nejsou levnější.

Krom toho žije dál i Embedded Payara a vznikly i další distribuce, většinou osekané o nepotřebnou funkcionalitu.

Nakonec vzniklo i toto zábavné reklamní video:

Placená podpora

Na druhou stranu, za Tomcat podporu taky neplatíte, že? Ale to, co umí Payara rozhodně neumí ;-)

Ve výsledku placená podpora slouží hlavně k čestné podpoře profesionálních týmů, které se o tyto projekty starají. Proto pokud pracujete na projektech pro velké firmy či stát, měli byste podporu platit.
Ve skutečnosti sice nezískáte větší podporu, než máte, leč přispíváte tím k tomu, aby aplikační server, který používáte, mohl být dál vyvíjen a udržován, tj. abyste po dvou letech nezjistili, že projekt prostě skončil a vy jedete na mrtvém koni. Což není tak málo, když si to tak vezmete, ne?

V tuto chvíli to vypadá tak, že C2B2 míří mezi velké firmy. Její vývojáři konzultují chyby ve Weld i EclipseLinku, komunita si vypomáhá, zatímco Oracle si stále něco plácá na svém písečku a o ostatní se moc nestará, ale možná je to jen můj pocit ...

Budoucnost

Kdyby někdo měl pocit, že na to má, tým Payary shání vývojáře. Já tam zatím nejdu, mám svůj boj jinde, který navíc slouží jako výborný obří reálný testovací příklad pro Payaru. A zatím můžu říct, že se všichni lepšíme.

Momentálně Websphere, WebLogic ani WildFly neumí všechno, co umí Payara. Možná umí něco navíc, možná něco umí lépe, ale ne dost na to, aby mělo cenu přecházet. Zvlášť když je Payara možná ještě převálcuje :-)

Řekl bych, že i Oracle na to nakonec nutně přijde a bude muset se k tomu postavit čelem. Těžko může komplikovat práci ostatním skrz licence, spíše bych hádal, že se C2B2 pokusí koupit a zklikvidovat, pokud tato konkurence začne být až moc silná.
Dokud ale bude Glassfish na GitHub, bude velmi těžké jeho "lepší klony" kontrolovat, uzmout zpět, takže tahle cesta Oracle asi nepomůže, ne na dlouho. Glassfish není jediný takový projekt, open source se dá sice všelijak poškodit, ale jen stěží kontrolovat, pokud má pod nohama tak silnou infrastrukturu, která má navíc pozitivní efekt i pro komerční obříky.

Časy se mění ... jedno riziko bych tu ale viděl - a tím je paradoxně TTIP (v odkazu TPP, což je podobná dohoda) a různé formy kontroly internetu. Představte si, že vám vláda zablokuje, omezí nebo zpoplatní přístup na GitHub ... že je to paranoidní nápad? Možná - ale třeba tlak například na omezování síly šifer už tu dávno je.
Mimochodem, na některé weby a videa se nedostanete už teď. BBC blokuje přístup na (některá?) videa mimo UK, Youtube "tají" videa před Němci, atd. - co nevidíme, o tom nevím, tohle jsou jen zkušenosti, na které jsme narazili náhodou s kamarády v zahraničí.
To je ale už úplně jiné téma ...