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
• Moving Rice Functionality Forward
• KC Development Process
• Implementing KC
• Where we are and where we’re going
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
Functional Roots - Coeus
• Cradle to Grave Research Administration– Proposals/Budgets– Awards
• Links to Financial System
– Subcontracts– Negotiations– Compliance (human subjects)
KC Architecture
KC Architecture
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
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
Rice Components
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
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
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
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
Documents - Size
Documents - Size
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>
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)
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"> <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>
public class ProposalDevelopmentDocument extends ResearchDocumentBase implements Copyable, SessionDocument {
...
}
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
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
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
Custom Attributes
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
People
• KC: Research System required data
• KFS: Financial System required data
• KIM– Define a ‘Person’ generically– Institution specific attributes– Application specific attributes
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
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
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
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
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
KC Development Process
• Development Toolbox– Eclipse– JUnit / HttpUnit– Jetty– Subversion (svn)– Maven
• Shared Tools– Continuum (CI)– Fisheye
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
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
KC Development Process
1. Functional Specification completed2. DM reviews spec3. DM assigns JIRA to developer4. Developer works in Eclipse against local database with Jetty5. Developer commits to svn6. 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
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)
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
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
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
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
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
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
Future of KC
Jan
Q1
Jan
Q1
Jan
Q1
Apr
Q2
Apr
Q2
Apr
Q2
Jul
Q3
Jul
Q3
Jul
Q3
Oct
Q42007 2008 2009
Release 1.0
KC & COEUS Development Merger Timeline
Release 2.0Aug 2009
Release 1.0Jul 2008
Release 3.0
November 2008
Quality Assurance
Kuali Rice Integration
Conflict of Interest
Awards
10000 ( )
4000 ( )
2000 ( )
IRB / Human Participants
Required Hours (# Developers )
Oct
Q4
Startup Proposal & Budget
Release 2.0
8300 (8)
Development
Oct
Q4
Jan
Q1
Apr
Q2
Release 3.0Sep 2010
2010
Jul
Q3
Deployment
Oct
Q4
2007 2008 2009
2010
2011
Jan
Q1
Apr
Q2
Jul
Q32011
Oct
Q4
Release 4.0
Release 4.0Apr 2012
Report Tracking
Animal Care and Use
Subcontracts
Negotiations 1400 ( )
4000 ( )
1400 ( )
8000 ( )
Export Controls
1400 ( )
4000 ( )
4000 ( )
Enhancements 4200 ( )
Chemical
Tracking
Bio -Safety
Jan
Q1
Apr
Q22012
Jul
Q3
Oct
Q4
Release 3.1
COEUS
Merger Catch-up
COEUS 4.4(contents known ) Development COEUS 4.5
(contents TBD )
2012
Budget
Release 1.1
Release 1.1Nov 2008
COEUS 4.4Apr 2009
COEUS 4.5Apr 2010
Release 3.1Apr 2011
akaCOEUS 5.0
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 - [email protected]– Bryan Hutchinson - [email protected]– Jack Frosch - [email protected]
Questions?