Saturday, June 29, 2013

Common Questions (aka Criticisms) About KRAD (P1)

As promised, in the next few posts I will answer some questions regarding the KRAD architecture. I have picked three questions we get the most, and that will also allow me to relay important principles of Kuali and the Rice project. These are:

  1. How is KRAD different from Java Server Faces (JSF)?
  2. Is KRAD tightly coupled with the data access layer?
  3. 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 is a great question and I am not surprised it gets asked often, for one simple reason: much of KRAD was designed based on Java Server Faces! So why do we not just use JSF? To answer this I need to describe the concept of components in KRAD. In functional terms a component is a reusable piece of UI content. There are basic components like text controls, buttons, and images. There are also more complex course grained components like tables, dialogs, and pages. Now, with JSF you can create much of the same UI content (text control, button, table, etc). So is KRAD meant to compete with JSF? No! KRAD is meant to build on top of tools like JSF.

Here is how it works technically. Producing HTML (and JavaScript) is the final goal, let us call this HTML markup level 1. JSF builds on HTML. Developers create JSF markup, and it in turn generates the HTML. So it is an abstraction, therefore let us call the JSF markup level 2. There are many other libraries like JSF that operate at level 2. For example, JSP, Velocity, FreeMarker, GWT, and various JavaScript libraries (I realize these tools are not really all the same, some do much more, but in general they all provide this HTML abstraction). Now KRAD builds another abstraction layer on these tools at level 2, creating a level 3. In other words, KRAD generates Freemarker/jQuery, which generates HTML. This abstraction layer in KRAD is provided by components.

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 

Rice is built using much of the Spring portfolio. To us, Spring is the best thing since sliced bread! We like it so much that we have expanded use of the Spring bean framework (also known as the Spring configuration system) to other areas besides dependency management. For example, the KRAD Data Dictionary uses the bean framework to configure metadata about application entities. Furthermore, the KNS used Spring beans for configuring some common screens (Lookup, Inquiry, and Maintenance). For KRAD, we wanted to use Spring beans for building all our user interfaces.

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:

  1. Vendor products are not built with the needs of higher ed in mind
  2. High licensing, support, and maintenance costs 
  3. 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.


Let us recall our history lesson and one of the primary goals of KRAD. Essentially this is to build enterprise web applications faster. How does a framework help us build software faster? One of the ways it can help is by pre-building functionality. Most applications have repetitive content, and certainly across multiple applications there exists a lot of repetitive content. We look for functionality like this and build it once, so that it does not have to be built multiple times by other Kuali developers.

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.

The initial functional requirements for KRAD (remember functionally driven) consisted of a list of roughly 20 'rich' UI features that were needed (as you might expect that list has grown greatly since then). Our mandate was not really to upgrade the Kuali tool set. However, we were using an old version of Struts (version 1), and really did not have any JavaScript library in place. Therefore adopting new tools was necessary to achieve the functionality in a way that would allow future growth (side note: this is a good example of how we can get technical issues addressed that likely would never get prioritized high enough by the functional groups). We performed extensive research on tools at that time (roughly 3 years ago, way before JavaScript MVC frameworks). Many of these met the requirements, had vibrant communities, and a promising future. The criteria then shifted to costs. What is the work involved to add the support in the framework, and then what will be the work involved for the existing Kuali applications to convert. The Spring/jQuery/JSP solution (now Spring/jQuery/FreeMarker) by far provided the lowest barrier.

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!

Jerry Neal
Kuali Rice KRAD Architect
Senior Developer, Indiana University


  1. Jerry, I think you have a fundamental misunderstanding of JSF. JSF is absolutely a "level 3" technology, and I think when you subtract domain-specific components (e.g. document header, notes/attachment tab), JSF and KRAD are very similar.

    The arguments I would buy are that JSF 1.0 gave JSF a bad reputation; and that being a JavaEE technology, JSF is CDI-centric and does not work well with Spring, in which Rice is heavily invested.

  2. Hi Ken,

    I could buy that JSF is a level 3 technology. What I was trying to relay with the level thing, is that KRAD is meant to build one level beyond whatever the tool of choice is. The main reasons being for the Spring integration, and to build more course grained Kuali specific content.

    I agree they have a lot of similarities, in particular with the basic components.

    Note, during the KRAD analysis phase I mentioned above, I really liked JSF and was supportive of using it. But in the end it came down to costs, and the technical committees felt JSF was too big of a change from the tools we had been using (although using KRAD itself is a big change, although I think knowing the tools underneath were familiar helps).

    Thanks for your feedback!

  3. "I would really like Spring to add an abstract UI framework, like KRAD, to their portfolio someday."

    Alfresco offered their Surf platform to Spring, but it appears that it never took off outside of Alfresco. I would love for the Kuali Foundation to approach SpringSource about donating the KRAD core to Spring. I want the Kuali Foundation focusing on functionality more than infrastructure. The more generic code that can be pushed out into a greater (i.e. not-just-higher-ed) community, the better for us all.

    1. I am absolutely with you! That would be very beneficial for both parties in my opinion.

      We have tried to get some connections for possible collaboration. When VMware became a Kuali partner we wrote a letter discussing some potential ways of collaborating, including KRAD. Nothing came of that but it is hard to know if it made it to the right people. I have attempted to contact some Spring folks as well with no luck.


  4. Excellent article. I'm adding this to Kuali Student required reading for on-boarding.

  5. Not a fan of JSF here. But I enjoyed the article and it will surely help me explain to my non-Kuali peers the reasoning behind KRAD rather than just using JSF or something else. Much as I dislike most level-2/3 tools that I've used thus-far, I understand the need for them increases the more enterprise a product becomes.

    1. Thanks Brandon, I appreciate the comment!

      I think there is not really any one tool that is good for all situations. Where KRAD and other higher level tools might come in valuable is for those institutions who want to make a long term investment in developing software. Really the gains come from developing software in the mass (and collaboration as well). But due to the high initial costs of using these tools, they are probably not the best for one off or small apps.