KRA Application Architecture

Terry Durkin, KRA Development Manager (Indiana University)

Bryan Hutchinson, KRA Development Manager(Cornell)

Andy Slusar, KRA Project Manager(Cornell)

Introduction

• KRA Background

• KRA Application Architecture

• Rice Background

• How KRA uses Rice

• Moving Rice Functionality Forward

• KRA Development Process

• Implementing KRA

About KRA

• Kuali Research Administration• Enterprise level Research Administration• Any proposal submitting institution• Based on MIT’s Coeus

– 12 years of development/functionality– 46 members in the Coeus Consortium

• Release 1.0 - July 2008– Proposal Development/Budget incl. Grants.gov S2S– Currently in Quality Assurance Testing (began 4/1)

Functional Roots - Coeus

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

• Links to Financial System

– Subcontracts– Negotiations– Compliance (human subjects)

KRA Architecture

KRA Architecture

KRA 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

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 include multiple

enhancements focusing on KRA requirements

Rice Components

Nervous System (KNS)

• Data Dictionary

• Document lifecycle

• Lookups

• UI Components

• Maintenance Documents

• Persistence

Workflow (KEW)

• Workflow as a Service• Rules• Approvals• Actions• Workgroups• Integrated into KNS Documents• Accessible from existing applications• Embedded/External

Notifications (KEN)

• Notifications (not Actions)

• Multiple notification schemes– Email– Mobile Phone

• Priority

• Extensible

Service Bus (KSB)

• Service Integration• Ease of Integration• Provides opportunities for synergies between Kuali

applications• Framework for communicating with existing applications• Multiple Connectors

– Java– SOAP– Spring Integration– Etc…

Identity Management (KIM)

• Simple out-of-the-box solution for Identity Management (users, groups, etc).

• Application integration via KSB• Institution and Application Extensible• Can provide fine grained User/Role based AuthZ• Integrate with existing AuthN infrastructure• Currently under development• KRA Release 1.0 will use an initial version of the

KIM interfaces with a KRA-specific implementation

How KRA Uses Rice

• Kuali Rice is the basic development framework used by KRA, but…– KRA is Functionally different from other Kuali

Applications– KRA is Technically different from other Kuali

Applications

Functionally different from other Kuali Applications

• Analysis of Functional Differences

• Differences provide basis for Rice enhancementsExtend and customize functionality where possible

Focus on Extension, not Disruption

Add new tools to the Rice toolbox

More on this tomorrow!

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, not Anthill

• Allows execution of Bamboo native plugins and Maven plugins

Documents - Size

• KRA: 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

Documents - Size

Documents - Size

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>

Documents - Web Scope

• KRA: Large Documents, Session based

• KFS: Currently Request based

• KNS– Mitigate issues with Session based persistence

(multiple browsers, etc…)– Eases development/maintenance (hiddens, load-

save-load anti-pattern)

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 {

...

}

Documents - Locking

• KRA: 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

Documents - Versioning

• KRA: Many documents require versioning• KFS: Versioning not required in general (PurAp

docs do version)

• KNS (enhancement pending - KRA Release 2.0)– Support optional versioning of documents– Configuration option– Little additional code required– New Version created by user request or

programmatically

Custom Attributes

• KRA: Transactional Documents, table based, runtime

• KFS: Reference Data, code based

• Implemented in KRA for Release 1.0 (Future enhancement to move from KRA to KNS)– Support both models– UI: Integrated custom tag– Accessible for Lookups, Routing, Reporting– Strongly typed for validation

Custom Attributes

User Roles; AuthZ

• KRA: User/Role based; Integrated into Unit Hierarchy; Code checks Permissions

• KFS: Workgroup based

• KIM– Manage people/groups– Qualified Roles allow integration with Unit Hierarchy

• KNS– Document Authorizer Class

People

• KRA: Research System required data

• KFS: Financial System required data

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

KIM

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

Workflow

• KRA: 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 KRA-related enhancements

More…

• KSB– Units/Organizations– People– Validation

• KRA - Grants.gov– Kuali Lookupable Interface for cohesive interface– Web Service

Moving Rice Functionality Forward

• Identifying KRA Requirements– Gap Analysis between Coeus and KRA

• Integration Meetings– Technical representatives from Rice enabled

applications– Review of Enhancement Proposals based on

Functional Requirements

• Project Planning– Managing multiple release schedules

Moving Rice Functionality Forward

• Development Work on approved Rice enhancements split between KRA and Rice teams

• Rice Enhancements for KRA Release 1.0– 19 Enhancements Proposed– 17 Approved, 1 Deferred for KIM, 1 Not needed

based on existing KEW functionality– 15 Development Complete, 2 In Process

Synergies and Moving Forward

• KRA– Relies on Rice to provide functionality

• Rice– Greater richness of functionality as KRA

requirements are integrated

• Future Rice Enabled Applications– More choices, more functionality, more features

KRA Development Process

• Distributed Development Team

• Module Teams led by a Development Manager

• Common Tools

• Clear Expectations

• Defined Standards and Processes

KRA Development Process

• Development Toolbox– Eclipse– Junit / Httpunit– Jetty– Cvs– Maven

• Shared Tools– Bamboo– Fisheye

KRA Development Process

• Shared collaboration tools– Confluence wiki– JIRA bug tracking– KRA Developer mailing list– PolyCom video-conferencing– Breeze / Adobe Connect - online collaboration– Skype - text / voice / video chat

KRA Development Process

• Clear expectations for KRA Developers documented in Confluence– Code Reviews– Coding Standards– Documentation Standards– Tool usage– Unit Tests– Etc

• Regular meetings– Weekly 1-on-1– Weekly Code Reviews– Bi-weekly team meetings– Periodic Face-to-Face meetings

KRA 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 cvs6. Bamboo gets latest updates and builds KRA app and runs unit tests7. CNV environment built daily8. REG environment built weekly

Implementing KRA

• Rice components necessary for KRA 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 (KIM) information– AuthN / AuthZ (KIM)

Implementing KRA

• Data Migration / Interfaces– KRA is SOA - implement your own implementations as

necessary– Main Data Migration / Integration points will be

documented

• Still to Come– Implementation Guide– KRA Packaging and Documentation for Release 1.0– KRA Test Drive– Support Model

Technical Competencies for KRA Implementation

• Straight Implementation– Enterprise Java– Apache Web Server– Tomcat– DBA (Oracle or MYSQL)

• For customization– Struts– OJB/ORM– Spring– Kuali Rice– XML

Future of KRA

• Release 1.0 - July 2008– Proposal Development / Budget– Grants.gov S2S

• Release 1.1 - Fall 2008– Budget UI Enhancement– Proposal Development / Budget Bug fixes

• Release 2.0 - 2009– IRB– Awards– COI

• Release 3.0, 4.0– Full functionality of Coeus– Additional Functionality not currently in Coeus

Future of KRA

For Further Information

• http://www.kuali.org/communities/kra/

– General KRA Information• https://test.kuali.org/confluence/display/KRADOC/Home

– KRA Documentation

• Contacts:– Terry Durkin - tdurkin@indiana.edu– Bryan Hutchinson - bh79@cornell.edu– Andrew Slusar - as833@cornell.edu

Questions?