1 / 44

KC Application Architecture

KC Application Architecture. Terry Durkin, KC Development Manager (Indiana University) Bryan Hutchinson, KC Development Manager (Cornell) Jack Frosch, KC Lead Developer (Kuali Foundation). Introduction. KC Background KC Application Architecture How KC uses Rice

oshin
Download Presentation

KC Application Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  15. Documents - Size

  16. Documents - Size <headerNavigation> <headerNavigationTab> <navigateTo>proposal</navigateTo> <displayName>Proposal</displayName> </headerNavigationTab> <headerNavigationTab> <navigateTo>budgetVersions</navigateTo> <displayName>Budget Versions</displayName> </headerNavigationTab> …snip… <headerNavigationTab> <navigateTo>grantsGov</navigateTo> <displayName>Grants.gov</displayName> </headerNavigationTab> <headerNavigationTab> <navigateTo>actions</navigateTo> <displayName>Proposal Actions</displayName> </headerNavigationTab> </headerNavigation>

  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. <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"> <forward name="basic" path="/WEB-INF/jsp/ProposalDevelopment{1}.jsp" /> <forward name=”budgetVersions" path="/WEB-INF/jsp/ProposalDevelopmentBudgetVersions.jsp" /> <forward name="keyPersonnel" path="/WEB-INF/jsp/ProposalDevelopmentKeyPersonnel.jsp" /> <forward name="proposal" path="/WEB-INF/jsp/ProposalDevelopmentProposal.jsp" /> ... </action> publicclass ProposalDevelopmentDocument extends ResearchDocumentBase implements Copyable, SessionDocument { ... } Documents - Web Scope

  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 • Functional Specification completed • DM reviews spec • DM assigns JIRA to developer • Developer works in Eclipse against local database with Jetty • Developer commits to svn • Continuum gets latest updates and builds KC app and runs unit tests • CNV environment built daily • REG environment built weekly • When JIRA task is complete, Lead Developer leads peer review of committed code • 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.edu • Bryan Hutchinson - bh79@cornell.edu • Jack Frosch - jfrosch@objistics.com

  44. Questions?

More Related