kuali rice at indiana university rice setup options july 29-30, 2008 eric westfall
TRANSCRIPT
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.