Příběh frameworku Ujorm

Kolik času může ušetřit framework Ujorm a proč vlastně vznikl? Nejen na tyto otázky se pokusí odpovědět následující článek.

Někdy v roce 2008 jsem měl příležitost zúčastnit se vývoje zajímavého rezervačního systému v jazyce Java pro klienta působícího v dopravě. Prezentační část se stavěla na technologii RichFaces, což byl komponentový framework postavený nad JavaServer Faces (JSF) firmy Sun Microsystems, obchodní logika byla umístěna do servisních tříd podporovaných frameworkem Spring, perzistentní vrstva se budovala na ORM frameworku Hibernate.

Implementaci předcházela analýza zkušeného analytika, většinu vývojového týmu tvořili vývojáři s mnohaletými zkušenostmi s vývojem webových aplikací v Javě. Nutno dodat, že výše uvedené technologie byly pro tým relativně nové, nicméně tento rizikový faktor byl v odhadu pracnosti zohledněn.  První ohlasy byly příznivě také díky pěknému vzhledu JSF komponent s integrovanou podporou technologie AJAX. Postupem času však se však vývoj začal zpomalovat. Pracnost údržby JSF komponent (postavených na XML souborech) se zvyšovala, chyběla možnost bezpečného refaktoringu komponent, jejich znovupoužití na prezentační vrstvě bylo pracné. Překlepy vznikaly také v referencích na metody servisní vrstvy, kterou Java kompilátor nemohl z principu odhalit. V závěrečné fázi projektu pracoval na úkolu téměř dvojnásobný počet z původně vyčleněných vývojářů, přesto se projekt nepodařilo dokončit v původně plánovaném termínu a kvalitě. Tím však problémy bohužel neskončily.

Provoz na reálných datech odhalil nečekané provozní problémy. Časová úspora, kterou přineslo použití frameworku Hibernate, se postupně rozpustila během hledání nápravy chyb a optimalizaci výkonu dotazů, které fungovaly v JDBC bez problémů. Lze připustit, že příčinou některých potíží byla naše nedostatečná znalost frameworku Hibernate, proto za jeho hlavní problém považuji dlouhou dobu učení. Naopak bezproblémové bylo využití frameworku Spring, který na servisní vrstvě řídil především dependency injection a databázové transakce. Projekt byl zákazníkem nakonec akceptován, ale hořký pocit z jeho vývoje zůstal a já jsem získal dojem, že některé věci by mohly fungovat jinak. V té době jsem začal psát framework, který je dnes známý pod názvem Ujorm.

Framework Ujorm je založený na doménových objektech typu key-value, kde klíče pro zápis hodnot slouží zároveň jako property-descriptor poskytující některé služby, například jejich řetězení. Taková architektura doménového objektu umožňuje (relativně) nový přístup ke tvorbě některých algoritmů, ale na druhou stranu budí i značné kontroverze. První veřejná verze Ujorm nabízela především perzistenci do XML souborů, kterou využila desktopová aplikace jWorkSheet pro měření času odpracovaného na projektech. Později vznikl modul ORM s dialekty podporující několik databázových produktů. Nakonec vznikl modul pro integraci webového frameworku Apache Wicket. V roce 2013 jsem zveřejnil jednoduchou webovou aplikaci pro fiktivní rezervaci hotelů s názvem Demo Hotels s cílem prezentovat zajímavé využití objektů implementujících interface Ujo. Kvůli jednoduchosti projekt obsahuje pouze jednu sadu doménových objektů, vyzkoušet si ho můžete zde.

Po zveřejnění této aplikace jsem dostal příležitost přepsat projekt pro administraci reálných služeb subdodavatele. Architektura projektu se změnila, servisní služby byly přesunuty na samostatný server, komunikace probíhala přes WS SOAP, na serveru proběhla integrace služeb třetích stran, nicméně původní technologie zůstala. A teď přijde zřejmě ta nejzajímavější část příběhu: vývoj modulu, který by v technologii JSF/JPA zabral člověku odhadem 3 měsíce – trval reálně 3 týdny. Jistě bude možné napadnout odhad té větší pracnosti jako nepřiměřeně pesimistický, ani neumím vyloučit, že by to napsal někdo jiný rychleji. Pokud by však měl někdo vážný důvod ten rozdíl zpochybnit, může aplikaci Demo Hotels přepsat do technologie JSF (na šablonách XHTML) s perzistencí JPA/Hibernate a následně porovnat objem zdrojového kódu obou projektů, objem projektu Demo Hotels odhaduji právě na čtvrtinu. Malá velikost zdrojového kódu však nemusí být jedinou indicií efektivního vývoje a tak doporučuji v hotovém projektu přejmenovat atribut entity Hotel.name a doplnit nové aplikační parametry, které by umožnily uživatelům nastavovat stránkování (počet řádků na stránce) v GUI pro každou tabulku samostatně. Zatímco chyby v projektu Demo Hotels po editaci odhalí snadno i programátorský junior díky kompilátoru (pokud IDE neprovede potřebný refaktoring automaticky), v případě technologie JSF/JPA bude pracnost úprav velmi záviset na zkušenosti vývojáře.

Závěr

Vypadá to, že způsob použití statických konstant s generickými typy a metodami pro čtení a zápis hodnot do doménového objektu byl ve své době unikátní. Na druhou stranu je pravda, že Ujorm může jen těžko soupeřit s konkurenty při srovnání rozsahu služeb či dokumentace. Letos uplyne deset let od uvolnění první verze ORM modulu frameworku Ujorm, od té doby byl nasazován na různých produkčních serverech bez větších provozních problémů, pokud vím. K masovému rozšíření však nedošlo.

Internetové odkazy

• domovská stránka projektu Ujorm
• blog projektu Ujorm
• popis použití objektů key-value v Ujorm
• popis aplikace DemoHotels (zdroj)
• zdrojový kód projektu Ujorm na GitHub
• návrh API typu key-value s podporou POJO