KC Application ArchitectureTerry Durkin, KC Development Manager (Indiana University)Bryan Hutchinson, KC Development Manager(Cornell)Jack Frosch, KC Lead Developer(Kuali Foundation)
IntroductionKC Background KC Application ArchitectureHow KC uses RiceMoving Rice Functionality ForwardKC Development ProcessImplementing KCWhere we are and where were going
About KCKuali Research AdministrationEnterprise level Research AdministrationAny proposal submitting institutionBased on MITs Coeus13+ years of development/functionalityOver 50 members in the Coeus ConsortiumRelease 1.0 - July 2008Proposal Development/Budget incl. Grants.gov S2SAvailable for download from http://www.kuali.orgRelease 2.0 - August 2009Awards, IRB, COICurrently under development
Functional Roots - CoeusCradle to Grave Research AdministrationProposals/BudgetsAwardsLinks to Financial SystemSubcontractsNegotiationsCompliance (human subjects)
KC Architecture
KC Architecture
KC Building BlocksKuali ToolboxOpen Source ToolsStruts - UIOJB - PersistenceSpring - ServicesRice builds upon and extends functionalityStruts - Mitigates common issues (POJO forms, Formatting,)OJB - DAO w/ Object Hierarchy; No custom code for POJO persistence
About Kuali RiceSoftware Development SimplifiedUnified development platformDiverse functional requirementsService Oriented Architecture (SOA)Integration of Kuali ApplicationsIntegration of existing Enterprise ApplicationsVersions 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 RiceKuali Rice is the basic development framework used by KC, butKC is Functionally different from other Kuali ApplicationsKC is Technically different from other Kuali Applications
Functionally different from other Kuali ApplicationsAnalysis of Functional DifferencesDifferences provide basis for Rice enhancementsExtend and customize functionality where possibleFocus on Extension, not DisruptionAdd new tools to the Rice toolbox
Technically different from other Kuali ApplicationsSame basic building blocks (Kuali stack)Rice allows us to make our own choices about developmentMaven, not AntJetty, not Tomcat (Development)HTMLUnit TestsBamboo, then Continuum, not Anthill for CI
Documents - SizeKC: Few, large, complexKFS: Many, small, still complex
KNSData Dictionary - Specify multiple pagesWeb Flow - Allow consistent behavior while navigating between multiple pages in arbitrary orderDocument interaction - Document is saved/loadedRules - Events/Rules can be specified in code and extended
Documents - Size
Documents - Size
Documents - Size proposal Proposal budgetVersions Budget Versions snip grantsGov Grants.gov actions Proposal Actions
Documents - Web ScopeKC: Large Documents, Session basedKFS: Currently Request based, will be session based for KFS Release 3.0
KNSMitigate issues with Session based persistence (multiple browsers, etc)Eases development/maintenance (hiddens, load-save-load anti-pattern)
Documents - Web Scope ... public class ProposalDevelopmentDocument extends ResearchDocumentBase implements Copyable, SessionDocument {...}
Documents - LockingKC: Pessimistic Locking, Long lasting docs, Session Based, Functional AreasKFS: Optimistic Locking, short lived docs
KNS (Rice Enhancement)Centralized locking mechanismDocument Authorizer classesProvide two layers of locking if desired
Documents - VersioningKC: Many documents require versioningKFS: Versioning not required in general (PurAp docs do version)
KNS (enhancement pending - KC Release 2.0)Support optional versioning of documentsConfiguration optionLittle additional code requiredNew Version created by user request or programmatically
Custom AttributesKC: Transactional Documents, table based, runtimeKFS: Reference Data, code based
Implemented in KC for Release 1.0 (Future enhancement to move from KC to KNS)Support both modelsUI: Integrated custom tagAccessible for Lookups, Routing, ReportingStrongly typed for validation
Custom Attributes
User Roles; AuthZKC: User/Role based; Integrated into Unit Hierarchy; Code checks PermissionsKFS: Workgroup based
KIMManage people/groupsRole Qualifiers allow integration with Unit HierarchyApplication AuthZ framework built on top of KIMKNSDocument Authorizer Class
PeopleKC: Research System required dataKFS: Financial System required data
KIMDefine a Person genericallyInstitution specific attributesApplication specific attributes
KIMhttp://rice.kuali.org/kim_javadocs/
WorkflowKC: Can support Coeus routing: Units define custom rules and responsibilities; Initial configuration based on analysis done by Kenton Hensley and Dan DwyerKFS: Account, Unit based; Rules defined for the entire document
KEWFlexible routing allows document/node based workflow (and more)Multiple KC-related enhancements
Moving Rice Functionality ForwardIdentifying KC RequirementsGap Analysis between Coeus and KCKuali Technical Integration MeetingsTechnical representatives from Rice enabled applicationsReview of Enhancement Proposals based on Functional RequirementsProject PlanningManaging multiple release schedules
Moving Rice Functionality ForwardDevelopment Work on approved Rice enhancements split between KC and Rice teamsRice Enhancements for KC Release 1.019 Enhancements Proposed17 Approved and completed, 1 Deferred for KIM, 1 Not needed based on existing KEW functionalityRice Enhancements for KC Release 2.0Currently about 9 enhancements identified
Synergies and Moving ForwardKCRelies on Rice to provide functionalityRiceGreater richness of functionality as KC requirements are integratedFuture Rice Enabled ApplicationsMore choices, more functionality, more features
KC Development ProcessDistributed Development TeamModule Teams led by a Development ManagerLead Developer for each module teamCommon ToolsClear ExpectationsDefined Standards and Processes
KC Development ProcessDevelopment ToolboxEclipseJUnit / HttpUnitJettySubversion (svn)MavenShared ToolsContinuum (CI)Fisheye
KC Development ProcessShared collaboration toolsConfluence wikiJIRA bug trackingKC Developer mailing listPolyCom video-conferencingBreeze / Adobe Connect - online collaborationSkype - text / voice / video chat
KC Development ProcessClear expectations for KC Developers documented in ConfluenceCode ReviewsPeer Reviews of all code, periodic larger group code reviews of interesting/complex/etc codeCoding StandardsDocumentation StandardsTool usageUnit/Integration TestsEtcRegular meetingsWeekly 1-on-1Weekly Code ReviewsMonthly all team and module team meetingsPeriodic Face-to-Face meetings
KC Development ProcessFunctional Specification completedDM reviews specDM assigns JIRA to developerDeveloper works in Eclipse against local database with JettyDeveloper commits to svnContinuum gets latest updates and builds KC app and runs unit testsCNV environment built dailyREG environment built weeklyWhen JIRA task is complete, Lead Developer leads peer review of committed codeOnce peer review is successfully completed, developer closes JIRA
Implementing KCRice components necessary for KC will be included out of the boxTo run Rice services centrally (ex: KEW), the implementing institution will have to plan and do more implementation workMain Configuration PointsWorkflow (KEW) ConfigurationPerson / Group / AuthZ / AuthN (KIM) Grants.gov communication (if implementing Proposal Development)
Implementing KCData Migration / InterfacesKC is SOA - provide your own implementations as necessaryMain Data Migration / Integration points will be documentedKuali Coeus Release 1.0 - July 2008Kuali Coeus Release 1.1 November 2008Implementation GuideKC Packaging and DocumentationKC Test DriveSupport Model
Technical Competencies for KC ImplementationStraight ImplementationJava EEWeb 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 customizationStrutsORM: OJB/JPASpringKuali RiceXML
Where we are nowRelease 1.0 publicly available (July 2008)Release 1.1 publicly available (Nov 2008)Release 2.0 Development has startedOngoing bug fixes for Release 1 Patch
Transition to Release 2.0 DevelopmentMore Developers, multiple modules teamsSeparate Lead Developers and Development Managers for each module teamPeer Reviews vs. large group code reviewsBetter documented (and enforced) coding and documentation standards
Transition to Release 2.0 DevelopmentUpgraded to Rice 0.9.3, and eventually 0.9.4Data Dictionary configuration files changedWill be migrating from OJB to JPARelease 2.0 will be database agnosticS2S Grants.gov module has been rewritten by offshore team Java, not stored proceduresRefactoring/Redesigning parts of the system to do things better this time around
Future of KCRelease 1 Patch Spring 2009Proposal Development / Budget Bug fixesRelease 2.0 - 2009IRBAwardsCOIRelease 3.0, 3.1 (Coeus merge point)Full functionality of Coeus4.0Additional functionality not currently in Coeus
Future of KC
Jan Q1
JanQ1
JanQ1
AprQ2
AprQ2
AprQ2
JulQ3
JulQ3
JulQ3
OctQ4
OctQ4
2007
2008
2009
