Rice 2.0 Work Remaining

Rice 2.0 is the first beta release and the goal of this release was to ensure that approximately 95% of the functionality was complete prior to the public beta test. The following sections summarize major work items that still need to be completed prior to the generally available release of Kuali Rice 2.0. Work will continue to try and resolve these issues as soon as possible for future beta releases.

"Remote" and "Embedded" client application configurations

There was much work done in Rice 2.0 to refactor the layout and organization of the project and it's services. This was primarily driven from the perspective of work being done both on improving modularity for the 2.0 release as well as requirements for version compatibility. Unfortunately, as of the first beta release for Rice 2.0, there is still cleanup work to do to allow for proper configuration and operation of non-bundled client applications. For those unfamiliar with the concept of "bundled" vs. "non-bundled", options for integration with the Kuali Rice middleware is essentially as follows:

  • bundled - in this model, a single application is bundled together with the Kuali Rice services and web application. This allows for that application to be deployed without the need to set up a separate application deployment for Kuali Rice. This model is not intended for "enterprise" application deployments because it prohibits proper reuse of the Kuali Rice middleware as a shared set of services.

  • standalone - in this model, a Kuali Rice "standalone server" is deployed which hosts the Kuali Rice web application along with all of it's services. Client applications can then integrate with the standalone server instance through various "run modes" which are supported by the client-side pieces for the different Kuali Rice components (KEW, KIM, KSB, etc.). This integration model makes more sense for an enterprise deployment of Kuali Rice because it allows the standalone server instance and the services it provides to be shared and leveraged by multiple applications within the enterprise.

For applications that are integrating with a standalone server, there are three primary possibilities for integration (generally, it's possible to integrate with different modules of Rice in different ways):

  • remote - in this mode, the client application will be configured to connect to the KSB service registry and will invoke remote rice services using the server endpoint information located within the registry

  • embedded - in this mode, some or all of the module will be "embedded" into the client application (in Rice 2.0, this mode is only supported by KEW and KIM). When using this client-integration mode, the client application will connect directly to the Kuali Rice database.

  • manual - all of the Kuali Rice services are available as SOAP web services, so any application can build a manual web-service client using information found in the WSDL's for the services published by the Kuali Rice standalone server. In these cases, there is generally no Kuali Rice code that need to be configured or used within the client application.

Because of the issues mentioned previously, not all of the modules in Rice are configured to fully support the remote and embedded configurations (however, manual web-service integration should be possible). For this reason, we are recommending those participating in the beta test start by working on upgrades to any Rice standalone server instances they have as well as running Rice 2.0 in "bundled" mode with any existing applications they wish to convert to Rice 2.0.

Configurers

Related to the previous item of remote and embedded client application configuration, part of the issue here lies with the fact that there is still outstanding work on how to set up client "configurers". Those familiar with Rice 1.0.x will recall the RiceConfigurer class which was used to load and configure the various Rice modules. In Rice 2.0, this class no longer exists and it's replacement is org.kuali.rice.core.impl.config.module.CoreConfigurer. However, the core configurer only configures the basic "core" of Kuali Rice. The other modules (such as KEW, KSB, etc.) have their own configurers as well.

The best place to look at for an example of how to configure Rice 2.0 is in the file impl/src/main/resources/org/kuali/rice/config/RiceSpringBeans.xml. This file imports other spring files which configure the various Rice modules. These files can also be imported into an application's Spring file in order to configure that particular module (unless an alternative or customized configuration is needed). Note, however, that the way in which Rice is configured will likely be adjusted in future beta releases, but information and documentation on such changes will be communicated along with those releases.

Caching

There is still work outstanding on the caching infrastructure for Kuali Rice. Remaining work primarily revolves around how client-side caching is managed and performed. Much of this work relates to the outstanding issues resulting in the inability of configuring remote and embedded client-side integration patterns.

KEN and KCB Services

The KEN and KCB services have not yet gone through the refactoring to align them with Kuali Rice 2.0 service compatibility standards. The services that are published for these modules will likely change in subsequent beta releases. However, they should be finalized prior to the final release of Rice 2.0.

Custom Action List Attributes

Work is still being undertaken to reimplement the Action List customization framework so that it adheres to Rice 2.0 version compatibility standards.

Document Search

As a result of heaving refactoring of the document search frameworks for version compatibility in Rice 2.0, there is still work remaining before this framework will have parity with the implementation that was in place in Kuali Rice 1.0.x. Specific outstanding work that remains here includes:

  • Support for range-based searches on search attribute values

  • Application document status search support

  • Route Node Name and Route Node Logic search support

  • Proper data formatting in result set

  • Ability to indicate column visibility on searchable attribute fields

  • Ability to customize help link on document search

  • Ability to pass query parameters via the document search URL

  • General cleanup and documentation

createproject.groovy

The createproject.groovy script has not yet been converted over to produce a valid Rice 2.0-based project.

Documentation

Document is still in a rudimentary state. During the course of the beta releases, it will be reviewed and augmented.

Upgrade Guides and Upgrade Scripts

These guides and scripts are not yet fully complete. However, final documentation and scripts will be provided prior to the final release. To access rough versions of scripts and some contributed by other members of the community, please visit the beta test site.