Author
melina-erika-tate
View
215
Download
2
Tags:
Embed Size (px)
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 - [email protected] Hutchinson - [email protected] Frosch - [email protected]
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******