- How is KRAD different from Java Server Faces (JSF)?
- Is KRAD tightly coupled with the data access layer?
- Why do I have to write all this XML?
Before I answer these questions, you guessed it, a short history lesson! I pointed out in my introductory post that KRAD is a replacement for the Rice KNS (Kuali Nervous System) framework. However, KRAD retains many of the same goals as its predecessor. What were these goals? Well, there were many, but the major idea behind the KNS was to make it easier and quicker to build the Kuali Financial System, and then a bit later Kuali Coeus. In other words, it was geared for building large enterprise administrative applications. These are applications with many screens and which contain a lot of repetitive user interface content. While retaining this objective, KRAD expands to support student facing applications as well.
Another important factor in our decision making process is one of Kuali's core values: we are functionally, not technically, driven. What does that mean? Well, there has never been an official definition that I have heard, but to me it means this. First, requirements and priorities are set by functional committees. Second, those on the technical side should make decisions that meet those requirements, while minimizing delivery time and future maintenance costs.
Our situation on Rice though is very complicated. Recall, our first mission is to support the Kuali projects. However, we are a technical project. Furthermore, our second mission is to be a general development framework for use at higher ed institutions. This means we do attempt to stay as modern as possible with technology, pay back technical debt, and so forth (as evident by our current work on JPA support). However, even these work items go through functional approval and prioritization.
That should set the stage, so here we go!
How is KRAD different from Java Server Faces?
This raises the question, why create the additional layer? There are many advantages to this architecture, and it has been interesting to see benefits come about we never planned for. Even though there are many advantages, I can summarize the main reasoning with two points.
The Spring Framework
Why is this bean thing so great? It turns out the Spring bean framework is not just convenient and flexible for configuring service dependencies, but really any type of configuration. It has all the benefits of XML, with the power of Java inheritance. This provides a powerful environment for assembling pre-built components (see the next part) into a working user interface.
I realize this sounds a bit abstract (side note: I am noting this as a great topic for a future post). Let me give you one concrete way this approach benefits us.
Many readers have likely heard Kuali is "built by higher ed, for higher ed". Some people take this to mean the Kuali products have everything any higher ed institution will need, right out of the box. They simply install and go. This is not the case. Instead the out of the box products contain common functionality, as agreed upon by the higher ed partners. The rest is a customization effort by the institution (or commercial affiliate) implementing the product.
Now those who have attended a Kuali Days conference before have likely also heard the numerous vendor horror stories. The three complaints heard most often are:
- Vendor products are not built with the needs of higher ed in mind
- High licensing, support, and maintenance costs
- Painful implementations and upgrades, where attempts are made to adjust the vendor product, so that it better fits the institution's needs
Kuali provides relief in all three of these areas. The first two are taken care of by the Kuali foundation and the criteria it sets for new Kuali projects (higher ed partners, community source). The third pain point is remedied by the design of the Kuali products. A great amount of effort is put into making sure institutions can make the customizations they need to, with minimal effort, and in a way that does not have a significant impact on upgrades. Much of this product flexibility is provided through the Rice framework itself, and the Spring framework makes this possible. This ability to easily make institutional modifications includes the user interfaces.
For example, if an institution calls an 'account' a 'fund', or their account number is 15 digits long instead of 7, no problem! They modify a few lines of XML and that change is reflected across the entire application. Need to add some fields to the travel section of the KFS disbursement voucher? No problem. A few lines of XML is all it takes. Furthermore, these changes are done entirely outside the core product, which means there is no need to reapply them each time an upgrade is made. Contrast this to what it would take for most products. First to even make a simple change like modifying label text, you would need to search through thousands of lines of markup, and likely make the change several times. Each time an upgrade is performed you would then need to reapply each of these changes again. This is a process that becomes unmanageable for more than a very small number of customizations.
In terms of building user interfaces, tools like JSF (level 2) certainly provide many useful features, but they are still fairly low level. That is, they require development to make a complete functional piece. In these tools you will not find a control that searches KIM (Kuali Identify Management) users. Nor will you find a header containing document information, or a fully functional notes and attachments tab. These are the sort of things that KRAD is meant to provide, again building off the lower level tools. Note you will also find lower level components in KRAD, which in some cases map almost one to one with the lower level tool. In fact, when new developers learn KRAD this is generally what they see first, which leads to questions like the one I am answering now.
Even in cases where KRAD provides a basic function (like a simple text control or button), there is still great value to the abstraction. This is because KRAD can encapsulate features such as UX best practices, accessibility, authorization, security, user preferences, theming, and mobile device support. These are not trivial matters in terms of development, and a great challenge to consistently implement without the use of a framework.
That explains why we are building this 'level 3', but now the question becomes why didn't we build on JSF? Well, the short answer is there were features of JSF we liked, but also features of the other 'level 2' tools we liked. As much as we would all enjoy being able to pick and choose features from different libraries, we had to pick one.
Since that point we have basically been in heads down development and have not looked back (although there is now momentum gaining for looking into client side MVC frameworks). I hope this explains why we do not use JSF directly and why we chose to use other tools to build on. Now, developers who are familiar with both JSF and KRAD might be unsatisfied by this argument. They could say I have taken a narrow view here (looking at only the templating aspect), and there is much more to KRAD components and JSF, which contain duplication. For example, both have a lifecycle concept and similar component Ajax options. This is true. Unfortunately, with Spring/JSP we did not get any functionality like this and therefore built it ourselves (side note: I would really like Spring to add an abstract UI framework, like KRAD, to their portfolio someday). However, even though the concepts are similar, there are great differences in the implementations and the role they play within each framework.
In the interest of keeping this post from getting too long (and loosing your attention), I'll save questions two and three for the next post. Don't forgot to pass our blog along to others. It's the Kul thing to do!
Kuali Rice KRAD Architect
Senior Developer, Indiana University