Date post: | 31-Dec-2015 |
Category: |
Documents |
Upload: | gloria-allison |
View: | 219 times |
Download: | 0 times |
Kuali Architecture: An Overview
Mike [email protected]
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
<dictionaryEntry> <businessObject businessObjectClass="org.kuali.kfs.bo.Country">… <lookup> <title>Country Lookup</title> <instructions>Lookup a Country</instructions> <defaultSort attributeName="postalCountryCode"
sortAscending="true" />
<lookupFields> <lookupField attributeName="postalCountryCode"
required="false" /> <lookupField attributeName="postalCountryName"
required="false" /> <lookupField attributeName="postalCountryRestrictedIndicator" required="false"> <defaultValue>N</defaultValue> </lookupField> </lookupFields>
<resultFields> <field attributeName="postalCountryCode" /> <field attributeName="postalCountryName" /> <field attributeName="postalCountryRestrictedIndicator" /> </resultFields> </lookup>
Business Object DD
<dictionaryEntry> <maintenanceDocument> <businessObjectClass>org.kuali.kfs.bo.Country</businessObjectClass> <maintainableClass>org.kuali.core.maintenance.KualiMaintainableImpl</maintainableClass>
<documentAuthorizerClass>org.kuali.core.document.authorization.MaintenanceDocumentAuthorizerBase</documentAuthorizerClass> <authorizations> <authorization action="initiate"> <workgroups> <workgroup>KUALI_ROLE_MAINTENANCE</workgroup> </workgroups> </authorization> </authorizations>
<documentTypeName>CountryMaintenanceDocument</documentTypeName> <documentTypeCode>CTRY</documentTypeCode>
<label>Country</label>
<summary>Country maintenance document</summary> <description>Document used to create or update Country objects</description> <help parameterNamespace="KFS-SY" parameterDetailType="Country" parameterName="COUNTRY" />
<lockingKeys> <field attributeName="postalCountryCode" /> </lockingKeys>
<maintainableSections> <maintainableSection title="Edit Country"> <maintainableItems> <maintainableField name="postalCountryCode" required="true" /> <maintainableField name="postalCountryName" required="true" /> <maintainableField name="postalCountryRestrictedIndicator" required="true"> <defaultValue>false</defaultValue> </maintainableField> <maintainableField name="versionNumber" /> </maintainableItems> </maintainableSection> </maintainableSections> </maintenanceDocument></dictionaryEntry>
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
<class-descriptor class="org.kuali.kfs.bo.Country" table="SH_COUNTRY_T"> <field-descriptor name="postalCountryCode" column="POSTAL_CNTRY_CD" jdbc-type="VARCHAR"
primarykey="true" index="true" /> <field-descriptor name="objectId" column="OBJ_ID" jdbc-type="VARCHAR" index="true" /> <field-descriptor name="versionNumber" column="VER_NBR" jdbc-type="BIGINT" locking="true" /> <field-descriptor name="postalCountryName" column="POSTAL_CNTRY_NM" jdbc-type="VARCHAR" /> <field-descriptor name="postalCountryRestrictedIndicator" column="PSTL_CNTRY_RSTRC_IND"
jdbc-type="VARCHAR" conversion="org.kuali.core.util.OjbCharBooleanConversion" /></class-descriptor>
Business Object Class DB Table
Additional Information
• www.kuali.org• test.kuali.org/confluence• rice.kuali.org• http://struts.apache.org/• http://www.springframework.org/• http://tomcat.apache.org/• http://db.apache.org/ojb/• http://java.sun.com/• http://displaytag.sourceforge.net
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?