Kuali Rice Technical Overview February 2011

Components of Rice  KEWKuali Enterprise Workflow  KNSKuali Nervous System  KRADKuali Rapid Application Development (KRAD replaces KNS)  KSBKuali Service Bus  KIM Kuali Identity Management  KRMSKuali Rules Management System  KENKuali Enterprise Notification (KEN is a rarely used component)

 UI:: Provides UI Framework – KNS/KRAD  Services:: Provides key middleware Services for Identity Management (KIM), Enterprise Workflow (KEW), Rules Management System (KRMS), Organization Management (future)  Service Bus:: Provides Enterprise Service Bus (KSB) on which KS Services are hosted Role of Rice Middleware

Rice Architecture

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

Component: KSB

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

 A lightweight service bus  Typically, KSB programming is centered on exposing Spring-configured beans to other calling code using a number of different protocols.  You deploy services to the bus either using the Spring tool or programmatically  Services must be named when they are deployed to the bus  Services are acquired from the bus using their name KSB Highlights

KSB Architecture

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

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

Component: KNS/KRAD

KNS/KRAD Overview  KNS/KRAD provides a toolkit with which to build the User Interface (UI) and connect it to Services  Contains UI guidelines for a common look and feel  Provides out-of-the-box ways to workflow enable the information processed by the UI (“document” is a commonly used term for workflow enabled forms)

KNS/KRAD 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

KNS/KRAD 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

KNS Architecture CHART_T Chart (POJO) ORM Mappin g Data Dictionary Lookups and Inquiries Maintenance Documents Transactional Documents Workflow (KEW)

KRAD Architecture

KRAD Technology Spring MVC Spring Beans and Expression Language Apache Tiles as the templating engine Fluid Skinning System for CSS jQuery as the javascript library Including jQuery UI And other plugins providing functionality like AJAX More information about Rice KRAD at Release+Documentation Release+Documentation

KNS/KRAD Feature: Inquiries  A way to drill down and get more read-only information about a table record

Inquiry Example Configuration Travel Account Inquiry

KNS/KRAD Feature: Lookups  A way to search for data by a set of criteria  Results of lookups can be returned to other lookups or documents

Lookup Example Travel Account Lookup Look up Inst.

Lookup Example Cont. <lookupField attributeName="foId" required="false" forceLookup="true" />

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

KRAD Screenshots KNS Look and Feel - KS Look and Feel - See lots of other examples by going to the “Kitchen Sink” at Log in as “admin” user

Component: KEW

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

 Content-based routing engine (“workflow”)  Flow  User creates a document from a process definition  User submits it to the workflow engine  Engine makes routing decisions based on the XML content of the document  KEW is a set of services, APIs, and GUIs with these features:  Action List for each user, also known as a user’s work list  Document searching  Route log: Document audit trail  Flexible process definition: Splits, joins, parallel branches, sub-processes, dynamic process generation  Rules engine  notification  Notes and attachments  Wide array of pluggable components to customize routing and other pieces of the system  eDocLite: Framework for creating simple documents quickly  Plugin architecture: Packaging and deployment of application plugins or deployment of routing components to the Rice standalone server at runtime KEW Highlights

Document Search Screen Shot

Action List Screen Shot

Route Log Screen Shot

Component: KIM

KIM Overview  Kuali Identity Management is a misnomer  KIM does not manage identity  Instead it sits between a Identity Management System (IdMS) and your application to provide security related functions to your application  Authentication  Authorization  It abstracts the proprietary nature of any IdMS and provides a Kuali Standard interface to IdMS

 Provides identity and access management services  KIM services are available on the service bus with both SOAP and Java serialization endpoints  Provides a set of GUIs that you can use to maintain identity information  Provides reference implementation of Identity related Services  Read-only services:  IdentityService  GroupService  PermissionService  RoleService  ResponsibilityService  AuthenticationService  Update services that allow write operations  A permission service that evaluates permissions: KIM provides plug points for implementing custom logic for permission checking, such as permission checks based on hierarchical data. KIM Highlights

KIM Architecture

KIM Concepts 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  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

Component: KRMS

 KRMS is a general-purpose business rules engine  Supports the management and execution of business rules needed for business processes  Used to define a set of rules within a particular business unit or for a particular set of applications. These business rules test for certain conditions and define the set of actions that result when conditions are met. KRMS enables you to call and use this logic from any application, without having to re-write and manage all the rules' logic within the application.  Example, you can define a rule to specify that when an account is closed, a continuation account must be specified. You can also define rules to manage your organizational hierarchies and internal structures. You can define compound rule logic, for example, "Must meet":  P credits of FirstYearScience (CLU set)  AND  P2 - Completed CALC101 with grade >= B+  AND  p3 - Average of B+ on last 12 credits KRMS

Rice 2.0 Documentation  rc2/reference/html/Intro_To_Rice.html#d967e295 rc2/reference/html/Intro_To_Rice.html#d967e295 Kuali Days 2011 Presentations  1+presentations 1+presentations Rice More Information