Kuali Rice Evolving the Infrastructure for Kuali Applications Brian McGough (Indiana University)...

Kuali Rice

Evolving the Infrastructure for Kuali Applications

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

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 project, development and integration with other Rice enabled applications and services comes for free

How we got hereGeneral Needs:

• Multiple separate applications need to be loosely connected

• Want technical consistency across Kuali products

• Administrative applications have common needs for middleware

• Avoid duplication• Consolidate configuration

How we got here• Kuali Enterprise Workflow (KEW) History:

– KEW existed at Indiana University before Kuali began (wasn’t called KEW at that time)

– Provided a common workflow engine to drive business processes electronically through the University

– Workflow provided a relatively simple API• Left a lot of choices about how to implement workflow in

the hands of developers– Kuali Financials (KFS) came along, and used

Workflow• Workflow became KEW

How we got hereKuali Nervous System (KNS) History:

• The first development effort on Kuali Financials (KFS) was to build a core foundation to support the functional patterns

• The Kuali Nervous System (KNS) was born• Unified approach to:

• Using workflow• Add/update/delete of reference tables• Posting financial transactions (KFS specific)

• The KNS abstracted a lot of the complexity of how to develop functionality in KFS

• Provided a large set of reusable code to enforce consistency and to assist productivity within the KFS project

How we got hereKuali Service Bus (KSB) History:

• Kuali Research Administration (KRA) came along• Need KRA to work with KFS in an independent

and modular fashion• Needed a way for systems to “talk” to each other

and re-use services in a loose fashion• KSB was born• Facilitate real-time integration of services and

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

How we got hereKuali Enterprise Notification (KEN)

History:• Advance information delivery to users

• Not all communications to end users are workflow• KEN concept arrived• Deliver a unified communications system to

users• Allow users to define how they like to

receive communications• Currently being built

How we got here• KNS/KEW = assets for KFS

• Good productivity• Standards enforcement

• KSB will be needed for KRA to integrate with KFS

• KEN will be fulfilling a general requirement for all systems

• Can these four different technical modules be applied to other apps in a cohesive fashion?• Both Kuali and non-Kuali?• YES!

• But… it’ll take some work.

Let There Be Rice!

Rice Technology• Java SDK• Spring Framework

– Service interface and implementations– Spring MVC

• Struts --> Spring MVC• Apache OJB

– Object relational mapper• McKoi DB (evaluating Apache Derby)

– KEN and KEW Quickstart• Oracle DB

– KNS and KEW - production quality

Rice Technology• OpenSymphony Quartz

– Spring integration• Apache Tomcat 5.5• JSP/JSTL• XML/XSD

– DOM/Xpath– XStream

• XSLT• Apache Axis

Rice Modules• KSB will enable applications and services

deployed on the bus to interact with other applications and services deployed on the bus

• Spring configured– HttpRemoting– Web Services

• Generic web service invocation (Apache Axis)– String in and String out (XML)

• Synchronous and asynchronous communications• Message topics

KSB (Kuali Service Bus)

Rice Modules

• Provides reusable code, shared services, and strategy for development– Documents (processes) and workflow integration

• Maintenance (add/update/delete records in tables)– Lookups– Inquiries– Pluggable authorization (interface/impl)– Pluggable business rules (interface/impl)– Data Dictionary - Glue (XML)

• Approaches to solving common development tasks

KNS (Kuali Nervous System)

Rice Modules• Facilitates routing and approval of business

transactions throughout the University• Allows for re-usable rules to be created for how

transactions should routed• Provides hooks for client applications to handle

workflow lifecycle events for transactions• End user:

– Common document (process) search function– Common Action List function that span across

different applications• JTA support• XML/Java/UI configuration

KEW (Kuali Enterprise Workflow)

Rice Modules• Provide a single list for all university related

communications– Workflow items (KEW)– Non-workflow items (KEN)

• Your book is overdue• A concert is coming up on campus

• A secure and controlled environment for notifying masses

• Eliminate sifting through email• Communication broker (Action List + SMS +

Email + etc)

KEN (Kuali Enterprise Notification)

Rice ModulesKEN (Kuali Enterprise Notification)

The Future of Rice• 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

Conclusion• Evolving Rice into an independent set of

reusable components will create some interesting possibilities for future java projects

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

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