Click here to load reader

KC Application Architecture Terry Durkin, KC Development Manager (Indiana University) Bryan Hutchinson, KC Development Manager (Cornell) Jack Frosch, KC

  • View

  • Download

Embed Size (px)

Text of KC Application Architecture Terry Durkin, KC Development Manager (Indiana University) Bryan...

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

  • KIM

  • 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) 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 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