1. KC Application Architecture Terry Durkin, KC Development Manager (Indiana University) Bryan Hutchinson, KC Development Manager (Cornell) Jack Frosch, KC Lead Developer (Kuali Foundation)

2. Introduction KC Background KC Application Architecture How KC uses Rice Moving Rice Functionality Forward KC Development Process Implementing KC Where we are and where we’re going

3. About KC Kuali Research Administration Enterprise level Research Administration Any proposal submitting institution Based on MIT’s Coeus –13+ years of development/functionality –Over 50 members in the Coeus Consortium Release 1.0 - July 2008 –Proposal Development/Budget incl. Grants.gov S2S –Available for download from http://www.kuali.orghttp://www.kuali.org Release 2.0 - August 2009 –Awards, IRB, COI –Currently under development

4. Functional Roots - Coeus Cradle to Grave Research Administration –Proposals/Budgets –Awards Links to Financial System –Subcontracts –Negotiations –Compliance (human subjects)

5. KC Architecture

7. KC Building Blocks Kuali Toolbox –Open Source Tools Struts - UI OJB - Persistence Spring - Services –Rice builds upon and extends functionality Struts - Mitigates common issues (POJO forms, Formatting,…) OJB - DAO w/ Object Hierarchy; No custom code for POJO persistence

8. About Kuali Rice Software Development Simplified –Unified development platform –Diverse functional requirements Service Oriented Architecture (SOA) Integration of Kuali Applications Integration of existing Enterprise Applications Versions 0.9.2 and 0.9.3 included multiple enhancements focusing on KC requirements, and the same is expected of version 0.9.4

9. Rice Components

10. How KC Uses Rice Kuali Rice is the basic development framework used by KC, but… –KC is Functionally different from other Kuali Applications –KC is Technically different from other Kuali Applications

11. Functionally different from other Kuali Applications Analysis of Functional Differences Differences provide basis for Rice enhancements –Extend and customize functionality where possible –Focus on Extension, not Disruption –Add new tools to the Rice toolbox

12. Technically different from other Kuali Applications Same basic building blocks (Kuali stack) Rice allows us to make our own choices about development –Maven, not Ant –Jetty, not Tomcat (Development) –HTMLUnit Tests –Bamboo, then Continuum, not Anthill for CI

13. Documents - Size KC: Few, large, complex KFS: Many, small, still complex KNS –Data Dictionary - Specify multiple pages –Web Flow - Allow consistent behavior while navigating between multiple pages in arbitrary order –Document interaction - Document is saved/loaded –Rules - Events/Rules can be specified in code and extended

14. Documents - Size

16. proposal Proposal budgetVersions Budget Versions …snip… grantsGov Grants.gov actions Proposal Actions

17. Documents - Web Scope KC: Large Documents, Session based KFS: Currently Request based, will be session based for KFS Release 3.0 KNS –Mitigate issues with Session based persistence (multiple browsers, etc…) –Eases development/maintenance (hiddens, load-save- load anti-pattern)

18. Documents - Web Scope <action path="/proposalDevelopment*" name="ProposalDevelopmentForm" validate="true” attribute="KualiForm" input="/WEB-INF/jsp/ProposalDevelopment{1}.jsp" scope="request" parameter="methodToCall" type="org.kuali.kra.proposaldevelopment.web.struts.action.ProposalDevelopment{1}Action">... public class ProposalDevelopmentDocument extends ResearchDocumentBase implements Copyable, SessionDocument {... }

19. Documents - Locking KC: Pessimistic Locking, Long lasting docs, Session Based, Functional Areas KFS: Optimistic Locking, short lived docs KNS (Rice Enhancement) –Centralized locking mechanism –Document Authorizer classes –Provide two layers of locking if desired

20. Documents - Versioning KC: Many documents require versioning KFS: Versioning not required in general (PurAp docs do version) KNS (enhancement pending - KC Release 2.0) –Support optional versioning of documents –Configuration option –Little additional code required –New Version created by user request or programmatically

21. Custom Attributes KC: Transactional Documents, table based, runtime KFS: Reference Data, code based Implemented in KC for Release 1.0 (Future enhancement to move from KC to KNS) –Support both models –UI: Integrated custom tag –Accessible for Lookups, Routing, Reporting –Strongly typed for validation

22. Custom Attributes

23. User Roles; AuthZ KC: User/Role based; Integrated into Unit Hierarchy; Code checks Permissions KFS: Workgroup based KIM –Manage people/groups –Role Qualifiers allow integration with Unit Hierarchy –Application AuthZ framework built on top of KIM KNS –Document Authorizer Class

24. People KC: Research System required data KFS: Financial System required data KIM –Define a ‘Person’ generically –Institution specific attributes –Application specific attributes

25. KIM http://rice.kuali.org/kim_javadocs/

26. Workflow KC: Can support Coeus routing: Units define custom rules and responsibilities; Initial configuration based on analysis done by Kenton Hensley and Dan Dwyer KFS: Account, Unit based; Rules defined for the entire document KEW –Flexible routing allows document/node based workflow (and more) –Multiple KC-related enhancements

27. Moving Rice Functionality Forward Identifying KC Requirements –Gap Analysis between Coeus and KC Kuali Technical Integration Meetings –Technical representatives from Rice enabled applications –Review of Enhancement Proposals based on Functional Requirements Project Planning –Managing multiple release schedules

28. Moving Rice Functionality Forward Development Work on approved Rice enhancements split between KC and Rice teams Rice Enhancements for KC Release 1.0 –19 Enhancements Proposed –17 Approved and completed, 1 Deferred for KIM, 1 Not needed based on existing KEW functionality Rice Enhancements for KC Release 2.0 –Currently about 9 enhancements identified

29. Synergies and Moving Forward KC –Relies on Rice to provide functionality Rice –Greater richness of functionality as KC requirements are integrated Future Rice Enabled Applications –More choices, more functionality, more features

30. KC Development Process Distributed Development Team Module Teams led by a Development Manager Lead Developer for each module team Common Tools Clear Expectations Defined Standards and Processes

31. KC Development Process Development Toolbox –Eclipse –JUnit / HttpUnit –Jetty –Subversion (svn) –Maven Shared Tools –Continuum (CI) –Fisheye

32. KC Development Process Shared collaboration tools –Confluence wiki –JIRA bug tracking –KC Developer mailing list –PolyCom video-conferencing –Breeze / Adobe Connect - online collaboration –Skype - text / voice / video chat

33. KC Development Process Clear expectations for KC Developers documented in Confluence –Code Reviews Peer Reviews of all code, periodic larger group code reviews of interesting/complex/etc code –Coding Standards –Documentation Standards –Tool usage –Unit/Integration Tests –Etc Regular meetings –Weekly 1-on-1 –Weekly Code Reviews –Monthly all team and module team meetings –Periodic Face-to-Face meetings

34. KC Development Process 1.Functional Specification completed 2.DM reviews spec 3.DM assigns JIRA to developer 4.Developer works in Eclipse against local database with Jetty 5.Developer commits to svn 6.Continuum gets latest updates and builds KC app and runs unit tests CNV environment built daily REG environment built weekly 7.When JIRA task is complete, Lead Developer leads peer review of committed code 8.Once peer review is successfully completed, developer closes JIRA

35. Implementing KC Rice components necessary for KC will be included out of the box –To run Rice services centrally (ex: KEW), the implementing institution will have to plan and do more implementation work Main Configuration Points –Workflow (KEW) Configuration –Person / Group / AuthZ / AuthN (KIM) –Grants.gov communication (if implementing Proposal Development)

36. Implementing KC Data Migration / Interfaces –KC is SOA - provide your own implementations as necessary –Main Data Migration / Integration points will be documented Kuali Coeus Release 1.0 - July 2008 Kuali Coeus Release 1.1 – November 2008 –Implementation Guide –KC Packaging and Documentation –KC Test Drive –Support Model

37. Technical Competencies for KC Implementation Straight Implementation –Java EE –Web Server (e.g. Apache) –Servlet 2.4 / JSP 2.0 Compatible Servlet Container (e.g. Tomcat) –Relational database (Oracle for release 1; future release will be platform agnostic) For customization –Struts –ORM: OJB/JPA –Spring –Kuali Rice –XML

38. Where we are now Release 1.0 publicly available (July 2008) Release 1.1 publicly available (Nov 2008) Release 2.0 Development has started Ongoing bug fixes for Release 1 Patch

39. Transition to Release 2.0 Development More Developers, multiple modules teams Separate Lead Developers and Development Managers for each module team Peer Reviews vs. large group code reviews Better documented (and enforced) coding and documentation standards

40. Transition to Release 2.0 Development Upgraded to Rice 0.9.3, and eventually 0.9.4 –Data Dictionary configuration files changed Will be migrating from OJB to JPA Release 2.0 will be database agnostic –S2S Grants.gov module has been rewritten by offshore team – Java, not stored procedures Refactoring/Redesigning parts of the system to do things better this time around

41. Future of KC Release 1 Patch – Spring 2009 –Proposal Development / Budget Bug fixes Release 2.0 - 2009 –IRB –Awards –COI Release 3.0, 3.1 (Coeus merge point) –Full functionality of Coeus 4.0 –Additional functionality not currently in Coeus

42. Future of KC

43. For Further Information http://www.kuali.org/communities/kc/ –General KC Information https://test.kuali.org/confluence/display/KRADOC/Home –KC Documentation Contacts: –Terry Durkin - tdurkin@indiana.edutdurkin@indiana.edu –Bryan Hutchinson - bh79@cornell.edubh79@cornell.edu –Jack Frosch - jfrosch@objistics.comjfrosch@objistics.com

44. Questions?