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