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

Quality Assurance

Release 1.0

Proposal & Budget

KC & COEUS Development Merger Timeline

8300 (8)

Kuali Rice Integration

Release 3.1Apr 2011akaCOEUS 5.0

Release 2.0

Startup

Conflict of Interest

Awards

Negotiations

Report Tracking

Subcontracts

Release 4.0

Release 2.0Aug 2009

OctQ4

10000 ( )

4000 ( )

2000 ( )

Release 3.0Sep 2010

Release 1.0Jul 2008

1400 ( )

4000 ( )

IRB / Human Participants

1400 ( )

Development

JanQ1

AprQ2

2010

Release 3.0

Export Controls

1400 ( )

4000 ( )

4000 ( )

Enhancements

4200 ( )

Chemical Tracking

Bio-Safety

November 2008

Release 4.0Apr 2012

Required Hours (# Developers)

Animal Care and Use

8000 ( )

JulQ3

Deployment

OctQ4

2007

2008

2009

COEUS 4.5Apr 2010

2010

2011

JanQ1

AprQ2

JulQ3

2011

OctQ4

Jan Q1

Apr Q2

2012

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

For Further Informationhttp://www.kuali.org/communities/kc/General KC Informationhttps://test.kuali.org/confluence/display/KRADOC/HomeKC Documentation

Contacts:Terry Durkin - tdurkin@indiana.eduBryan Hutchinson - bh79@cornell.eduJack Frosch - jfrosch@objistics.com

Questions?

*Bryan******Specify that we are focusing on things that make KC unique; some items have pending enhancements**Terry next***Struts still thinks our ActionForms are in the Request. However, we implement a marker interface (SessionDocument) to indicate otherwise. SessionDocument is handled in KualiRequestProcess (subclass of RequestProcessor from Struts)*****WIP - APIs published; KRA will create services that conform to KIM APIs for now*Jack next* CNV:- Reg:*KEW: Customize workflow routing rulesPerson/Group/Authz/Authn: Release 1.0: Populate Person data from HR systemGrants.gov: Get an encryption certificate from Grants.gov* Services are looked up and data access objects are injected into the services using the Spring Framework- Packaging and Documentation: Need more on this KC Test drive at http://www.kuali.org/testdrive/- Support Model: Currently mailing lists; later more community based; Partner institutions can report issues via JIRA system******