Kuali Rice OverviewApril 2008April 2008

Aaron Godert

© 2008 Aaron Godert. Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3

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

Sits on the bottom of a dishNot a very tasty meal by itselfNot a very tasty meal by itselfBetter with some substance on top

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

Rice is the foundation to a hearty software product

The Goals for RiceThe board vision for Kuali is a plug and play module by module approach to softwareKuali started as financials, but has evolved into a suite of administrative software (KFS KRA KS)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 environmentFor Kuali projectsFor non-Kuali projects

Rice Goals Cont.A common and consistent architecture

Allow developers to understand other rice enabled projectsI f t t ld t d t b i t dInfrastructure 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 suiteAdoption of other Kuali modules feasible

Generic enough for non-Kuali applications

Rice is MiddlewareMade up of several, possibly standalone and swappable, middleware componentsApplications become a “Rice Client ppApplication” by easily integrating with this middlewareInteraction with other Rice enabled applications becomes seamless

How We Got HereKuali Enterprise Workflow (KEW) existed in production at Indiana UniversityKuali Finanical System (KFS) started d l t d h d hit t tdevelopment and had an architecture team

Morphed into the Kuali Nervous System (KNS) teamAchieve technical consistency across all aspects of KFS

KFS --> KNS --> KEW

Along Came KRAKuali Research Administration (KRA) needed to integrate with KFSAlign our core to support sharing services across K li i l l l d f hiKuali apps in a loosely coupled fashionAll Kuali products should be technically consistent under the hood

For end user functionalityFor different development methodologies

Thinking Outside of the WokMost administrative applications have a common need for middleware services

WorkflowESBNotification

Avoid design and code duplicationConsolidate configuration

Rice Was Born!

Rice Modules (Products)KEW Kuali Enterprise WorkflowKNS Kuali Nervous SystemKSB Kuali Service BusKEN K li E t i N tifi tiKEN Kuali Enterprise NotificationKIM Kuali Identity ManagementKOM 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 KEWKuali Enterprise Workflow existed at Indiana University as a stand alone integration project before Kuali beganProvided common engine to drive business processes electronicallyWhen Kuali came along, the IU workflow engine became Kuali Enterprise Workflow (KEW)

The History of KNSKFS spent a large amount of development time up front, using the best talent from each of the partner institutionsCame up with a foundation on which to build KFSCame up with a foundation on which to build KFS - the Kuali Nervous SystemIt 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 KSBOther Kuali projects came along: i.e. KRAThey needed to be able to seamlessly “talk” to other Kuali services/applications in real pptime

Reducing the need for offline batchIncreasing business process agility

The KSB was born to satisfy simple needs

The History of KENCornell 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 atStarted development of the notification system at CornellRecognized the synergy in leveraging KEW

Realized that Kuali applications also wanted an advanced model for end user communicationThe concept of Kuali Enterprise Notification was born

The (short) History of KIMKFS has its own user tables that are specific to financial data

Also has groups, roles, permissionsKEW has its own users groups rolesKEW has its own users, groups, roles, permissionsWhen 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 KFSKS is also gearing up and shows similar needs with additional requirementsRecognized the potential for re use and the needRecognized the potential for re-use and the need for context specific IdM dataMost importantly, we recognized the need for consistent service interfaces across projectsThe concept of Kuali Identity Management was born

The (short) History of KOMKOM will address the unit hierarchy/org chart needs of KFS/KRA/KSCame out of functional integration gcommittee

Why Does a Project Need Rice?KNS and KEW enhance developer productivity and enforce standardsKSB provides an SOA approach for cross project interoperabilityinteroperabilityKEN enhances the user experience while fulfilling a general need for notification across all rice enabled applicationsKIM provides consistent IdM across your projectsKOM provides consistent Org mgmt across your projects

The Rice Interactive Diagram

Available at http://rice.kuali.orgClick anywhere on the diagram to beginClick anywhere on the diagram to beginClick on any component for details

Rice Deployment ArchitecturesStand-alone: a central hub and spoke model

Good if you just want to support one Rice serverCentralized services and featuresBest for non-Java clientsBest for non Java clients

Embedded: a decentralized, federated approachFast for developers because services are localDistributes load; technically a clustered model Provides distributed transactions (via JTA)

Hybrid: best of both

Kuali Rice - Current StatusPublic release 0.9.2 available at http://rice.kuali.org --> DownloadKRA is using 0.9.3KFS 2 2 release using 0 9 2 1KFS 2.2 release using 0.9.2.1Active development is 0.9.3Well tested

Rice is being used in KFS; released with KFS 2.2Both unit (JUnit) and functionally testedContinuous Integration

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 communication3. 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 connectedThrough simple Spring configuration, Java based g p p g g ,services can be “exported” from a rice enabled application as SOAP or HttpRemoted services

Common resource loading - access services remotely or locallyOther “Rice Clients” can connect to any of the services on the KSB

KSB Communication ModelsSynchronous = P2P : waits for a responseAsynchronous = messaging : fire and forget : possible callbackpQueues = single service retrieved from redundant set of services; only one invokedTopics = all services retrieved from redundant set of services; all invoked

KSB SecurityBus level : option to digitally sign, encrypt Service level security through Acegi

Service level, method levelUser proxying through standard security models (i.e. CAS, Kerberos)Security context passed along (user, authntoken, roles)Services can call authn/authz authority to validate context

KSB is Simple and Light WeightEvaluated ServiceMix, ActiveMQ, Mule a year and a half ago

Reliability issues then, better now thoughFor simple needs (SOAP and SpringFor simple needs (SOAP and Spring HttpRemoting), the messaging components of KEW sufficed in combination with XFire and SpringKuali Student has greater needs from an ESB (WSDL first, process orchestration, etc)Are looking to KS ESB team for the direction to go

KNS OverviewProvides reusable code, shared services, integration layer, and a development strategyProvides a common look and feel through screen drawing frameworkA document (business process) centric model with workflow as a core concept

Understanding the KNS Paradigm

CHART_TChart

(POJO)ORM

Mapping

Data Dictionary

Lookups and

Inquiries

MaintenanceDocuments

TransactionalDocuments

Workflow(KEW)

Transactional DocumentsThese are data-entry centric documents or “transactions” that model the business processesExamples include: Proposal Development, J l E t P t R i b tJournal Entry, Payment ReimbursementBuilt on a case by case basis using the Kuali Rice tag libraries (encompass snippets of UI behavior):

Notes and attachmentsWorkflow route log (audit log)

Integrated with workflow

Maintenance DocumentsThey do not need to be built case by case - just one JSP that draws them allThese are the CRUD documents - an easy way to maintain support tables in a Kuali databasemaintain support tables in a Kuali databaseC: Create new table recordsR: Read or query table recordsU: Update existing table recordsD: Delete existing table records

Examples include: Budget ratesProject codes

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

LookupsA way to search for data by a set of criteriaResults of lookups can be returned to other lookups or documentsp

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" p q

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 FeaturesData DictionaryQuestion componentNotes and attachmentsNotes and attachmentsPluggable business rulesPluggable authorizationsSystem parametersExtended/custom attributes

KEW OverviewFacilitates routing and approval of business processes throughout an organizationProvides re-usable routing rule creation which d fi h b i h ld b t ddefines how business processes should be routed

Bind business data to users/groups that must approveProvides hooks for client applications to handle workflow lifecycle events of business processesEnd users interact with central workflow GUIs for all client applications

Document Search Screen Shot

Action List Screen Shot

Route Log Screen Shot

KEN OverviewWorks with the action list to provide a single place for all university related communications

Workflow items come from KEWN kfl it f KENNon-workflow items from KEN

Non-workflow example itemsOverdue library bookA concert on campusGraduation checklists for seniors

KEN Overview Cont.Provides a secure and controlled environment for notifying the massesEliminate sifting through emailCommunication broker which provides any combination of action list, text messages, email, etc.

Controlled by user preferencesAudit trail for all messages just as in KEW

KEN: Sending NotificationsS2S: A developer can send notifications by:

Calling the sendNotification() service on the KSBInvoking 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 OverviewJust gearing upKeep it simple to startGoals:

Cl d i t t i i t f d b llClean and consistent service interfaces used by all Kuali apps; generic enough for non-Kuali appsLeverage KNS to provide a reference implementation for services; workflow enabled management applicationFlexibility 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 wellGroup - simply groups users; arbitrary data associated with them

KIM Overview Cont.Permissions - ability to perform actionsRoles - 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 OverviewBasic concepts

Context - scopes the treesOrganization - XYZ Department, College of g p , gABC, University of EFGOrganization Category - University, College, Department, Club, etcParent/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

JPA for data persistence (move to Hibernate)Easier configuration and turnkey upgradesLight weight service interfaces (WSDL, XSD)Open source ESB foundation for KSB

The main Rice web sitehttp://rice.kuali.orgSign up for our public mailing list

About the website

g p p gAccess to our wiki: roadmap, project plans, documentation, etc

Documentation is a weakness

That’s it!

Q & A