Kuali Rice OverviewJanuary 2008

Aaron Godert - Cornell University

What is Kuali Rice? Kuali: a humble kitchen wok; Malaysian

origins Rice: it is what it is

Sits on the bottom of a dish Not a very tasty meal by itself Better with some substance on top

• KFS - Beef• KRA - Chicken• KS - Seafood

Rice is the foundation to a hearty software product

The Goals for Rice 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)

A lot of functionality in Kuali systems Keeping the Kuali code base as small as possible

without impacting quality is key Highly productive development environment

For Kuali projects For non-Kuali projects

Rice 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 Generic enough for non-Kuali applications

Rice is Middleware Made up of several, possibly

standalone and swappable, middleware components

Applications become a “Rice Client Application” by easily integrating with this middleware

Interaction with other Rice enabled applications becomes seamless

How We Got Here Kuali Enterprise Workflow (KEW) existed in

production at Indiana University Kuali Finanical System (KFS) started

development and had an architecture team Morphed into the Kuali Nervous System (KNS)

team Achieve technical consistency across all aspects

of KFS KFS --> KNS --> KEW

Along Came KRA Kuali Research Administration (KRA) needed

to integrate with KFS Align our core to support sharing services

across Kuali apps in a loosely coupled fashion

All Kuali products should be technically consistent under the hood For end user functionality For different development methodologies

Thinking Outside of the Wok Most administrative applications have

a common need for middleware services Workflow ESB Notification

Avoid design and code duplication Consolidate configuration

Rice Was Born!

Rice Modules (Products) KEW Kuali Enterprise Workflow KNS Kuali Nervous System KSB Kuali Service Bus KEN Kuali Enterprise Notification KIM Kuali Identity Management KOM Kuali Organization Management

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

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 the best talent from each of the partner institutions

Came up with a foundation on which to build KFS - the Kuali Nervous System

It focused on a unified approach to development of functionality A standard way to use workflow, perform CRUD

operations, handle business transactions KNS extracted into Rice as a module

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 to satisfy simple needs

The History of KEN Cornell University recognized the need for a

more general notification system that could work alongside of a workflow “to-do” list Started development of the notification system at

Cornell Recognized the synergy in leveraging KEW

Realized that Kuali applications also wanted an advanced model for end user communication

The concept of Kuali Enterprise Notification was born

The (short) History of KIM KFS has its own user tables that are specific

to financial data Also has groups, roles, permissions

KEW has its own users, groups, roles, permissions

When KEN was built, it piggy-backed on KEW’s users, groups, and roles

The (short) History of KIM Cont. KRA came along with similar needs as KFS KS is also gearing up and shows similar

needs with additional requirements Recognized the potential for re-use and the

need for context specific IdM data Most importantly, we recognized the need

for consistent service interfaces across projects

The concept of Kuali Identity Management was born

The (short) History of KOM KOM will address the unit

hierarchy/org chart needs of KFS/KRA/KS

Came out of functional integration committee

Why Does a Project Need Rice? KNS and KEW enhance developer productivity

and enforce standards KSB provides an SOA approach for cross

project interoperability KEN enhances the user experience while

fulfilling a general need for notification across all rice enabled applications

KIM provides consistent IdM across your projects

KOM provides consistent Org mgmt across your projects

The Rice Interactive Diagram

Available at http://rice.kuali.org Click anywhere on the diagram to

begin Click on any component for details

Rice Deployment Architectures Stand-alone: a central hub and spoke model

Good if you just want to support one Rice server Centralized services and features Best for non-Java clients

Embedded: a decentralized, federated approach Fast for developers because services are local Distributes load; technically a clustered model Provides distributed transactions (via JTA)

Hybrid: best of both

Kuali Rice - Current Status Public release 0.9.1 available at

http://rice.kuali.org --> Download KRA is using 0.9.2 KFS is using 0.9.2 Well tested

Rice is being used in KFS; released with KFS 2.0 Both unit and functionally tested with JUnit/HtmlUnit Continuous Integration:

https://test.kuali.org/bamboo Let's take a closer look at each of these pieces

in more detail

KSB Overview - The Goals1. Enable applications and services

deployed on the bus to interact with other applications and services

2. Provide (a)synchronous communication

3. Provide flexible security4. Provide Quality of Service (QoS)5. Keep it simple (light weight)

KSB Overview Cont. A common registry of services

Lists all services on the bus and how they can be connected

Through simple Spring configuration, Java based services can be “exported” from a rice enabled application as SOAP or HttpRemoted services

Common resource loading - access services remotely or locally

Other “Rice Clients” can connect to any of the services on the KSB

KSB Communication Models Synchronous = P2P : waits for a response Asynchronous = messaging : fire and

forget : possible callback Queues = single service retrieved from

redundant set of services; only one invoked

Topics = all services retrieved from redundant set of services; all invoked

KSB Security Bus level : option to digitally sign,

encrypt Service level security through Acegi

Service level, method level User proxying through standard security

models (i.e. CAS, Kerberos) Security context passed along (user, authn

token, roles) Services can call authn/authz authority to

validate context

KSB is Simple and Light Weight Evaluated ServiceMix, ActiveMQ, Mule a year

and a half ago Reliability issues then, better now though

For simple needs (SOAP and Spring HttpRemoting), the messaging components of KEW sufficed in combination with XFire and Spring

Kuali Student has greater needs from an ESB (WSDL first, process orchestration, etc)

Are looking to KS ESB team for the direction to go

KNS Overview Provides reusable code, shared

services, integration layer, and a development strategy

Provides a common look and feel through screen drawing framework

A document (business process) centric model with workflow as a core concept

Understanding the KNS Paradigm

CHART_TChart

(POJO)

ORMMappin

g

Data Dictionary

Lookups and

Inquiries

MaintenanceDocuments

TransactionalDocuments

Workflow(KEW)

Transactional Documents These are data-entry centric documents or

“transactions” that model the business processes Examples include: Proposal Development, Journal

Entry, Payment Reimbursement Built on a case by case basis using the Kuali Rice

tag libraries (encompass snippets of UI behavior): Notes and attachments Workflow route log (audit log)

Integrated with workflow

Maintenance Documents They do not need to be built 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 table records R: Read or query table records U: Update existing table records D: Delete existing table records

Examples include: Budget rates Project codes

Inquiries A way to drill down and get more

read-only information about a table record

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> <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>

Other KNS Features Data Dictionary Question component Notes and attachments Pluggable business rules Pluggable authorizations System parameters Extended/custom attributes

KEW Overview Facilitates routing and approval of business

processes throughout an organization Provides re-usable routing rule creation which

defines how business processes should be routed Bind business data to users/groups that must approve

Provides hooks for client applications to handle workflow lifecycle events of business processes

End users interact with central workflow GUIs for all client applications

Document Search Screen Shot

Action List Screen Shot

Route Log Screen Shot

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 example items Overdue library book A concert on campus Graduation checklists for seniors

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. Controlled by user preferences

Audit trail for all messages just as in KEW

KEN: Sending Notifications S2S: A developer can send

notifications by: Calling the sendNotification() service on

the KSB Invoking the service via a SOAP WS

(exposed by the KSB) Manual: A user can send notifications

using a provided workflow enabled form

KEN Screenshot: My Notifications

KEN Screenshot: Notification Details

KIM Overview Just gearing up Keep it simple to start Goals:

Clean and consistent service interfaces used by all Kuali apps; generic enough for non-Kuali apps

Leverage KNS to provide a reference implementation for services; workflow enabled management application

Flexibility for dynamic attributes associated with IdM entities (persons, groups, roles, etc)

Pluggable support for Internet2 products (Grouper, etc)

KIM Overview Cont. Basic concepts

Namespace (i.e. Application, any generic context)

Person - different default “sponsored” attributes for each namespace context; core shared attributes as well

Group - simply groups users; arbitrary data associated with them

KIM Overview Cont. Permissions - ability to perform actions Roles - cross context capabilities;

aggregates permissions (i.e. fiscal officer, dean, etc)

Qualified Roles - specific to a context• fiscal officer for organization XYZ• dean for the College of ABC• administrators for the College of ABC <-- this

one’s a group

KOM Overview Basic concepts

Namespace - scopes the trees Organization - XYZ Department, College

of ABC, University of EFG Organization Category - University,

College, Department, Club, etc Parent/Child Organization

What’s Next? Looking to the Future… Rice components will piggy back on each other

KEW and KEN will use KNS to draw screens, etc. Standards

JSR 186/286 portlets for user interfaces (portals) BPEL for process orchestration JPA for data persistence (move to Hibernate) WS-* support

Easier configuration and turnkey upgrades Light weight service interfaces (WSDL, XSD) Open source ESB foundation for KSB

The main Rice web site http://rice.kuali.org Sign up for our public mailing list Access to our wiki: roadmap, project

plans, documentation, etc Documentation is a weakness

About the website

That’s it!

Q & A