As mentioned in the overview and highlights, there were many major changes that were made in support of the goals of the Rice 2.0 release. During the implementation of modularity and version compatibility changes, there were many structural improvements and refactoring changes to Rice that are intended to help set a stronger foundation for future releases. Additionally, the KRMS and KRAD modules brought a large amount of new functionality to the Kuali Rice platform. These next sections dive into these changes in more detail.
In Rice 2.0, we are providing what we call "middleware" or "service" compatibility. This type of compatibility is mainly concerned with compatibility between a client application and the version of the Kuali Rice standalone server with which it is integrated. The basic requirement here is that if the Kuali Rice standalone server (which hosts all of the Kuali Rice services) is upgraded to a new version, that should not force any applications that integrate with those services to also upgrade (unless the server has been upgraded to a new "major" version such as Rice 3.0, 4.0, etc.). It should be able to continue to interoperate with the new set of services without having to pull in new Kuali Rice client libraries or (in the case of manual web-service integration) it should not have to modify the way in which it invokes and handles remote service calls.
The image below shows what the target is for version compatibility from the perspective of major, minor, and patch releases of Kuali Rice.
The type of compatibility being implemented for version 2.0 is in contrast to what we call "framework" compatibility, or the ability to upgrade a client application to a new version of the Kuali Rice client libraries or development framework without having to make any forced changes to that client application. Those who use Java are familiar with this type of compatibility because that is the level of compatibility that is generally provided between releases of the JDK (this is sometimes called a "drop-in" replacement). Working toward a goal of framework compatibility is on the roadmap for the Kuali Rice project, however the Rice 2.0 release makes no guarantees that it will provide such a level of compatibility moving forward.
More info on this and also Framework Version Compatibility can be found in our Kuali Rice Version Compatibility Statement.
The following sub-sections will delve into some specific work that was done in support of version compatibility.
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:
The "required" portions of the message format are well-defined
The proper format of data in the messages in well-defined
Error and exception cases are well-defined
The services are designed to allow for safe evolution over time
The services are namespaced and named appropriately
The services are versioned appropriately
There is consistency in how services are designed and documented
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:
Client applications now connect to the service registry through a SOAP web service, rather than through direct connections to the KRSB_SVC_DEF_T and related tables.
There is a new API for the ServiceBus which is well documented and acts as the client application interface point with the KSB.
The practice of storing a java serialized form of the service configuration in the database was altered to store an XML-serialized service descriptor. This allows for more portability and greater access for non-Java applications to interact with the service bus.
Removed the faulty "dead service" indicator from the registry.
Added the concept of a service status to the registry.
Added service version number information to the registry.
Replaced the concept of the "service namespace" with the concept of an "application id".
Introduced the concept of an "instance id" which identifies an instance of an application. This allows the KSB to better handle applications that are clustered with multiple deployments all publishing the same set of services.
Much more flexibility in how a client application can configure and use the KSB. For example, a client application could just configure the KSB client to act as a publisher of a service, or it could just connect to the KSB as a consumer of services. As well as additional configuration permutations related to support for reliable messaging and "development" mode (where services are not actually published).
A general refactoring of the internal architecture of the KSB related to handle it handles the publishing lifecycle of services as well as synchronization with the shared service registry.
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:
org.kuali.rice.core.api.parameter.ParameterRepositoryService - remote service which provides operations related to system parameters
org.kuali.rice.core.api.namespace.NamespaceService - remote service which provides operations related to namespaces
org.kuali.rice.core.api.component.ComponentService - remote service which provides operations related to components, as well as implementing a new model for publication of "derived" components
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:
If an institution wanted to implement their own version of the service, they would effectively need to implement a complex interpreter which would take the incoming String value and determine how to implement the lookup according to the values passed in.
There was no way to preform cross-property "ors" with this model.
There was no support for "paging" of query results.
The contract itself tended to be weakly defined, resulting in service methods that would be hard to maintain from a service compatibility perspective.
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:
The
WorkflowDocumentclass is now an interface and is created usingWorkflowDocumentFactory.createDocumentorWorkflowDocumentFactory.loadDocumentinstead of creating new instances through theWorkflowDocumentconstructor.SimpleDocumentActionsWebServicewas combined withWorkflowDocumentActionsto create the newWorkflowDocumentActionsServiceremotable service.WorkflowInfoandWorkflowUtilitywas removed and replaced with the following services:WorkflowDocumentServiceActionListServiceDocumentTypeServiceNoteServiceRuleService
The various KEW framework services were refactored to conform to service version compatibility standards. This includes services for document search customization, action list customization, workflow notes, document security, rule validation, and workflow rule attributes.
The various KEW message queues were refactored to conform to service version compatibility standards. This includes queues for document routing, blanket approval, immediate email reminders, searchable attribute indexing, document requeuing, etc.
In the KNS, both
KualiWorkflowInfoandKualiWorkflowDocumentwere removed as it was deemed this duplicate level of abstraction was unnecessary. In the case ofKualiWorkflowDocument, existing references were changed to justWorkflowDocument. In the case ofKualiWorkflowInfo, code was changed to call one of the new KEW services that was added in Rice 2.0.
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:
SearchableAttribute- class still named the same but moved to a different package, method names changed, returnsRemotableAttributeFieldinstead ofList<Row>Client applications no longer allowed to override or use these attributes:
DocumentSearchCriteriaProcessorAttributeDocumentSearchGeneratorAttributeDocumentSearchResultProcessorAttributeDocumentSearchXMLResultProcessorAttribute
The only valid document search-related attributes are now:
SearchableAttributeDocumentSearchCustomizerDocumentSecurityAttribute
The
DocumentSearchCustomizerreplaces most of the original document search-related attributes. It is a single attribute which allows for customization of criteria, results, and various other aspects of the Document Search operation.The customizer itself is not remoted, instead a
DocumentSearchCustomizationHandlerServiceis published by each KEW client application. This allows for a client application to implement as many customizers as they want and map them to the document types they should apply to viaDocumentTypeconfiguration. The Document Search functionality itself will then callback into the client application when it needs to via the publishedDocumentSearchCustomizationHandlerService.The new document search framework uses the
RemotableAttributeFieldabstraction for defining fields that should be displayed as extra search criteria. This is in contrast to Rice 1.0.x where KNSRowandFieldobjects were transmitted using Java serialization. This old model did not translate well to SOAP-based services and had numerous other problems as well (namely that not all ofFieldandRowwas properly serializable or could be interpreted correctly by the Rice standalone service, such as custom formatters, values finders, etc.).
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
In version 1.0.x of Kuali Rice, the software was divided into 3 main modules: api, impl, and web. While this was convenient from the development perspective, it resulted in a high level of coupling between the various "logical" modules of Rice (the core, kew, kim, ksb, etc.). Attempts were made to rectify some of these issues in Kuali Rice 2.0. Since the full vision for modularity in Kuali Rice was not in scope for the 2.0 release, as much work was done on modularity as could be permitted in order help reach version compatibility goals for the release.
Primarily, this included the creation of numerous "api" and "framework" modules and the partitioning of Kuali Rice into various sub-project modules. This structure can be seen when looking at the source code for Rice 2.0. The overall vision for modularity in Kuali Rice as well as some notes on specific changes that were made in pursuit of it can be found at the following links:
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
XAPool/Bitronix Configuration Changes (KRDOC-382 )
New configuration Parameters related to component publishing (KRDOC-386)
Drop support of Tomcat 5.5, servlet spec 2.4,jsp 2.0) - KRDOC-223
Changes to configurers and run modes (KRDOC-389)
There were many changes made to the various direct and transitive dependencies for Kuali Rice. Additional documentation is forthcoming on what these specific changes were, but the following is a summary of some of the highlights:
Spring 3.1
currently on RC1 of this library, but it is expected that the generally available release of Spring 3.1 will be available prior to the generally available release of Rice 2.0
Apache CXF 2.3.6
OJB 1.0.4-patch7
includes various patches from the Kuali community
Direct Web Remoting (DWR) 3.0.RC2
Ehcache 2.4.6
Groovy 1.8.1
joda-time 2.0
JOTM 2.1.9
Bitronix 2.1.1
Quartz 1.8.4
Spring Security 3.0.7
Struts 1.3.10
Tiles 2.2.2
jQuery 1.6.3
There were many other changes made in Kuali Rice 2.0 which are not included in the previous section. The following list is a highlight of some of these. For a comprehensive list of changes that were performed, the Jira issues are the best place to look.
Removal of DateUtils and NumberUtils (KRDOC-232)
Changes in how unit tests and integration tests are run (KRDOC-367)
Addition of Priority parallel activation type (KRDOC-380)
Use of immutable objects and the builder pattern for various APIs
Removal of "object remoting" functionality from the KSB
Conversion of identifiers from numeric to character-based data types in KEW
Changes to PersistableBusinessObjectBase and notes (KULRICE-4862)
Normalization on a single concept of "application id"
Unique constraint on kim permission namespace:name and responsibility namespace:name
Clean up of multiple "key-value-pair" style classes (KULRICE-4854)
Transition from custom-written email services to standardizing on the spring mailer (KULRICE-4863)
Move to Maven version 3
DateTimeService converted to use configuration parameters instead of system parameters, allowing for it to be used through more of the system without the need for database dependencies
Kuali Communication Broker (KCB) integration turned off by default
Removal of IdentityManagementService, replaced with individual service calls in KIM
Replacement of AttributeSet in KIM service apis with simple Map<String, String>
Renaming of various data elements in KIM to more closely align with PESC standards (KULRICE-5360)
Ability for a RouteModule to be called back into multiple times in order to generate more requests in support of new PeopleFlow feature
Hours of availability awareness (KULRICE-5695)
Change from WorkflowFunctions to EDLFunctions (and package name changes) in eDocLites
Ability to define finer-grained Action List notification preferences for KEW (KULRICE-5848)