1 / 55

Kuali Rice Overview January 2008 Aaron Godert - Cornell University

Kuali Rice Overview January 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

gisela-fields
Download Presentation

Kuali Rice Overview January 2008 Aaron Godert - Cornell University

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Kuali Rice Overview January 2008 Aaron Godert - Cornell University

  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

  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

  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

  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

  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

  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

  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

  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)

  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

  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

  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

  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

  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

  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

  19. The Rice Interactive Diagram • Available at http://rice.kuali.org • Click anywhere on the diagram to begin • Click on any component for details

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

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

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

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

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

  28. Understanding the KNS Paradigm CHART_T Chart(POJO) Data Dictionary ORMMapping Lookups and Inquiries MaintenanceDocuments TransactionalDocuments Workflow(KEW)

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

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

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

  32. Inquiry Screenshot

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

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

  35. Lookup Screenshot

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

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

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

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

  40. Document Search Screen Shot

  41. Action List Screen Shot

  42. Route Log Screen Shot

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

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

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

  46. KEN Screenshot: My Notifications

  47. KEN Screenshot: Notification Details

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

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

More Related