Kuali Rice

Evolving the Technology Framework for Kuali

Applications

Brian McGough (Indiana University)Aaron Godert (Cornell University)

Warner Onstine (University of Arizona)

Why Evolve?

• Realign technical strategy to match evolved board vision for Kuali– Started as a (KFS) Kuali Financial System– Evolved to a umbrella suite of

administrative higher education systems

• Facilitate a common architecture that can be used for future Kuali applications

• IT industry advances and standards for SOA based architectures

The Goals

• Enable the technology infrastructure investment that was made for the Financial system to be leveraged by other Kuali sister projects

• Use a common development framework to gain productivity and consistency across Kuali projects

The Goals

• Common underlying infrastructure in other Kuali modules will allow for easier adoption of new modules as they are developed

• Create a reusable development environment that could be adopted as a general approach to systems development and systems integration at an institution

Kuali Rice

• There are several middleware subcomponents that make up Rice

• This diagram represents the core infrastructure components that represent Rice

• The next slide shows the role that Rice components play in applications

Kuali Rice

• As shown in the previous diagram, Rice is made up of several reusable pieces of middleware

• A Rice enabled application will make use of the Rice Client to gain access to Rice middleware functionality

• Using the Rice Client in a Kuali Development project, development and integration with other Rice enabled applications and services comes for free

How we got here• Several key factors have influenced the

evolution of our frameworks– The need for multiple separate applications

to be able to be loosely connected– The need for multiple separate applications

to exist under the Kuali umbrella of products– Most administrative applications have

common needs for middleware– Providing a solid base upon which to build

our systems will allow us to avoid duplication of effort across projects

How we got here

• Some History:– Workflow (KEW) existed as a standalone

integration oriented project at IU before Kuali began

– Workflow enabled many disparate applications to be able to all use a common workflow engine to drive business processes electronically through the University

– Workflow provides a relatively simple API, but leaves many choices about how to implement workflow in the hands of developers

How we got here

• History Continued:– To come up with a unified approach to

using workflow, writing transactions in Kuali Systems, and other commonly needed application components the (KNS) Kuali Nervous System was born

– The KNS abstracted a lot of the complexity of how to develop functionality in KFS and provided a large set of reusable code to enforce consistency and to assist productivity within the KFS project

How we got here• Present thoughts and futures:

– Having KNS as an asset that was built for KFS allowed for good productivity and standards enforcement…but only within KFS

– So in order to extend into a multi-application platform some additional pieces were required

– This is where the KSB (Kuali Service Bus) comes into the picture

– The KSB will allow for cross application messaging and service invocation among disperate Kuali Rice enabled applications

How we got here

• Present thoughts and futures continued:– The KSB will provide the functionality needed

to facilitate real-time integration of services and applications

• Reducing the need for batch types of integration• Increasing our business process agility

– The KSB will facilitate better application to service and service to service integration

– We also wanted to increase the ability for Kuali systems to interact in an advanced way with people and this is how the KEN (Kuali Enterprise Notification) component concept arrived

How we got here

• Present thoughts and futures continued:– Using KEN we will be able to leverage

other core infrastructure of Kuali to deliver a unified communications system with our users from all different kinds of applications

– KEN will allow users to define how they like to receive communications

How we got here

• Futures– Looking ahead the components of Rice will

allow for enhancements in the ways that our business processes are carried out without having to look at rewriting a bunch of systems

– Adoption of technology standards for components of Rice is a primary concern going forward: BPEL, JSRs, Portals, etc; to allow for interoperation with other standards compliant products and services in our environments

Rice Subcomponents

• The KSB will enable applications and services deployed on the bus to interact with other applications and services deployed on the bus

• The KSB will also enable web service invocation for services that should be exposed

• Allows for synchronous and asynchronous communications between applications and services

KSB (Kuali Service Bus)

Rice Subcomponents

• Provides reusable code, shared services, and strategy for development

• Documents (processes) and workflow integration– Maintenance– Transactional

• Data Dictionary• Lookups• Inquiries• Rules• Approaches to solving common development tasks

KNS (Kuali Nervous System)

Rice Subcomponents

• Facilitates the routing and approval of transactions through the University

• Allows for rules to be created for how transactions should be approved

• Provides hooks for client applications to handle workflow lifecycle events for transactions

• Provides common document (process) search function and common Action List function that span across different applications and will integrate with KEN

KEW (Kuali Enterprise Workflow)

Rice Subcomponents

• Provide a single list for all university related communications– Workflow items (KEW)– Non-workflow items (KEN)

• Examples of non-workflow items:– Your book is overdue– A concert is coming up on campus– Graduation check list to all Seniors

KEN (Kuali Enterprise Notification)

Rice SubcomponentsKEN (Kuali Enterprise Notification)

Rice Subcomponents

• Eliminate sifting through email• Quickly find what you need, to go about your

university related business• Provide a controlled environment

– Eliminate unwanted messages– Integrated user and group management

• Audit trail• Centralize communication broker• More robust preference capabilities

KEN (Kuali Enterprise Notification)

Rice Subcomponents

• Integration with KEW:– Action list– Audit trail (logging)– User and groups

• Services exposed on KSB for direct consumption (HTTP Remoting)

• Services exposed as web services via KSB’s generic web services mechanism

• Out-of-the-box integration with KEW• Out-of-the-box web app for viewing notification details,

maintaining the system, sending messages (generic form)• Future portlets for portal integration (any JSR168 portal)

KEN (Kuali Enterprise Notification)

Frameworks and Methodology

• Kuali has chosen to Adopt common approaches to development problems

• This in turn has led to our adoption of certain general components required by our software distributions

• By building and adopting certain frameworks, some of the methodology of development decisions are simplified

Conclusion• Evolving the technology framework for

Kuali will create some interesting possibilities for future Kuali projects

• The focus of the evolution to enable rapid project development in a common way for Kuali projects

• Better business process agility for our systems through real time integration and support for defining and evolving workflow processes and messaging practices