Kuali Student Architecture Overview February 2011

batterycopperInternet and Web Development

Nov 12, 2013 (3 years and 11 months ago)

165 views

Kuali

Student
Architecture Overview

February 2011

2

Kuali

Student
Architecture


Kuali Student


Kuali Rice

Kuali Service Bus (KSB)

Service
Layer/ SOA

Organization

(KOM)

Notification (KEN)

Workflow (KEW)

Rules (KRMS)

Person

(KIM)

Service Implementation

JAXWS/CXF

Service Contract

SOAP

Rapid Application Development Framework (KRAD)

Presentation

Application

Jquery

Spring MVC

Data Access Object (DAO)

JPA/Hibernate, OJB

Persistence

Database

DB Independent

Database

Architecture Drivers & Philosophy

1.
N
ew
high level entities

2.
Use
of workflow and rules
engines

3.
Easy
to configure to support new rules and processes

4.
M
odular
, loosely coupled, standards based
architecture

4

Elements
of a highly effective system

5

1. Entity
models that allow flexibility


P
ersons


T
ime


L
earning
units


course; single lecture in a course; 15 minute student
presentation in a course


participation in community service


any activity that the student wants to include on a formal or
co
-
curricular transcript


a “learning unit number” is like a SKU...


L
earning
results, learning plans, learning resources


don’t restrict what people and institutions can do


6

2. Work
flow and rules engines


P
rocesses
are represented using workflow, not coded
into the system


R
ules
are represented in rules engines, making them
easier to review and change


O
wnership
of processes and rules moves closer to the
positions and units responsible


W
orkflow
and rules engine technology is reusable and
scalable


process change is easier


7

3. Support
for
Local Business Processes AND..


B
usiness
processes evolve to meet unique institutional
requirements, reflecting the role, student body, and
academic mission


Different
types of institution and different units in
institutions need to do things very differently


E
xisting
practices are often “best practices” for the
institution using them


E
xisting
systems often incorporate someone else’s “best
practices”


system fits many different units and institutions

8

.. AND Easy
to
Change
B
usiness
P
rocesses


Rules
engines for internal process logic


W
orkflow
for end
-
to
-
end business processes


processes can cross systems


E
ncourage
and support innovation and change


It’s
OK to customize.....


your practices, not someone else’s “best practices”

9

4. Modular
,
Standards
B
ased


D
ifferent
institutions can build applications that will work
together


A
pplications
can use different technologies


A
pplications
can be integrated with existing systems


O
pen
source and commercial applications can be
combined


A

critical mass of applications will deliver a next
generation system


deploy what you need, when you need it

10

Specific Objectives


To develop a next generation Student Service System
architecture that follows the principles of Service
-
Orientation, implemented using Web Services.


To develop the Service Contract specifications for the
services required to implement the Student Service
System. This will enable development work to be
completed by a large community, not just the originating
Founders.


To develop, and release for implementation, a software
product consisting of a set of Services that have been
defined to be the core functions of a next generation
Student Service System
-

Kuali Student.


To define and publish standards for development that
can be used by other members of the community to
develop Services that are not within the scope of the
core product.


11

Specific Objectives


To ensure the core Services of Kuali Student are
successfully implemented by the Founding Institutions.


To promote the adoption and implementation of Kuali
Student by a wide variety of educational institutions


within North America and internationally.


To build a community of interest that will sustain future
maintenance, enhancement and development of the
product.


To define product development and support processes
that will be used to assist the community to implement
the software and to provide operational support for the
product.


To continue to evolve the technology and architecture of
Kuali Student over time to keep up with new industry
standards, tool releases and trends.

Technical Principles


These
principles
guide the
full lifecycle of the project
.

1.
SOA
methodology

2.
Rice as the middleware platform

3.
Web
services

4.
Standards
based

5.
Separate
governance process for service contracts

6.
Abstraction
of business process and business rules

7.
Abstraction
of the data
layer

8.
System will be built entirely on an open source software stack

9.
Java
as the language of choice


Guiding Principles

Truly a next generation Student System



Infrastructure: Relies on a modern infrastructure
developed in the Cloud



Separation of UI and Services enables institutions to


Develop their own UIs


Integrate with current systems on campus


Implications

Truly a next generation Student System



Services are designed to accommodate future changes
to business processes.


Front end can change every few years but Service Contracts
are more stable over time



Loose coupling between modules helps institutions


Roll out modules over time


Minimize impact of changes from one module to another


Implications

Layer


Presentation (UI)

17

Kuali

Student
Architecture


Kuali Student


Kuali Rice

Kuali Service Bus (KSB)

Service
Layer/ SOA

Organization

(KOM)

Notification (KEN)

Workflow (KEW)

Rules (KRMS)

Person

(KIM)

Service Implementation

JAXWS/CXF

Service Contract

SOAP

Rapid Application Development Framework (KRAD)

Presentation

Application

Jquery

Spring MVC

Data Access Object (DAO)

JPA/Hibernate, OJB

Persistence

Database

DB Independent

Database


Old::
UI Curriculum Management (CM) was written with
the Google Web Toolkit (GWT)



New::
Enrollment, and the rest of KS UI, has now
moved over to using KRAD (Kuali Rapid Application
Development) as the UI Framework. KRAD is a part of
Kuali Rice



There are currently no plans to fully convert CM from
GWT to KRAD. This will happen over time by the
community

UI Frameworks In Use

CM Application Flow (GWT Based)

CM Application Architecture (GWT Based)

2 possible types of
deployments:


Embedded:

As one giant
application on one machine.
This is typical on a
development machine.


Standalone
(shown here):
UI stack and Rice
middleware are deployed on
different machines. This is a
typical production
deployment.

CM Deployment Topology

Enrollment UI Framework


Rice KRAD

KRAD Technology


Spring MVC


Spring Beans and Expression Language


Apache Tiles as the
templating

engine


Fluid Skinning System for CSS


jQuery

as the
javascript

library


Including
jQuery

UI


And other plugins providing functionality like AJAX



More information about Rice KRAD at
https://wiki.kuali.org/display/KULRICE/Kuali+Rice+
Release+Documentation

KRAD Screenshots


KNS Look and Feel
-

http://bit.ly/
tKDhKa


KS Look and Feel
-

http://bit.ly/
rYCDQy


See lots of other examples by going to the
“Kitchen Sink” at
http://demo.rice.kuali.org


Log in as “admin” user

Layer
-

Services

26

Kuali

Student
Architecture


Kuali Student


Kuali Rice

Kuali Service Bus (KSB)

Service
Layer/ SOA

Organization

(KOM)

Notification (KEN)

Workflow (KEW)

Rules (KRMS)

Person

(KIM)

Service Implementation

JAXWS/CXF

Service Contract

SOAP

Rapid Application Development Framework (KRAD)

Presentation

Application

Jquery

Spring MVC

Data Access Object (DAO)

JPA/Hibernate, OJB

Persistence

Database

DB Independent

Database

Kuali Student has four high level entities

KS

Time

Person

Learning

Unit

Organization

Service Contracts are King

The Database Entity Relation Model is not
^

important.

1.
Interoperability


2.
Stability (& extensibility)


3.
Configurability


Kuali Student SOA
--

Goals

Top Down Approach

Shared

Service Contract

Designs on WIKI

Java Interfaces

with annotations

WSDL

PHP Interface???

REST Interface???

JSON Interface???

Shared

HTML Contract

Documentation

Some Future
Transform

Manually
expressed in Java

Contract
Document

CXF

Service Contracts are the Stable Point

Service
Contracts

As technology moves forward

Interoperability & Stability


Many to Many


Kuali


Student
Service
Contracts

School B

Using KS

Student
Accounting

School A

Using Legacy
Student
Accounts

School A

Using KS

Enrollment

School B

Using Legacy
Enrollment


Types


Simple Inheritance mechanism


States


Lifecycle State of the object


Dictionary


Softcoding Validations


Workflow


Varying Approval Processes


Rules


Configurable Calculations


Configurability & Extensibility

Kuali Student SOA
-

Configurability

Learning
Unit

Credit
Course

Program

(Major,
Minor, etc)

Type
Definition

Class II Service

Class I Service


Class I Services
-

Atomic


Academic Time Period


Comment


Document


Learning Objective


Learning Result Catalog


Learning Unit


Message (labels and errors)


Proposal


Statement (Rules Authoring)


Organization


Enumeration Management


Shared:


Dictionary


Search


Version Management




Class II Services
-

Composite


Course


Program


Class III Contributions


TBD


Class IV
--

RICE Services


KIM


Identity Management


Person


Permission


Roles


Groups


KEW
--

Workflow


KSB


Service Bus




Existing Service Contracts From CM


Class I Services


Learning Unit Instance (LUI)


LUI Person Relation (LPR)


Learning Result Record
(LRR)


Learning Result Definition
(LRD)


Learning Unit Plan (LRP)


Shared:


Types


States




Class II Services


Common (with lots of things)


Academic Calendar


Course Offering


Program Offering


Course Registration


Program Enrollment


Grading


Academic Record


Program Progression


Advising


Learning Plan


Graduation Clearance



Additional Service Contracts for Enrollment


With other SIS Components


Student Financials Interface


Financial Aid Interface


Admissions Interface


Degree Audit Interface


Course Scheduling Interface


Transfer Articulation Interface




Common (with lots of things)


Calendar Interface


Holds Interface


Exemptions Interface


Room Service Interface


With External Systems


LMS Interface


HR Interface


General Ledger (TBD)


Housing (TBD)


Etc…




Other Services for Enrollment (not classified yet)

Middleware


Rice


UI::
Provides UI Framework
-

KRAD



Services::
Provides key middleware Services for
Identity Management (KIM), Enterprise Workflow
(KEW), Rules Management System (KRMS),
Organization Management (future)



Service Bus::
Provides Enterprise Service Bus (KSB)
on which KS Services are hosted


Role of Rice Middleware

Rice Architecture

Rice Deployment Architectures


Stand
-
alone: a central hub and spoke model


Good if you just want to support one Rice server


Centralized services and features


Best for non
-
Java clients


Embedded: a decentralized, federated
approach


Fast for developers because services are local


Distributes load; technically a clustered model


Provides distributed transactions (via JTA)


Hybrid: best of both

KIM Overview


Kuali Identity Management is a misnomer


KIM does not manage identity


Instead it sits between a Identity Management
System (
IdMS
) and your application to provide
security related functions to your application


Authentication


Authorization


It abstracts the proprietary nature of any
IdMS

and provides a Kuali Standard
interface to
IdMS

KIM Architecture


Provides identity and access management services



KIM services are available on the service bus with both SOAP and
Java serialization endpoints


Provides a set of GUIs that you can use to maintain identity
information


Provides reference implementation of Identity related Services


Read
-
only services:


IdentityService


GroupService


PermissionService


RoleService


ResponsibilityService


AuthenticationService


Update services that allow write operations


A permission service that evaluates permissions: KIM provides plug points
for implementing custom logic for permission checking, such as
permission checks based on hierarchical data.



KIM Highlights

KIM
Concepts

Basic concepts


Namespace (i.e. Application, any generic context)


Person
-

different default “sponsored” attributes for each
namespace context; core shared attributes as well


Group
-

simply groups users; arbitrary data associated with
them


Permissions
-

ability to perform actions


Roles
-

cross context capabilities; aggregates permissions (i.e.
fiscal officer, dean, etc)


Qualified Roles
-

specific to a context


fiscal officer for
organization XYZ


dean for the
College of ABC


administrators

for the
College of ABC

<
--

this one’s a group


KEW Overview


Facilitates routing and approval of business
processes throughout an organization


Provides re
-
usable routing rule creation which
defines how business processes should be
routed


Bind business data to users/groups that must
approve


Provides hooks for client applications to handle
workflow lifecycle events of business processes


End users interact with central workflow GUIs
for all client applications


Content
-
based routing engine (“workflow”)


Flow


User creates a document from a process definition



User submits it to the workflow engine


Engine makes routing decisions based on the XML content of the document


KEW is a set of services, APIs, and GUIs with these features:


Action List

for each user, also known as a user’s work list


Document searching


Route log
: Document audit trail


Flexible process definition
: Splits, joins, parallel branches, sub
-
processes, dynamic
process generation


Rules engine


Email notification


Notes and attachments


Wide array of

pluggable components

to customize routing and other pieces of the system


eDocLite
: Framework for creating simple documents quickly


Plugin

architecture
: Packaging and deployment of application
plugins

or deployment of
routing components to the Rice standalone server at runtime



KEW Highlights


A lightweight service bus


Typically, KSB programming is centered on exposing
Spring
-
configured beans to other calling code using a
number of different protocols.


You deploy services to the bus either using the Spring
tool or programmatically


Services must be named when they are deployed to the
bus


Services are acquired from the bus using their name


KSB Highlights

KSB Architecture

KSB Communication Models


Synchronous = P2P : waits for a response


Asynchronous = messaging : fire and forget : possible
callback


Queues = single service retrieved from redundant set of
services; only one invoked


Topics = all services retrieved from redundant set of
services; all invoked

KSB Security


Bus level : option to digitally sign, encrypt


Service level security through Acegi


Service level, method level


User proxying through standard security models (i.e. CAS,
Kerberos)


Security context passed along (user, authn token, roles)


Services can call authn/authz authority to validate context


KRMS is a general
-
purpose business rules engine


Supports the management and execution of business rules needed for
business processes


Used to define a set of rules within a particular business unit or for a particular
set of applications. These business rules test for certain conditions and define
the set of actions that result when conditions are met. KRMS enables you to
call and use this logic from any application, without having to re
-
write and
manage all the rules' logic within the application.


Example, you can define a rule to specify that when an account is closed, a
continuation account must be specified. You can also define rules to manage
your organizational hierarchies and internal structures. You can define
compound rule logic, for example, "Must meet":


P1
-

12 credits of
FirstYearScience

(CLU set)


AND


P2
-

Completed CALC101 with grade >= B+


AND


p3
-

Average of B+ on last 12 credits


KRMS

Rice 2.0 Documentation


http://site.kuali.org/rice/2.0.0
-
rc2/reference/html/Intro_To_Rice.html#d967e295


Kuali Days 2011 Presentations


https://wiki.kuali.org/display/KULRICE/Kuali+Days+201
1+presentations

Rice More Information

Expert Review of Architecture


Recent expert review of architecture validates that
platform


Has a solid foundation



Will be adoptable as production enterprise software



Will run with appropriate availability/scalability



Has no "red flag" issues



Has some areas of concern/improvement which are
being
worked on




Expert Review of Architecture