1. Kuali Rice Evolving the Infrastructure for Kuali Applications Brian McGough (Indiana University) Aaron Godert (Cornell University)

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

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

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

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

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

8. How we got here General 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

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

10. How we got here Kuali 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

11. How we got here Kuali 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

12. How we got here Kuali 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

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

14. Let There Be Rice!

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

16. Rice Technology OpenSymphony Quartz –Spring integration Apache Tomcat 5.5 JSP/JSTL XML/XSD –DOM/Xpath –XStream XSLT Apache Axis

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

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

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

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

21. Rice Modules KEN (Kuali Enterprise Notification)

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

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