Kuali Rice: Cross Project Middleware

Nate Johnson - Indiana University

November 17, 2007

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 - veggies & tofu• KRA - chicken• KS - seafood

• Rice is the foundation to a hearty software product

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)

• 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

Goals Continued

• 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 Financial 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 Components

• KEW Kuali Enterprise Workflow• KNS Kuali Nervous System• KSB Kuali Service Bus• KEN Kuali Enterprise Notification• KIM Kuali Identity 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

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

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

This History of KNS Cont.

• It focused on a unified approach to development of functionality– A standard way to use workflow– A standard way to maintain support tables

using CRUD operations– A standard way of creating business

transactions• KFS financial transactions

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

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

• 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 - Current Status

• Public beta version 0.9.0.3 available at http://rice.kuali.org --> Download

• KRA is using 0.9.2• KFS is using 0.9.0.4• Well tested

– Rice is being used in KFS; soon to be 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 Goals

1. Enable applications and services deployed on the bus to interact with other applications and services

2. Provide (a)synchronous communication

3. Provide flexible security

4. Provide Quality of Service (QoS)

5. Keep it simple (light weight)

Goal 1 - General Bus Mechanics

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

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 logged in user– The authentication token (from CAS or Kerberos) – The user’s 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 status

Goal 5 - Simple and Light Weight

• Evaluated ServiceMix, ActiveMQ, and 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 replace the core of KSB with an OS ESB and JMS solution

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

KNS Overview Cont.

• More Core Concepts / Features– Transactional documents– Maintenance documents– Inquires– Lookups– Rules– Questions– Data dictionary

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” /> <field attributeName="name" /> <field attributeName="accountType" /> <field attributeName="foId" /> </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

business process’s 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– References the BO DD file 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– References the document POJO– Defines the pluggable business rules– Defines the document type (business process)– Defines the document’s attributes as well as how they

are drawn and validated– Defines the pluggable authorizations– And various metadata (descriptions, summaries,

titles, etc.)

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

KEW Overview Cont.

• End users interact with central workflow GUIs for all client applications– Document Search: Allows users to search for

documents (business process transactions)– Action List: One place to go to find all

documents that you must take action on

Document Search Screenshot

Action List Screenshot

KEW Overview cont.

• Route log : document history, audit trail

KEW Architecture

• Stand-alone: a central hub and spoke model– Good if you just want to support one workflow server– Centralize Action List and Doc Search– Possibly easier to connect non-Java client

• Embedded: a decentralized, federated approach– 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 (embedded uses JTA)

• Services reachable via the KSB

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

• 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 Screenshot: My Notifications

KEN Screenshot: Notification Details

KEN Screenshot: Notification Approval

KEN Screenshot: Delivery Type

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 chart XYZ• dean for the College of ABC• administrators for the College of ABC <-- this one’s

a group

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

The Team• Current Contributors

– Brian McGough - Indiana University– Aaron Godert - Cornell University– Nate Johnson - Indiana University– Ryan Kirkendall - Indiana University– Eric Westfall - Indiana University– David Elyea - Indiana University– Aaron Hamid - Cornell University– Chi-Thanh Dang - University of Arizona– Phillip Berres - University of Southern California– Tom Clark - Indiana University

• Past Contributors– John Fereira - Cornell University– Scott Battaglia - Rutgers University

That’s it!

• Q & A