Transcript KEW Java Thin Client

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.