1. KRA Application Architecture Terry Durkin, KRA Development Manager (Indiana University) Bryan Hutchinson, KRA Development Manager (Cornell) Andy Slusar, KRA Project Manager (Cornell)

2. Introduction KRA Background KRA Application Architecture Rice Background How KRA uses Rice Moving Rice Functionality Forward KRA Development Process Implementing KRA

3. About KRA Kuali Research Administration Enterprise level Research Administration Any proposal submitting institution Based on MIT’s Coeus –12 years of development/functionality –46 members in the Coeus Consortium Release 1.0 - July 2008 –Proposal Development/Budget incl. Grants.gov S2S –Currently in Quality Assurance Testing (began 4/1)

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

5. KRA Architecture

7. KRA 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 include multiple enhancements focusing on KRA requirements

9. Rice Components

10. Nervous System (KNS) Data Dictionary Document lifecycle Lookups UI Components Maintenance Documents Persistence

11. Workflow (KEW) Workflow as a Service Rules Approvals Actions Workgroups Integrated into KNS Documents Accessible from existing applications Embedded/External

12. Notifications (KEN) Notifications (not Actions) Multiple notification schemes –Email –Mobile Phone Priority Extensible

13. Service Bus (KSB) Service Integration Ease of Integration Provides opportunities for synergies between Kuali applications Framework for communicating with existing applications Multiple Connectors –Java –SOAP –Spring Integration –Etc…

14. Identity Management (KIM) Simple out-of-the-box solution for Identity Management (users, groups, etc). Application integration via KSB Institution and Application Extensible Can provide fine grained User/Role based AuthZ Integrate with existing AuthN infrastructure Currently under development KRA Release 1.0 will use an initial version of the KIM interfaces with a KRA-specific implementation

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

16. 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 More on this tomorrow!

17. 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, not Anthill Allows execution of Bamboo native plugins and Maven plugins

18. Documents - Size KRA: 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

19. Documents - Size

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

22. Documents - Web Scope KRA: Large Documents, Session based KFS: Currently Request based KNS –Mitigate issues with Session based persistence (multiple browsers, etc…) –Eases development/maintenance (hiddens, load- save-load anti-pattern)

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

24. Documents - Locking KRA: 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

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

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

27. Custom Attributes

28. User Roles; AuthZ KRA: User/Role based; Integrated into Unit Hierarchy; Code checks Permissions KFS: Workgroup based KIM –Manage people/groups –Qualified Roles allow integration with Unit Hierarchy KNS –Document Authorizer Class

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

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

31. Workflow KRA: 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 KRA-related enhancements

32. More… KSB –Units/Organizations –People –Validation KRA - Grants.gov –Kuali Lookupable Interface for cohesive interface –Web Service

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

34. Moving Rice Functionality Forward Development Work on approved Rice enhancements split between KRA and Rice teams Rice Enhancements for KRA Release 1.0 –19 Enhancements Proposed –17 Approved, 1 Deferred for KIM, 1 Not needed based on existing KEW functionality –15 Development Complete, 2 In Process

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

36. KRA Development Process Distributed Development Team Module Teams led by a Development Manager Common Tools Clear Expectations Defined Standards and Processes

37. KRA Development Process Development Toolbox –Eclipse –Junit / Httpunit –Jetty –Cvs –Maven Shared Tools –Bamboo –Fisheye

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

39. KRA Development Process Clear expectations for KRA Developers documented in Confluence –Code Reviews –Coding Standards –Documentation Standards –Tool usage –Unit Tests –Etc Regular meetings –Weekly 1-on-1 –Weekly Code Reviews –Bi-weekly team meetings –Periodic Face-to-Face meetings

40. KRA 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 cvs 6.Bamboo gets latest updates and builds KRA app and runs unit tests 7.CNV environment built daily 8.REG environment built weekly

41. Implementing KRA Rice components necessary for KRA 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 (KIM) information –AuthN / AuthZ (KIM)

42. Implementing KRA Data Migration / Interfaces –KRA is SOA - implement your own implementations as necessary –Main Data Migration / Integration points will be documented Still to Come –Implementation Guide –KRA Packaging and Documentation for Release 1.0 –KRA Test Drive –Support Model

43. Technical Competencies for KRA Implementation Straight Implementation –Enterprise Java –Apache Web Server –Tomcat –DBA (Oracle or MYSQL) For customization –Struts –OJB/ORM –Spring –Kuali Rice –XML

44. Future of KRA Release 1.0 - July 2008 –Proposal Development / Budget –Grants.gov S2S Release 1.1 - Fall 2008 –Budget UI Enhancement –Proposal Development / Budget Bug fixes Release 2.0 - 2009 –IRB –Awards –COI Release 3.0, 4.0 –Full functionality of Coeus –Additional Functionality not currently in Coeus

45. Future of KRA

46. For Further Information http://www.kuali.org/communities/kra/ –General KRA Information https://test.kuali.org/confluence/display/KRADOC/Home –KRA Documentation Contacts: –Terry Durkin - tdurkin@indiana.edutdurkin@indiana.edu –Bryan Hutchinson - bh79@cornell.edubh79@cornell.edu –Andrew Slusar - as833@cornell.eduas833@cornell.edu

47. Questions?