Kuali Rice at Indiana University

Kuali Rice at Indiana University Rice Setup Options July 29-30, 2008 Eric Westfall

IU’s Rice Setup • Kuali Rice version 0.9.1 + customizations • Java 1.5 • Tomcat 5.5 • Cluster of 4 Application Servers • Red Hat Enterprise Linux • Oracle 10g Database • Will learn more about these specifics later

Deployment and Integration • There are multiple options for deploying and integrating applications with Kuali Rice • Bundled – Kuali Rice software is “bundled” into your application • Standalone – a standalone server is deployed • In addition, when deploying a standalone server, the following client integration options are available, most relate to the KEW module • Embedded KEW – workflow engine is embedded into your application • KEW Java Thin Client • Web Services – for KEW and, eventually, KIM

Bundled Mode • All Kuali Rice modules are embedded into the client application, including the Web Application • Does not require the deployment of a standalone Rice server • Ideal for development or “quickstart” applications • This is not desirable for Enterprise deployments of Kuali Rice

Bundled Mode Diagram

Standalone Rice Server • The Standalone Rice Server allows you to run a central Kuali Rice application that can be integrated with multiple clients • Facilitates a single KEW Action List, Document Search, etc. • Allows for a shared KSB Service Registry • Supports multiple integration options for clients: • KEW Java Thin Client • Embedded KEW • Web Services

KEW Java Thin Client • Allows for a Java client application to integrate with the KEW module of Rice • Uses Java Serialization over HTTP • All workflow processing happens on the standalone server • If the workflow processing requires custom code (i.e. Post Processors), then plug-ins need to be developed and deployed to the server

KEW Java Thin Client Diagram

Embedded KEW • Embedded KEW allows you to configure a workflow engine embedded in your application but still use a standalone rice server • This allows for the following: • Integration of database transactions between client application and embedded KEW (via JTA) • Fast - Embedded client talks directly to database • No need for application plug-ins on the server • Still a single KEW web app but scalability is increased because of multiple Workflow Engines

Embedded KEW Diagram

KEW Web Services • There are a few web service endpoints that are exposed from Kuali Rice • KEW has a subset of it’s API available using this integration method • The KSB allows for exporting of services onto the bus using SOAP Web Services • In the future, we hope to add more web service endpoints to Kuali Rice • For example, KIM is being designed with web service remoting in mind

Bringing it all Together • Leveraging the KSB and the previous examples, it’s possible to utilize multiple strategies for Kuali Rice/KEW integration and deployment • Examples: • Some clients running as Thin Clients • Some clients leveraging code deployed in plug-ins on the standalone server • Multiple servers deployed in a cluster for scalability • Some clients integrating directly with web service endpoints • Some clients running in Embedded Mode • Numerous eDoc Lite applications • We’ll see a diagram of how we pull this together at IU a little later

The Whole Picture

Institutional Customizations • A major component of a successful Rice setup is to integrate it with existing services at your institution • Common Services include: • User Directory • Groups • Authentication • Authorization • Kuali Rice has a plug-in framework to faciliate this customization

Maintaining Institutional Customizations • We have a separate project at IU that is used for maintaining our customizations • Also used for packaging up the standalone server for deployment in our environments • Essentially, pulls the Rice jars and web content together to package a standalone server WAR • Standalone WAR packaged by the Rice team wasn’t available when we implemented 0.9.1 • Let’s take a look at the iu_workflow project

IU’s User Service • We implement a custom User Service which integrates with our Enterprise Directory Service (EDS) via LDAP • The implementation queries EDS for users when requested and then inserts/updates a row in EN_USR_T for the user • Only goes back to EDS on a configurable update period to check for updated user info • Also implements an in-memory cache of users for increased speed

IU’s Workgroup Service • Essentially the same as the out-of-the-box Workgroup Service provided with Kuali Rice • Does go to our Microsoft Active Directory Service (ADS) to fetch groups if they can’t be found in the Rice database

IU’s Web Authentication Service • Handles authenticating our users with CAS • We configure a CAS filter to redirect to our CAS server when required • The Web auth service then extracts information about authenticated from CAS filter • Also handles establishing a session for the user by caching some information • Groups they are a member of • If they are authenticated with our Safeword system or not • List of Roles that the user has in our ADS system

IU’s Web Authorization Service • Used to prevent user who only have Student roles in ADS from accessing certain portions of the application • List of restricted URLs is configured using KEW’s Application Constants.

Kuali Rice at Indiana University