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

IU’s Rice Setup Kuali Rice version 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 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.