1. research administration Kuali Rice: Enterprise Middleware Solutions Geoff McGregor Terry Durkin

2.  Kuali Rice – middleware suite of integrated products  Kuali Nervous System (KNS) – application development framework  Kuali Enterprise Workflow (KEW) – document routing engine  Kuali Identity Management (KIM) – identity and access management services  Kuali Service Bus (KSB) – common registry of remote services  Kuali Enterprise Notifications (KEN) – broker for university- related communications

3.  Bundled Mode  When you download KC, you are downloading Rice  By default, Rice is Bundled with KC  Behaves as one monolithic application  All services in local Spring context  Web content in the same war  Single DB schema

4.  Rice can be downloaded separately and run as an independent service  Standalone client integration options  Embedded  Remote  Hybrid – different modes by module

5.  KC was designed to make switching deployment modes relatively simple  kc-config.xml:  Modify.runmode parameters  If using embedded, specify the Rice datasource info  Ensure dev.mode param = false  If using KSB security, fill in keystore params  Modify rice.app.url to point to the Rice webapp url

6.  Rice services run in the client application and access the Rice DB directly  Independent Rice web app and database

7.  Fast – embedded client talks directly to the database  Scalable – processing load is distributed  No need for application plugins on the Rice server to handle application-specific logic

8.  Client applications interact with Rice standalone via KSB service calls or straight web service calls

9.  Loosest coupling  Easy to connect  May require multiple deployment artifacts (app + plug-in)  Reduced performance due to transport overhead

10.  Each module composed of a set of service interfaces and API components  Each module also has a reference implementation of those services  Each module publishes services on the service bus that are available externally  Services are located and invoked – they may be deployed locally or remotely and the caller does not need to know  Client applications code to the module APIs – don’t care about the underlying deployment mode DocumentService documentService = ServiceLocator.getDocumentService(); documentService.routeDocument(myDocument);

11.  Modularity powered by the resource loader stack  A component in Rice which locates and loads references to service endpoints  All services identified by a qualified name  Can also load objects from classloaders

13.  Sits at the bottom of the Resource Loader Stack  Simple service bus  Exporters  Connectors  Synchronous service invocation  Asynchronous reliable messaging  Service registry

16.  Provides the ability to scale applications horizontally  Can publish more than one service with the same name from multiple instances  KSB will round-robin requests, as well as fail over if an instance is down  KSB can identify which application cluster a service belongs to based on app’s Service Namespace

17.  Part of KEW  Build simple forms quickly  Ideal for quickly turning paper-based forms into electronic forms back by workflow and its features:  Document search  Action list  Email notifications  Route log  Routing rules

18.  Created with XML and optionally javascript  No java, no relational tables – data stored in a table by key- value  Data can be transformed and inserted into relational tables via postprocessor hooks, if necessary  Even ‘lighter’ (but more limited) than KNS Maintenance Documents

21.  As an enterprise middleware solution, Rice provides:  Common development framework for programmers and experience for users  Generic workflow engine can be leveraged by any application  Consolidated action list, doc search for all KEW-enabled eDocs  eDocLite for quickly building lightweight routable eDocs  Centralized, comprehensive identity management solution  KEW and KIM synergy for group and role-based routing  Communication broker for system-to-system integrations (e.g., KC-KFS)

22.  Why?  How long?  How many applications?  How many documents?  How many users?  How does it work?  Which Modules?  How many developers?

23.  Core infrastructure  Supporting Enterprise Apps  Supporting a shared development methodology for the institution  Supporting our Service Deployment and Deployment Strategy through KSB  Supporting our evolving IDM process through KIM  Supporting departmental processes through eDoc Lite

24. DateApplication May 2003Electronic Research Administration October 2003Human Resource eDocs June 2005EPIC (Electronic Procurement and Invoicing Center) October 2006Timekeeping September 2007Add/Drop Course November 2007Indiana University Foundation December 2007Grade Change November 2008Intelligent Infrastructure Billing February 2009Schedule of Classes July 2009Electronic Paid Time Off (EPTO) October 2009Travel May 2010Kuali Financial System - General Ledger August 2010Course Remonstrance August 2010Graduate Admissions Application

25. DateApplication February 2007Office of Affirmative Action July 2007Student Special Credit Request August 2007Safeword Card Administration September 2007University Graduate School – Course Remonstrance July 2008Office of VP for Research – Internal Funding Request August 2008Office of VP for Research Administration – Conflict of Interest August 2008Health Center Appointment Request January 2009Registrar – Staff Orientation Information Request May 2009Payroll Request September 2009Security Office – Web Vulnerability Scanning Request December 2009Registrar – Course Bulletin January 2010Optometry Appointment Request March 2010Motor Pool Vehicle Request March 2010Purchasing Contract May 2010Oncourse Adminstration Request August 2010Business Intelligence Project Submission

28.  Load balancer with four clustered Kuali Rice standalone server instances  Use Tomcat as the servlet container  Shared file system mount for attachments  Oracle database  Many client applications use an embedded workflow engine  This is our recommended integration model  There are a few “thin client” applications remaining which utilize plug-ins

30.  Designed for horizontal scalability  Load balancer helps to distribute requests  Could add additional application servers to suit needs  Over the years have moved from two application servers to four to handle increased usage  Using embedded workflow engines also helps to distribute the load

31.  Identity management at IU is handled by a separate team  Use a tool from Microsoft called “Identity Lifecycle Manager”  Provisions identity data into KIM database tables  Does so in as near real-time as possible  Implemented a custom SOAP service and published on the KSB to receive CRUD operations  Also integrates with Active Directory for groups

33.  Our Enterprise Portal is currently using a “closed-loop” version of the service bus to handle communication between different instances in their application cluster  Action List portlet  Notifications Channel  Future projects:  Bringing portal onto the enterprise bus  Loading student calendars via web services  KIM Integration

35.  Created a multi-page form to collect all disclosures  Faculty with nothing to disclose can simply submit the form after filling in some info  For those with disclosures, cut the processing time from up to two months, to within a week  No more data entry costs – staff can work on other things  Reporting:  Send reports to departments  Run reports to determine who still needs to disclose  Metrics

37.  For those faculty with no disclosures, they can select all “No” and they are finished  If “Yes” is answered to any question, it takes them to a screen where they can enter disclosures

38.  Top level Kuali Project  Investors, Project Board  Application Roadmap Committee – Features/Functionality  Technical Roadmap Committee – Tools, Libraries  Rice 2.0  Summer 2011  Workflow GUI/Rules processing  Version Compatibility (upgrade server/clients separately)  KRAD – Next-gen KNS, AJAX, updated tools