Kuali Architecture: An Overview Mike Criswell MSU Enterprise Business Systems Projects (EBSP) April 23, 2008

Making Your Own Kuali

Kuali Definition A kuali is a wok Is a versatile round-bottomed cooking vessel originating in China. It is used especially in East and Southeast Asia It is most often used for stir frying kuali (small wok) in Malaysia, and kawa (big wok) Kuali Software: Enterprise software designed by higher ed for higher ed

Goals of Presentation Brief introduction to the Kuali Foundation, its initiatives, and MSU’s involvement Define what makes a Kuali application Architectural and design philosophies Awareness of the major open source products used The Kuali Rice Framework (overview of two important modules: Kuali Enterprise Workflow (KEW) and Kuali Nervous System (KNS)) Where you can get more information Answer your Kuali questions

Introduction Need to replace legacy systems Central Financial System (Mainframe-based) to be replaced with Kuali Financial System (KFS) Contracts and Grants – Goal is to use Kuali Research Administration (KRA) EBSP (Enterprise Business Systems Projects) – Responsible for overseeing Kuali initiatives at MSU Relationship between MSU and Kuali Foundation

Foundation

Kuali Initiatives Contributed Stores System??? Stores collaboration

Architectural Philosophy Java-based apps built with J2EE and XML technologies Use open standards Incorporate Service Oriented Architecture (SOA) concepts Apps are built using a shared framework Modular Extensible Scalable Database agnostic

Design Philosophy Reusable Code Apps should have a common look and feel Utilize Open Source Tools and Frameworks Promote Loose Coupling –Program to an Interface –Dependency Injection/Inversion of Control (IoC) (Spring Framework)

What is a Kuali Application? Based on the concept of routable electronic documents (eDoc) Documents represent the transactions or processes that exist in the system eDocs utilize an underlying workflow engine that allows documents to be routed for approval(s), acknowledgements, FYIs, before they are processed Kuali applications are built with the Kuali Rice Framework

KFS Application

Example eDoc

eDoc Characteristics eDocs are derived from a common base class via inheritance. Share similar traits and behaviors Identified by a unique document ID number assigned to each document instance eDocs inherit workflow capabilities. Document behaviors vary depending on the document type. Common behaviors, such as initiate, save, route, blanket approve, cancel, etc., are made available to an eDoc Support for Notes and Attachments

Types of eDocs Two main types –Maintenance Documents –Transactional Documents Most documents extend one of these two types

Maintenance Documents –Inherit behaviors and traits to manage an application’s maintenance table’s records –Example: Maintenance Document would be appropriate for supporting Country Codes, State Codes, Zip Codes, System Parameters

Transactional Documents These documents represent business process related transactions like: Buy something (Requisition, Purchase Order) Receive money Pay somebody Transfer assets Hire someone Sign up for classes Etc.

Architectural Tiers Client Web Service Persistence/DAO Database

Request Flow OJB

Open Source Products Kuali applications use open source products throughout all tiers –Struts Framework –DisplayTag Library - suite of custom tags that provide high-level web presentation patterns that work with the MVC model –Spring Framework (service wiring/dependency injection) –OJB (ORM Persistence Framework) –Tomcat – Servlet Container & HTTP Services –Ehcache – Caching implementation

Web Tier - Struts A Framework used in the Web Tier Based on MVC (Model/View/Controller) design pattern Conforms to Sun's Java Servlet and JSP specifications. Struts is the driver of the web tier and handles the processing and dispatching of incoming requests that end with *.do Struts will lookup the correct Action Form and Action Class to dispatch to based on the request URL and then populate the Action Form with the request parameters before dispatching the appropriate Action Class

Web Tier Components The Web Tier for Kuali is made up of the following types of components: –web.xml –Filters –Listeners –Struts Action Servlet –Struts Request Processor –Struts Forms –Struts Actions –Struts-config.xml –JSP files –JSP Tag libraries –Image files –Javascript files –CSS files –XML/XSLT files –AJAX DWR

Kuali Rice Framework Kuali: a humble kitchen wok; Malaysian origins Rice: it is what it is –Sits on the bottom of a dish –Not a very tasty meal by itself –Better with some substance on top KFS - Beef KRA - Chicken KS - Seafood Rice is the foundation to a hearty software product

Kuali Rice Modules KEW - Kuali Enterprise Workflow KNS – Kuali Nervous System KEN – Kuali Enterprise Notification KSB – Kuali Service Bus KIM – Kuali Identity Management

Rice – Kuali Enterprise Workflow (KEW) Responsible for providing the routing capabilities Helps eliminate paper processes Each workflow process instance created by a Kuali app is assigned a unique identifier Maintains a permanent record of an eDoc’s route history Can be installed as Embedded or Standalone eDocs defined by a Kuali app must be registered in KEW eDocs are serialized into XML allowing KEW to route documents based on specific content

Rice – Kuali Nervous System (KNS) History –Originally part of KFS application (pre-Rice) –Kuali architects wanted to leverage existing investment in infrastructure code for next set of Kuali applications –Goal was to abstract common features into a framework to gain productivity and consistency across projects –Create a reusable development environment A sub framework composed of common components used across e-Docs

KNS Features Data Dictionary Framework Lookup Framework Inquiry Mechanism Maintenance Framework Authentication Component Authorization Component Workflow Component Document Notes and Attachments Scheduler for batch processing Validation Framework Kuali Tag Library

Data Dictionaries Components used to build an eDoc are glued/assembled by a document Data Dictionary XML file (One document DD for each eDoc) XML documents used to create eDocs Currently three DD types exist –Business Object DD –Maintenance Document DD –Transactional Document DD

… Country Lookup Lookup a Country N Business Object DD

org.kuali.kfs.bo.Country org.kuali.core.maintenance.KualiMaintainableImpl org.kuali.core.document.authorization.MaintenanceDocumentAuthor izerBase KUALI_ROLE_MAINTENANCE CountryMaintenanceDocument CTRY Country Country maintenance document Document used to create or update Country objects false Maintenance Document DD Tabs (maintainable sections) common to all eDocs

Pluggable Authentication Allows an institution to implement its preferred services if necessary Example: Ability to plug in existing authentication services –Kuali’s default Authentication implementation uses the Central Authentication Service (CAS) developed by Yale. MSU will use Sentinel

Authorization Authorization in Kuali is document- based and is driven by KEW workgroups Actions a user can take on an eDoc are defined within the eDoc’s maintenance or transaction data dictionary xml file. Kuali applications are dependent on Rice’s Kuali Enterprise Workflow

Authorization DD Entry

Lookups Provide a common way to look up records and view summarized details Can return a list of appropriate values to be used for a field on a eDoc Used extensively with maintenance eDocs Allows a user to lookup data related to an associated eDoc

Lookups Lookup Results handled by open source DisplayTag package Links to Workflow Instantiates a new maintenance eDoc to add a Country code Wildcardable search criteria

Inquiries

Service Tier - Responsibility The Service tier is intended to be the layer in the application that is responsible for exposing the primary core behaviors in the system The Service layer is also intended to represent and wrap calls that need to ultimately go to the data layer in the application

Service Tier – Service Examples A few of the many services –WebAuthenticationService –DataDictionaryService –DocumentService –CachingService –UserService –ConfigurationService –AuthorizationService

Service Tier - Spring Spring –Manages services through dependency injection –Services are defined in the system based on their interfaces, then “wired” to a particular implementation –Flexibility to change out the implementation of a given service implementation with an alternate impl class

Service Tier – Trx Mgmt Spring Transaction Management –A key feature that Spring provides is declarative transaction management –All Services that will be interacting with the Data Tier are wrapped in a transactionAutoProxyCreator bean defined in the Spring configuration file –This will ensure that all calls made by any of those services to other services etc. are all in one managed transaction with automatic rollback and commit functionality

Persistence Tier The Data Tier of a Kuali application consists of several different pieces –Connections and Connection Pools –The code that we use to interact with the data through the connections to the database –The Database itself and the corresponding data in the tables

Data Tier – Data Source Connections and Connection Pools –The various configurations that exist Spring managed data source and transaction manager defined through XML as Spring Beans The Web App uses a data source managed by the servlet container and transaction manager defined in Spring

Data Tier - Database The Database –Kuali applications are architected to be database agnostic –The database should only be used to store data, and should avoid embedding logic in vendor- specific DB languages like PL/SQL or Transact- SQL –Foundation is currently using Oracle and MySQL during development –MSU Kuali implementations will use Oracle

Data Tier - Interaction Application calls to the database are done through a service and typically do not interact directly with the database. The services interact with the DAOs in the Data Access Tier CRUD actions that require transactional services currently use a transaction manager (Atomikos) wired through Spring

Data Tier - DAOs Interacting with the Database –Is done through an additional level of interface/implementation pairs to again allow for substitution of a particular implementation should that be desired –The DAO interfaces simply define the required behaviors needed by the application, but in no way tie us to particular implementation like OJB which is our default in terms of Impls

Data Tier - OJB Interacting with the Database –OJB (Apache’s ObJectRelationalBridge) Currently OJB is used as Kuali’s persistence framework OJB is an Object Relational Mapping (ORM) tool When we define an entity (table) to the system we must map it to an object representation in OJB’s repository xml file

OJB XML Repository <field-descriptor name="postalCountryRestrictedIndicator" column="PSTL_CNTRY_RSTRC_IND" jdbc-type="VARCHAR" conversion="org.kuali.core.util.OjbCharBooleanConversion" /> Business Object Class DB Table

Additional Information test.kuali.org/confluence rice.kuali.org

Wrap Up Discussed the Kuali Foundation, its initiatives, and MSU’s role Defined what makes a Kuali application Covered Architectural and design philosophies Overview of the major open source products used Importance of Rice (KEW and KNS) Where you can get more information

Questions?