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.