Kuali Rice at Indiana University Rice Setup Options

  • Slides: 19
Download presentation
Kuali Rice at Indiana University Rice Setup Options July 29 -30, 2008 Eric Westfall

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

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 10 g Database Will learn more about these specifics later

Deployment and Integration • There are multiple options for deploying and integrating applications with

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

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

Bundled Mode Diagram

Standalone Rice Server • The Standalone Rice Server allows you to run a central

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

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

KEW Java Thin Client Diagram

Embedded KEW • Embedded KEW allows you to configure a workflow engine embedded in

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

Embedded KEW Diagram

KEW Web Services • There a few web service endpoints that are exposed from

KEW Web Services • There 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

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 e. Doc Lite applications • We’ll see a diagram of how we pull this together at IU a little later

The Whole Picture

The Whole Picture

Institutional Customizations • A major component of a successful Rice setup is to integrate

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

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

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

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

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

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.