Kuali Rice: Cross Project MiddlewareNovember ???, 2007
Nate Johnson - Indiana 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 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 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 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 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)
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, 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" 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 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 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
The Team Current Contributors
Brian McGough - Indiana University Aaron Godert - Cornell University Eric Westfall - Indiana University Ryan Kirkendall - Indiana University Nate Johnson - Indiana University Aaron Hamid - Cornell University David Elyea - Indiana 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