Kuali Rice – ARC / TRC Update May 18, 2010 Eric Westfall – Kuali Rice Project Manager

Progress – November 2009 to May 2010 Kuali Rice 1.1 development kicked off in January 2010 Original Deliverables for Rice 1.1 Release in Q – Replace OJB with JPA – Spring 2.5 Upgrade – Improved XML import/export support – Adobe PDF automation contribution from Cornell – Complete the API module of Rice – Version Compatibility – KIM Management Screen improvements – FERPA and FIPPA improvements – Research running KIM standalone

Progress – November 2009 to May 2010 Kuali Rice released February 5th, 2010 – New KIM Service methods to support KFS access security – KSB Performance Enhancements – KEW Thin Client Enhancements – Numerous bug fixes – Other items in support of the KFS release

Progress – November 2009 to May 2010 Kuali Rice released May 14th, 2010 – KEW Application Document Status Enhancement. – Document linking mechanism in Rice. – The "remote" run mode for KIM and other Rice modules. – Rice Configuration Enhancements – Other items in support of the Kuali Coeus 2.0 release

Progress – November 2009 to May 2010 Cornell PDF functionality was contributed during Rice face-to-face in January Kuali Rice 1.1 was upgraded to Spring 3.0 Many pieces of the JPA implementation were completed – Configuration and other scaffolding for JPA put into place – Mapping of all entities in Rice – Data Access Object conversion – KSB, KEW and KIM middleware components were converted and mostly working – OJB to JPA conversion scripts were implemented…

But wait! JPA KNS

JPA and the KNS The KNS proved to be very problematic from a JPA perspective. KNS was designed on top of OJB and some of the fundamental differences between OJB and JPA prevented the Rice team from achieving a successful integration. It was becoming critical to figure out how to proceed…

JPA Deferral – ARC Vote ARC was presented with 3 options to vote on: – Should JPA be deferred? – If so, should some of the smaller scope 1.1 items be done on an earlier version of Rice. – If so, should that earlier version of Rice be a 1.0.x version or 1.1 (with version compatibility becoming 1.2) ARC voted as follows: – Yes – Smaller scope items on earlier version of Rice – Earlier version will be 1.0.x, not 1.1

KFS, KC, and KS Impact KFS - ceased JPA conversion work done so far – Migrated to the branch for bug fixes and enhancement work KC – had not begun JPA conversion yet – They were going to start on this for the next version KS – does not currently use the KNS but is planning to. – KS currently is implemented with JPA, so no JPA support in KNS impacts them.

Version Compatibility Version Compatibility is a major deliverable of Rice 1.1 Two types of compatibility: – Middleware (client-server) – Application Development Framework (i.e. KNS) The first of these is the most crucial from the perspective of satisfying our version compatibility requirements. – Supports rational upgrade process (no forced marches) – Supports multiple applications in same environment running against one Rice server

Version Compatibility - Continued Application Development Framework compatibility allows for non-impacting upgrades between Rice versions within a client application. Compatibility goals require changes and testing across 13 “areas”! – API – Database Structure – Datasets – URL – Service name – Configuration Parameters – Tag Libraries – XML Schema Changes – Service and DTO Versioning – XML Generated from XStream – Data Dictionary – Plugins – Dependent Libraries

DRAFT -Proposed Rice Releases The favored release restructuring approach discussed in Rice team meetings this week is as follows. 1.0.X ?? – XML import/export improvements – Adobe PDF automation contribution – KIM Management screen work which has already been defined and spec’d – KFS 4.0 bug fixes – Remaining KIM Management screen work 1.1 – API Module (modularity) (Necessary to achieve Version compatibility) – Version compatibility (Middleware Only! Defer ADF compatibility) – Spring Upgrade (already completed) – FERPA and FIPPA (relative priority?)