Kuali Rice: Cross Project
Middleware
May 21, 2007
Aaron Godert - Cornell University
Nate Johnson - Indiana University
The Goals



The board vision for Kuali is a plug and play
module by module approach to software
Kuali started as financials, but has evolved into a
suite of administrative software (KFS, KRA, KS)
Highly productive development environment


For Kuali projects
For non-Kuali projects
Goals cont.

A common and consistent architecture
Allow developers to understand other rice
enabled projects
 Infrastructure would not need to be reinvented
on each project - focus on functionality!
 Rice team can focus on IT standards, like SOA,
that will benefit the entire Kuali software suite
 Adoption of other Kuali modules feasible

Rice is middleware
Made up of several, possibly standalone
and swappable, middleware components
 Applications can use a “Rice Client” to
easily integrate with this middleware
 By using this client, interacting with other
rice enabled applications comes for free


KRA using services deployed in other projects
How we got here
Several separate applications needed to be
connected and share services in a loosely
coupled fashion
 Kuali products needed to be technically
consistent under the hood

For end user support
 For different development methodologies

How we got here cont.

More reasons for technical consistency
Most administrative applications have a
common need for middleware services
 Avoid design and code duplication
 Consolidate configuration

Rice Components

KEW
 KNS
 KSB
 KEN
Kuali Enterprise Workflow
Kuali Nervous System
Kuali Service Bus
Kuali Enterprise Notification

We should take a look at the history of each
of these products before talking in more
detail how they apply to Rice
The History of KEW




Kuali Enterprise Workflow existed at Indiana
University as a stand alone integration project
before Kuali began
Provided common engine to drive business
processes electronically
Provided relatively simple API allowing choices on
how to create workflows
When Kuali came along, the IU workflow engine
became Kuali Enterprise Workflow (KEW)
The history of KNS

KFS spent a large amount of development
time up front, using its best and brightest
people, and came up with a great
foundation on which to build KFS - the Kuali
Nervous System!
This history of KNS cont.

It focused on a unified approach
A standard way to use workflow
 A standard way to maintain support tables
using CRUD operations
 A standard way of creating business
transactions, which in the case of KFS was
posting financial transactions

This history of KNS cont.
The KNS abstracted a lot of the complexity
of developing the functionality of a financial
system
 By doing so it provided a large set of
reusable code

Enforced consistency in the KFS codebase
 Enhanced productivity for KFS developers


But this only benefited the KFS
The history of the KSB


Other Kuali projects came along: i.e. KRA
They needed to be able to seamlessly “talk” to
other Kuali services/applications in real time



Reducing the need for offline batch
Increasing business process agility
The KSB was born


Currently used by KEW and hence KFS
Will be 0.9 version by July 1, 2007
The history of KEN
Kuali applications wanted an advanced
model for end user communication
 The concept of Kuali Enterprise Notification
was born
 KEN unifies different communications for
users

The history of KEN cont.

It allows user preferences for notification
Users can choose how they are notified
 Preferences are saved for future notifications


Could be used for emergency
communication in times of campus crises
Cell phones, instant messages, email, etc
 Mass notification from user’s preference to
better reach the campus community quickly

Why does a project need Rice?




KNS and KEW enhance developer productivity
and enforce standards
KSB provides a SOA approach for cross project
interoperability
KEN enhances the user experience while fulfilling
a general need for notification across all rice
enabled applications
Let’s take a closer look at these components
The Rice Interactive Diagram
Available at http://rice.kuali.org
 Click anywhere on the diagram to begin
 Click on any component for details

Kuali Rice as it stands Today



Version 0.9 will be released July 1, 2007
This is the version KRA will start with
Well tested




Rice is being used in KFS
Both unit and functionally tested with JUnit/HtmlUnit
Set up in Continuous Integration environment
Let's take a closer look at each of these pieces in
more detail
KSB Overview - The Goals
1.
2.
3.
4.
Enable applications and services
deployed on the bus to interact with other
applications and services
Provide (a)synchronous communication
Provide flexible security
Provide Quality of Service (QoS)
Goal 1 - General Bus Mechanics

A common registry of services
Lists all services on the bus and how they can
be connected
 Through simple configuration, most java based
services can be “exported” from a rice enabled
application, which is then ready to be
consumed by another application

Goal 1 - General Bus Mechanics cont.

A common resource loading layer that
provides access to services (bus or local)
Services can be local to the application, in
which case the bus is short circuited and
services are loaded directly and efficiently from
inside the application
 Services can be remote, in which case the
service registry is queried for a service
endpoint

Goal 1 - General Bus Mechanics cont.

Most java services inside a rice-enabled
application can be exported to a variety of
endpoints

Java serialization, SOAP, JMS, etc.
A rice-enabled application can easily
connect to any service on the bus
 Let’s take a closer look - http://ksb.kuali.org

Goal 2 - Communication Models


Synchronous communication = point to point : a
method call that waits for a response
Asynchronous communication = usually
messaging : fire and forget : possible callback



KSB has a proprietary messaging model out of the box
that needs minimal configuration
JMS can be used : Good if you have IBM or Tibco
Could plug in open source JMS when one matures
Goal 2 - Communication Models cont.

Queue and Topic style messaging
Queues are a model where a single service is
retrieved from a (possibly) redundant set of
services and only that one is invoked
 Topics are a model where all services with a
given name are retrieved from a (possibly)
redundant set of services and invoked

Goal 3 - Security
Bus Security : Option to digitally sign
internal bus communication
 Service level security : done with open
source standard project, Acegi

Can be protected at the service level
 Can be protected at the individual method level
 Can be protected by many of the standard
security models such as CAS or Kerberos
 Can act as the user performing the activity

Goal 3 - Security cont.


A “Security Context” is passed along with service
invocations
This context holds





The user logged in
The authentication token (from CAS or Kerberos)
The users roles (for Authorization)
Services can then call an authentication authority
to validate the user and optionally authorize the
user with the roles
An application gets all of this "for free" by using
the KSB via standard Acegi configuration
Goal 4 - Quality of Service (QoS)




Failover - the ability to automatically switch to
another service w/o the calling service noticing
Reliability - guaranteed delivery of messages
Availability - services on the bus are available real
time -- if service is down, reliability ensures
messages are delivered when service is available
again
Time to live and retry counts - ensure that an
institution can set their own QoS settings. If QoS
is not met messages enter exception routing.
KNS Overview
Provides reusable code, shared services
and a development strategy
 Provides a common look and feel through
screen drawing framework
 A document or transaction centric model
with workflow as a core concept

KNS Overview cont.

More Core Concepts / Features
Transactional documents
 Maintenance documents
 Inquires
 Lookups
 Rules
 Questions
 Data dictionary

Transactional Documents
These are data-entry centric documents or
“transactions” that model the business
processes
 Examples include: Proposal Development
and Protocol
 Built on a case by case basis using the
Kuali tag libraries (soon to be a part of Rice)
 Integrated with workflow

Maintenance Documents


They do not need to be build case by case - just
one JSP that draws them all
These are the CRUD documents - an easy way to
maintain support tables in a Kuali database





C: Create new business objects
R: Read or query business objects
U: Update existing business objects
D: Delete existing business objects
Examples include: budget rates and cost
elements
Inquiries

A way to drill down and get more read-only
information about a business object
Inquiry Screenshot
Inquiry Example Configuration
<inquiry>
<title>Travel Account Inquiry</title>
<inquirySections>
<inquirySection title="Travel Account">
<inquiryFields>
<field attributeName="number" forceInquiry="true" />
<field attributeName="name" />
<field attributeName="accountType" />
<field attributeName="foId" forceInquiry="true" />
</inquiryFields>
</inquirySection>
</inquirySections>
</inquiry>
Lookups
A way to search for data by a set of criteria
 Results of lookups can be returned to other
lookups or documents

Lookup Screenshot
Lookup Example
<lookup>
<title>Travel Account Lookup</title>
<menubar>
<a href="/SampleRiceClient/index.html">Main</a>
</menubar>
<instructions>Look up Inst.</instructions>
<defaultSort sortAscending="true">
<sortAttributes>
<sortAttribute attributeName="number" />
</sortAttributes>
</defaultSort>
Lookup Example cont.
<lookupFields>
<lookupField attributeName="number" required="false" />
<lookupField attributeName="name" required="false" />
<lookupField attributeName="accountType" required="false" />
<lookupField attributeName="foId" required="false"
forceLookup="true" />
</lookupFields>
<resultFields>
<field attributeName="number" forceInquiry="true" />
<field attributeName="name" forceInquiry="true" />
<field attributeName="accountType" forceInquiry="true" />
<field attributeName="foId" forceInquiry="true" />
</resultFields>
</lookup>
Rules




These are programmatic events defined in Java
Another way to think of them are as hooks in a
document lifecycle
They can return errors and stop the lifecycle until
user input is corrected
A lot have to do with the workflow lifecycle


processSaveDocument(…)
processRouteDocument(…)
Questions
A configurable way to ask a question of the
person using the Kuali application
 Example: “Are you sure you want to cancel
this operation? Yes or No”

Questions Screenshot
Data Dictionary
Configure all of the above concepts into a
“usable document”
 XML based configuration
 Three types of dictionaries

Business Object
 Maintenance Document
 Transactional Document

Data Dictionary cont.

Business Object Data Dictionary
Defines how to draw an inquiry (which fields to
show the user)
 Defines how do draw lookup and the result
fields returned from a lookup as well as the
default sort order of the lookup
 Defines the business object’s attributes as well
as how they are drawn and validated

Data Dictionary cont.

Maintenance Document Data Dictionary
Defines the BO that is being maintained
 Defines the business rules for the document
 Defines the authorizations (initiator group)
 Defines the maintainable sections (tabs) and
layout of the attributes
 And various metadata (descriptions,
summaries, titles, etc.)

Data Dictionary cont.

Transactional Document Data Dictionary
Defines the document Java bean
 Defines the business rules for the document
 Defines the document type
 Defines the document’s attributes as well as
how they are drawn and validated
 And various metadata (descriptions,
summaries, titles, etc.)

KEW Overview


Facilitates routing and approval of business
transactions (documents) throughout the
university
Provides re-usable rule creation which defines
how transactions (documents) should be routed


Bind business data to users
Provides hooks for client applications to handle
workflow lifecycle events of transactions
(documents)
KEW Overview cont.

End users interact with workflow GUIs
Doc Search: Allows users to search for
documents (transactions)
 Action List: One place to go to find all
documents that apply to you

Document Search Screenshot
Action List Screenshot
KEW Overview cont.

Route log : document history, audit trail
KEW Overview cont.

Stand-alone: a centralize hub and spoke
approach




Embedded: a decentralized, almost P2P
approach



Good if you just want to support one workflow server
Centralize Action List and Doc Search
Possibly easier to connect non-Java client
Fast for developers because workflow is local
Distributes workflow across the university
Provides distributed transactions so that workflow
and client applications stay in synch with each
other (easier in embedded)
KEN Overview

Works with the action list to provide a single place
for all university related communications



Workflow items come from KEW
Non-workflow items from KEN
Non-workflow Examples




Overdue library book
A concert on campus
Graduation checklists for seniors
A crisis on campus
KEN Overview cont.
Provides a secure and controlled
environment for notifying the masses
 Eliminate sifting through email
 Communication broker which provides any
combination of action list, text messages,
email, etc...
 Audit trail just as in KEW

KEN Overview cont.
User preferences for notification types
 End user interfaces

Viewing notification details
 Maintaining the system (admin)
 Sending messages (admin)

KEN: Sending Notifications

A developer can send notifications by:
Calling the sendNotification() service on the
KSB
 Invoking the service via a SOAP WS (exposed
by the KSB)
 Future: integration with KNS’s document
frameworks


A user can send notifications using a
provided workflow enabled form
KEN: Send Notification WS Input
KEN Screenshot: My Notifications
KEN Screenshot: Notification Details
KEN Screenshot: Notification Approval
KEN Screenshot: Delivery Type
What’s next? Looking to the future…

Coming soon
Maven2 archetype for project template
 Distributed user and group services
 Out of the box web application for management
of users, groups, and adding application
specific user attributes

The Future… cont.

Rice components will piggy back on each other


Standards






KEW and KEN will use KNS to draw screens, etc.
JSR 186/286 portlets for user interfaces (portals)
BPEL for process orchestration in workflow
JPA for data
Lots of web service interoperability specifications
Possibly easier configuration through DSL
Possibly better data mapping through JPA

More easily move away from OJB to Hibernate, EJB or
any J2EE container if that is more desirable
About the website

The main Rice Site


Rice has a sub-site for each component





http://rice.kuali.org
Nervous System
Service Bus
Workflow
Notification
http://kns.kuali.org
http://ksb.kuali.org
http://kew.kuali.org
http://ken.kuali.org
Still a work in progress

Documentation stable and finished by July 1, 2007
The Team










Brian McGough - Indiana University
Nate Johnson - Indiana University
Ryan Kirkendall - Indiana University
Eric Westfall - Indiana University
Tom Clark - Indiana University
Aaron Godert - Cornell University
John Fereira - Cornell University
Aaron Hamid - Cornell University
Scott Battaglia - Rutgers University
Dmitriy Kopylenko - Rutgers University
That’s it!

Q&A