1. Kuali Rice Overview April 2008 Aaron Godert
© 2008 Aaron Godert. Creative Commons Attribution 3.0 Unported License (

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

3. 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 inherited goals from board for good reason
Rice needs to support this suite with a consistent and cohesive foundation
Certainly a lot of functionality in the Kuali systems and Rice needs to do it’s part to eliminate redundant code; get a lot of re-use, and while keeping the code base as small as possilbe w/out sacrificing quality
Rice should provide a highly productive development environment - solves common architectural problems - both Kuali and non-Kuali apps

4. 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
1.) Expanding on the last point…
a.) switching from project to project; KRA dev knows how to implement KFS
2.) Generic enough - institutional needs outside of Kuali

5. 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
1.) middleware components - workflow, notification, service bus, ADF… talk about later
2.) leveraging rice and it’s services - deems your app as a “rice client”
3.) Interaction - services in KFS can be called easily by KRA; all rice clients share a single workflow component (re-use of routing rules, action list, etc)

6. 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
1.) KEW at IU - HR, etc - called Eden Workflow, then OneStart Workflow
2.) KFS discussions: mid-to-late 2004; IU ideas before that; actual partners joined in early 2004 and started work
architecture team for about 2-3 months; then development started
3.) In the early days of KFS, we had KFS using KNS using OneStart (renamed to KEW at some point)

7. 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
1.) KRA idea a little more than a year ago - maybe a bit earlier; knew it was going to happen maybe about a year ago, few months after that, we recognized the need to re-use a lot of the good stuff we built for KFS
2.) KRA and KFS needed to access services in eachother
3.) circle back around to board and architecture team - consistency
A suite of admin apps with technical consistency under the hood (what a novel idea)
- UI - end user
Various development practices existed and we wanted some consistency there too; patterns in Rice could help to ensure consistent practices; metrics for better planning

8. 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
1.) Mentioned “non-Kuali” apps before
2.) Thinking “Hey, what we’ve got in KNS is general enough that it can be a should be taken the few extra steps to allow for non-Kuali app development too.”

9. Rice Was Born!

10. 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
1.) Time to learn some acronyms
2.) Represents all of the products
KEW - central workflow configuration for business applications; re-usable routing rules, single “action list”
KNS - ADF integration layer - allows for easy integration with other “service” products in Rice - standard application patterns for quick integration
KSB - sharing services between applications in an SOA fashion; remote, local, discovery
KEN - communication broker integrating with KEW action list for communication with end users; preferences for delivery of messages
KIM - common IdM services and maintenance of entities used by those services - person, groups, roles, permissions, etc

11. 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)
Title : Often pronounced as the English letter Q.
1) Projects that have used workflow at IU include human resources, purchasing, time keeping, research, and more.
2) We wanted to move away from paper based approaches
3) Every department, every school and dean, had a different way to do things, so the engine needed to be flexible
enough to accommodate for this

12. 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
1.) months up front; people (ninjas); many from architecture group
2.) Used concrete use cases and requirements from IU’s FIS system to build the re-usable KNS component

13. 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
KRA not only wanted the good features of the KNS, but also to leverage services in KFS without need for old-school batch feeds

14. 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
One place to get all enterprise / university wide messages -- guaranteed.

15. 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
1.) Really new we needed this a while ago; but never really acted on it
2.) One day over the summer, we were kind of like, we need to just do this b/c it’s needed by everyone

16. 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
In fact, will probably be the most consistently leveraged Rice module

17. The (short) History of KOM
KOM will address the unit hierarchy/org chart needs of KFS/KRA/KS
Came out of functional integration committee

18. 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
4) Now that we’ve seen where the components originated from…

19. The Rice Interactive Diagram
Available at
Click anywhere on the diagram to begin
Click on any component for details
Gives a feel for how different applications can be rice-enabled
* Makes applications available on the bus -- Can be java apps, Kuali apps, or even legacy apps
* Allows applications to discover common services on the bus (Identity Management, Workflow, Notification, other Kuali applications)
* Use components like the KNS for common look and feel
* Connect a single web service that has nothing to do with Kuali yet provides a useful service at your institution

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

21. Kuali Rice - Current Status
Public release available at --> Download
KRA is using 0.9.3
KFS 2.2 release using
Active development is 0.9.3
Well tested
Rice is being used in KFS; released with KFS 2.2
Both unit (JUnit) and functionally tested
Continuous Integration
Let's take a closer look at each of these pieces in more detail

22. KSB Overview - The Goals
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)
Keep it simple (light weight)

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

24. Explain
- Connectors : Allows any application, not just Kuali apps, to connect to the bus for services
- Exporters : An easy way for rice-enabled apps to put services on the bus
- Bridges : A way for non-Kuali services to use the KSB to export their services and get the QoS provided by KSB
Mention
- Security : Hit key points. More details in a few slides
- Transformation : messages can be changed on the way in and on the way out of the bus. This makes
it so that all types of message can play.
- Backbone : more to come

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

26. 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
1) Example: KRA asks for service A from the KSB. Service A need to talk to Service B and C.
A talking to B and C can optionally use bus security to ensure authentication. Authorization
is then up to the services.

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

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

29. Understanding the KNS Paradigm
CHART_T
Chart (POJO)
Data Dictionary
ORM Mapping
Lookups and Inquiries
Maintenance Documents
Transactional Documents
Workflow (KEW)

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

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

32. Inquiries
A way to drill down and get more read-only information about a table record

33. Inquiry Screenshot

34. Inquiry Example Configuration
<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>

35. Lookups A way to search for data by a set of criteria
Results of lookups can be returned to other lookups or documents

36. Lookup Screenshot

37. Lookup Example <lookup>
<title>Travel Account Lookup</title>
<instructions>Look up Inst.</instructions>
<defaultSort sortAscending="true">
<sortAttributes>
<sortAttribute attributeName="number" />
</sortAttributes>
</defaultSort>

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

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

40. 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
2a) Only a fiscal officer is allowed to approve certain documents
fiscal office is just a user that in that role, and a rule is just a criteria
that checks if the user matches FO

41. Document Search Screen Shot

42. Action List Screen Shot

43. Route Log Screen Shot

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

45. KEN Overview Cont.
Provides a secure and controlled environment for notifying the masses
Eliminate sifting through
Communication broker which provides any combination of action list, text messages, , etc.
Controlled by user preferences
Audit trail for all messages just as in KEW

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

47. KEN Screenshot: My Notifications

48. KEN Screenshot: Notification Details

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

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

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

52. KOM Overview Basic concepts Context - scopes the trees
Organization - XYZ Department, College of ABC, University of EFG
Organization Category - University, College, Department, Club, etc
Parent/Child Organization

53. 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 upgrades
Light weight service interfaces (WSDL, XSD)
Open source ESB foundation for KSB
#1 PRIORITY - supporting other Kuali apps

54. About the website The main Rice web site Documentation is a weakness
Sign up for our public mailing list
Access to our wiki: roadmap, project plans, documentation, etc
Documentation is a weakness
The documentation and downloads will be in place by July 1, 2007.

55. That’s it!
Q & A