The Story of Ujorm
The Story of Ujorm
Checkout the story behind Ujorm.
Join the DZone community and get the full member experience.Join For Free
Somewhere back in 2008, I had an opportunity to participate in development of an interesting transport reservations system written in Java. The frontend was built on RichFaces, a former component framework for Sun Microsystems' JavaServer Faces. Business logic was placed into service classes managed by Spring framework, and the persistent layer was built on the Hibernate ORM framework.
An analysis by an experienced analyst was performed before the implementation; most of the development team consisted of developers with ages of experience in creating Java web applications. For the record, technologies mentioned above were relatively new for the team, but this risk factor was taken into account in the workload estimations.
First reactions were positive, partially thanks to the neat look of JSF components with embedded AJAX support. As time went by though, the development started to slow down. Maintenance of the JSF components (based on XML files) was becoming more and more difficult, safe refactoring was impossible, and their reuse for frontend was troublesome.
Typos were piling up in the service layer to method references, and Java's compiler – by design – wasn't able to recognize them. In the last phase of the project, the number of working developers had nearly doubled against the previous expectations. Despite this, it couldn't be finished in the expected time with the expected quality. Unfortunately, the trouble didn't stop there.
Usage on real data revealed unexpected operational issues. Time savings achieved by using Hibernate framework were gradually lost during bugfixing and performance optimization of queries, which worked just fine in JDBC. It's possible that our lack of experience with the Hibernate framework had caused the issues to some degree, which is why I consider the long period of time it took to learn the framework to be its major downside.
You may also like: Top 5 Courses to Learn Hibernate in Depth.
In contrast, the use of the Spring framework, which mainly handled dependency injection and database transactions was smooth and issueless. The project was accepted by the customer in the end, but the bitterness from the development sticked with me, and I realized that some things could work differently. This was the moment I began to write a framework, today known as Ujorm.
Ujorm is based on domain key-value type objects, where the keys used for writing values also serve as property-descriptors providing some services like their chaining. Such domain object's architecture on one hand presents a (relatively) new approach to creating certain algorithms, on the other hand engenders some controversy though.
The initial public Ujorm version introduced XML file persistence, which was used by a jWorkSheet desktop app for tracking time spent on projects. Later, an ORM module with dialects suppoting several database products was created. A module allowing integration of Apache Wicket web framework was eventually made. In 2013, I've published a simple web app for virutal hotel reservations – called Demo Hotels – in order to present an intriguing use case scenario of objects implementating the Ujo interface. The project contains only one domain objects set for simplicity purposes, feel free to try it out here.
After publishing this application, I got an opportuninty to rewrite the project for administration of real subcontractor's services. The project's architecture has changed, service classes were moved to a designated server, communication was mediated via WS SOAP, an integration of third-party serices was commenced on the server, but the initial technology has been preserved.
Now, here comes the most interesting part of the story: development of a module took only 3 weeks. However, the same implementation in JSF/JPA would take three months of work in my experience. Some may argue the estimate is way too pesimistic and I cannot exclude the possibility of someone else creating it faster.
With that said, should someone wish to dispute the clear difference between those times, I encourage them to rewrite Demo Hotels to JSF (on XHTML templates) with JPA/Hibernate persistency and then compare the size of both projects' source code. My estimate is the Demo Hotels project will be a quarter of the latter.
However, small source code size doesn't have to be the only indicator of an efficient development. Therefore, I recommend renaming the Hotel.name entity's attribute and filling in new parameters that'd allow users to configure the number of lines on a page via GUI separately for every table. While errors in Demo Hotels after the editing can easily be spotted even by a junior programmer thanks to the compilator (in case IDE doesn't refactor it automatically), in the JSF/JPA scenario will the difficulty of such edits very much depend on programmer's experience.
It seems that the approach of static constants use with generic types and methods for reading and writing values into a domain object was unique in its time. However, it's true that Ujorm can hardly compete with its competitors when it comes to range of services or documentation. This year will mark ten years of the first Ujorm Framework's ORM module release, since then it's been deployed on various production servers without major operational issues as far as I know. Mass deployment hasn't happened though.
Opinions expressed by DZone contributors are their own.