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

KC Application Architecture

Terry Durkin, KC Development Manager (Indiana University)

Bryan Hutchinson, KC Development Manager(Cornell)

Jack Frosch, KC Lead Developer(Kuali Foundation)

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

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

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

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

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

Functional Roots - Coeus

• Cradle to Grave Research Administration– Proposals/Budgets– Awards

• Links to Financial System

– Subcontracts– Negotiations– Compliance (human subjects)

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

KC Architecture

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

KC Architecture

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

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

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

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

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

Rice Components

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

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

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

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

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

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

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

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

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

Documents - Size

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

Documents - Size

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

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>

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

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)

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

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 {

...

}

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

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

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

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

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

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

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

Custom Attributes

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

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

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

People

• KC: Research System required data

• KFS: Financial System required data

• KIM– Define a ‘Person’ generically– Institution specific attributes– Application specific attributes

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

KIM

http://rice.kuali.org/kim_javadocs/

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

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

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

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

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

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

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

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

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

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

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

KC Development Process

• Development Toolbox– Eclipse– JUnit / HttpUnit– Jetty– Subversion (svn)– Maven

• Shared Tools– Continuum (CI)– Fisheye

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]

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

Questions?


Recommended