Kuali Rice 2.0.0-b1-SNAPSHOT Release Notes

In Kuali Rice 1.0.x, services based on Java serialization were the primary services used for integration between Kuali Rice and client applications. The mechanism by which serialization was performed used Spring's HTTP invoker remoting framework. Java serialization is convenient for Java-to-Java application interaction. However, a SOAP web service approach allows for a greater level of interoperability between applications, including those not written in Java. Additionally, serialization can sometimes inherently cause compatibility issues when attempting to communicate between applications which might be running different versions of Java or different versions of libraries.

To this end, the services in Rice 2.0 have all been reimplemented as SOAP-based web services. There will be no Java-serialization based service distributed with Kuali Rice 2.0. However, the Kuali Service Bus will still support publishing of services that use Java. As part of this effort, the team has taken care to carefully design the message formats such that:

Much of the above information can be found in the WSDL's which are generated for each of the services. The WSDL defines the message formats, operations, and error conditions of the numerous Kuali Rice services. This effort of service refactoring is at the heart of what we are calling "version compatibility" for the Kuali Rice 2.0 release.

Note that while SOAP is being used as the primary way in which services are exposed in Rice 2.0, there will likely be work in the near future to make services available using the REST architectural style.

In order to support requirements for version compatibility, there were numerous changes that needed to be made to the Kuali Service Bus. This ultimately resulted in a reworking of much of the internals of the KSB (with the exception of it's messaging functionality). The major changes made to the KSB for Kuali Rice 2.0 were:

As can be seen from the list above, much work was done to the service bus for Kuali Rice version 2.0. For more details, read the following page https://wiki.kuali.org/x/T3dyEg

In Rice 1.0.x, parameters, namespaces, and components were part of the KNS module of Rice. Client applications would access tables in the Kuali Rice server database directory in order to read and write values from these tables. As part of the general effort to modularize the Rice platform, it was decided that these three concepts were core concepts since they were used outside of the pure application development domain of the KNS (parameters in particular are used all over the Kuali Rice codebase). To this end they were moved to the newly established "core" module of Rice (see more information on modularity work in later sections).

Additionally, SOAP services were created for each of these to eliminate the need for a client application to directly communicate with the related database tables, instead using a service-oriented approach to interacting with these different information sources. This resulted in the creation of the following services:

For working with parameters, there is still a ParameterService this is provided as part of the client-side API. This service is configured with the application id of the application and delegates calls down to the remote ParameterRepositoryService.

For the ComponentService, it provides a new mechanism for publication of "derived" components, which can include components that are derived from an application's data dictionary configuration. This is a replacement for the "getNonDatabaseComponents" method which was part of the RiceApplicationConfigurationService in Rice 1.0.x. It uses a push model in contrast to the pull model which was used in Rice 1.0.x.

More information about these individual services and their available operations can be found in the javadocs. Also see the following page for more details on the work that was done with these services, including a description of the new model used for publication of derived components: https://wiki.kuali.org/x/tg5yEg

In Rice 1.0.x, the RiceApplicationConfigurationService was a service published by all KNS applications which provided callbacks into the application from the Kuali Rice standalone server. This service was removed in Rice 2.0 for various reasons. The reasons for it's removal and information on it's effective replacements can be found on the following page: https://wiki.kuali.org/x/vA6tEg

In Rice 1.0.x, may of the services (particularly the KIM services) had general-purpose lookup methods which took a Map<String, String>. In this map, the key was intended to represent the property name on the data element being looked up and the value was intended to be the value to search for. The value itself could contain various wild card characters and other operators to allow for the construction of more complex searches. However, there were a few inadequacies with this approach:

To this end, some work was done to design a general purpose lookup API that could be applied in a standard fashion across the various Rice services which needed it. The following page describes more about the various possibilities for implementing this as well as the solution which was chosen: https://wiki.kuali.org/x/PR9yEg.

The implementation of this api can be found on the core-api module under the package org.kuali.rice.core.api.criteria.

The Kuali Enterprise Workflow services have been refactored for version compatibility in a similar fashion to the rest of the services in Rice. As part of this effort, a bit of a rearchitecture of the service layer and APIs for workflow were performed as well. The major changes made to the workflow services and apis are as follows:

Some rough notes with more details on the work that was done in KEW can be found here: https://wiki.kuali.org/x/fwuREg

One of the major KEW framework refactorings that was undertaken for Rice 2.0 was a reimplementation of the various components that support Document Search customization. Full documentation on these changes and how to utilize them is still in progress, but a summary is as follows:

Further documentation on how to migrate from the old document search framework to the new document search framework is forthcoming. For the time-being, the best resource is to look at the javadocs for the org.kuali.rice.kew.framework.document.search package. All of the framework apis should have fairly thorough javadocs. Additional, some rough notes on the document search work and architectural service approach for the customization handler service can be found near the bottom of this page: https://wiki.kuali.org/x/fwuREg

In Rice 1.0.x, caching was implemented using a framework called OSCache along with distributed caching flushing behavior across the KSB. This worked well in general, however this setup was plagued by issues of far too many cache-related message events getting generated and sent. Additionally, OSCache is a long-dead project which has not had any activity in a long time. In order to ensure that Kuali Rice was positioned for service compatibility moving forward, an effort was undertaken to revamp and update the caching architecture utilized by the Rice platform and find a better and more sustainable solution.

The result is a solution based on the caching abstraction provided with the core Spring framework version 3.1. The backend caching implementation being used is Ehcache (which is the default recommended by Spring). There is a also integration with the Kuali Service Bus for sending cache eviction messages out to interested listeners. This allows us to keep our caching consistent across different applications in an enterprise architecture which has been integrated with Kuali Rice.

More details on the specific work that was done to rearchitect the Kuali Rice caching infrastructure can be found here: https://wiki.kuali.org/x/XgmWEg

A new concept was added to Kuali Enterprise Workflow as part of workflow routing requirements for Kuali Coeus. The requirement was essentially to replicate the functionality of "Maps" in the existing Coeus system upon which Kuali Coeus is based. These maps are simply lists of people or roles who can approve in a particular order. This order is defined by a series of "stops". At each stop there can be a number of possible approvers which may have delegates.

There was not really an equivalent concept in KEW today, this is essentially like a mini-workflow itself. So the concept of PeopleFlows were added along with a new activation type called "Priority-Parallel" activation. This priority-parallel activation allows for action requests to be activated at a node in parallel if they have the same priority, but in sequence if they have different priority values.

Further details on the implementation of PeopleFlows, their lineage in Coeus, as well as some screenshots of the maintenance user interface can be found here: https://wiki.kuali.org/x/3R6REg

The previous section introduced the concept of PeopleFlows. The KRMS module will have integration with PeopleFlows built in through the use of a custom type of "Action". This action will allow a rule author to build a business rule and then indicate that the action that should be executed if the rule succeeds would be to route to the specified PeopleFlow.

Details on the way this integration is implemented can be found here: https://wiki.kuali.org/x/3R6REg

KRAD (Kuali Rapid Application Development) is a framework that eases the development of enterprise web applications by providing reusable solutions and tooling that enable developers to build in a rapid and agile fashion. KRAD is a complete framework for web development that provides infrastructure in all major areas of an application (client, business, and data) and integrates with other modules of the Rice middleware project. KRAD is the next generation of the Rice Kuali Nervous System (KNS) and Kuali Student development frameworks. It expands on the ability to rapidly create user interfaces with XML while providing more flexibility with layouts and user experience. In addition, KRAD allows for the creation of modern, rich user interfaces using the jQuery and Fluid frameworks.

How does KRAD improve on the KNS? See Benefits of KRAD.

To learn more about KRAD, please visit the following pages:

In addition, see various analysis pages here (Note: some of the information might be incomplete or out of date): KRAD Analysis

KRMS (Kuali Rule Management System) is a new module in Rice that enables the externalization of pieces of business logic (rules) from an application such that it is customizable without need for additional client programming. Agendas containing custom business rules can be defined, edited and stored in the repository, and then executed by the application against some set of information (facts).

There is also integration between KRMS and KEW's new PeopleFlow concept that enables invocation of the rule execution engine from within a workflow. Rules can be configured with PeopleFlow actions that specify PeopleFlows to route to or to notify.

View the following analysis page for some additional information on KRMS:KRMS Analysis