Transcript Kuali PowerPoint
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
Applications different from other Kuali – KRA is
Technically
Applications different from other Kuali
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 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 implements
ProposalDevelopmentDocument
extends
Copyable,
SessionDocument
{ ...
} ResearchDocumentBase
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
http://rice.kuali.org/kim_javadocs/
KIM
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.
2.
3.
4.
5.
6.
7.
8.
Functional Specification completed DM reviews spec DM assigns JIRA to developer Developer works in Eclipse against local database with Jetty Developer commits to cvs Bamboo gets latest updates and builds KRA app and runs unit tests CNV environment built daily 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 [email protected]
– Bryan Hutchinson [email protected]
– Andrew Slusar [email protected]