1. Kuali Student Architecture Overview February 2011

2. Kuali Student Architecture
Rapid Application Development Framework (KRAD)
Presentation
Application
Jquery
Spring MVC
Kuali Service Bus (KSB)
Service Layer/ SOA
Organization
(KOM)
Notification (KEN)
Workflow (KEW)
Rules (KRMS)
Person
(KIM)
Service Implementation
JAXWS/CXF
Service Contract
SOAP
Separation of concerns
Deployment flexibility
Data Access Object (DAO)
JPA/Hibernate, OJB
Persistence
Database
DB Independent
Kuali Student
Kuali Rice

3. Architecture Drivers & Philosophy

4. Elements of a highly effective system
New high level entities
Use of workflow and rules engines
Easy to configure to support new rules and processes
Modular, loosely coupled, standards based architecture

5. 1. Entity models that allow flexibility
Persons
Time
Learning 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...
Learning results, learning plans, learning resources
don’t restrict what people and institutions can do

6. 2. Work flow and rules engines
Processes are represented using workflow, not coded into the system
Rules are represented in rules engines, making them easier to review and change
Ownership of processes and rules moves closer to the positions and units responsible
Workflow and rules engine technology is reusable and scalable
process change is easier

7. 3. Support for Local Business Processes AND..
Business 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
Existing practices are often “best practices” for the institution using them
Existing systems often incorporate someone else’s “best practices”
system fits many different units and institutions

8. .. AND Easy to Change Business Processes
Rules engines for internal process logic
Workflow for end-to-end business processes
processes can cross systems
Encourage and support innovation and change
It’s OK to customize.....
your practices, not someone else’s “best practices”

9. 4. Modular, Standards Based
Different institutions can build applications that will work together
Applications can use different technologies
Applications can be integrated with existing systems
Open 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.

12. Technical Principles

13. Guiding Principles
These principles guide the full lifecycle of the project.
SOA methodology
Rice as the middleware platform
Web services
Standards based
Separate governance process for service contracts
Abstraction of business process and business rules
Abstraction of the data layer
System will be built entirely on an open source software stack
Java as the language of choice
SOAD is different from OO in several respects (more emphasis on process and less on domain models)
In theory SOA can be implemented on any platform (RMI, CORBA, DCOM etc). In practice WS is the only realistic alternative
Standards: we do not want to replace vendor lock-in by product lock-in
Governance: because of the enormous importance of service contracts in the SOA we need to pay special attention to the governance process for service contracts
Rules: this is a “made in UBC” variation on SOA. Instead of having business logic encapsulated in individual services, ikt it externalized in a rules engine.
Portal. Unlike our sister projects, Sakai and Kuali financials, we are going to deliver our user interface layer through a portal right from the start.
Data layer.
OS stack: everything from the database to the WS engines and registry must be open source. We cannot be the reseller of a commercial product.
The various frameworks (ORM, MVC) used in the development must also be open source
Lastly, the actual code base is java (open source)

14. Implications 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
Think Course Catalog on Steriods….

15. 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
Think Course Catalog on Steriods….

16. Layer – Presentation (UI)

17. Kuali Student Architecture
Rapid Application Development Framework (KRAD)
Presentation
Application
Jquery
Spring MVC
Kuali Service Bus (KSB)
Service Layer/ SOA
Organization
(KOM)
Notification (KEN)
Workflow (KEW)
Rules (KRMS)
Person
(KIM)
Service Implementation
JAXWS/CXF
Service Contract
SOAP
Separation of concerns
Deployment flexibility
Data Access Object (DAO)
JPA/Hibernate, OJB
Persistence
Database
DB Independent
Kuali Student
Kuali Rice

18. UI Frameworks In Use
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

19. CM Application Flow (GWT Based)

20. CM Application Architecture (GWT Based)

21. CM Deployment Topology
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.

22. Enrollment UI Framework – Rice KRAD

23. 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 Release+Documentation

24. KRAD Screenshots
KNS Look and Feel -
KS Look and Feel -
See lots of other examples by going to the “Kitchen Sink” at
Log in as “admin” user

25. Layer- Services

26. Kuali Student Architecture
Rapid Application Development Framework (KRAD)
Presentation
Application
Jquery
Spring MVC
Kuali Service Bus (KSB)
Service Layer/ SOA
Organization
(KOM)
Notification (KEN)
Workflow (KEW)
Rules (KRMS)
Person
(KIM)
Service Implementation
JAXWS/CXF
Service Contract
SOAP
Separation of concerns
Deployment flexibility
Data Access Object (DAO)
JPA/Hibernate, OJB
Persistence
Database
DB Independent
Kuali Student
Kuali Rice

27. Kuali Student has four high level entitiesKS
Time
Person
Learning
Unit
Organization
Business users were frustrated with their systems.
Tired of the old categories
Time: faculty want to teach more and more in times that are not strictly bound by the semeter model….
But all time can be modeled as Seasonality and duration (cycles within cycles)
Can model Academic Year of semesters and min-mesters and a Four Year Program with freshman, sophomore, junior and senior years
Person: I’m a student, not an employee, oops yes I am,
I’m an employee not an alumni, oops yes I am
I’m an alumni but not a parent, oops yes I am
I’m a parent but not a faculty member, oops yes I am…
Orgs: Old way Academic Department table but then something that is not a department can offer course so we have to stick the “writng office” in as an academic department.
Learning Unit: A course is a course of course of course… except when it is not a course… it’s an internship or a thesis or a research project a competition or….
 Most important thing in college career is often not a course but that internship or that competition
For years we have been jamming things into the “course structure” and calling it a course because our systems are in-capable of supporting any other kind of learning unit

28. Service Contracts are King
We do have an ERD and we do care about the details especially for performance reasons but… as
The Database Entity Relation Model is not ^ important.

29. Kuali Student SOA -- Goals
Interoperability
Stability (& extensibility)
Configurability
Note that Usability by programmers is (a) on the list but (b) way down at number 4...  So don't expect the service contracts to do everything exactly HOW you would want it to be done to make your life easier.

30. Top Down Approach Shared Service Contract Designs on WIKI
Manually expressed in Java
Java Interfaces
with annotations
Some Future Transform
Contract Document
CXF
The KS SOAD methodology is an adaptation of both the IBM and Thomas Erl approaches.
In particular, it was modified to be more agile, not requiring complete agreement at each level before moving to the lower level of analysis.
This was particularly important to allow us to model the diverse processes of each of the participating institutions.
PHP Interface???
REST Interface???
JSON Interface???
Shared
HTML Contract
Documentation
WSDL

31. Service Contracts are the Stable Point
User Interface
Implementation
Service Contracts
These next slides show the point of interoperability and stability
As technology moves forward

32. Interoperability & Stability
Many to Many
School B
Using KS
Student Accounting
School A
Using KS
Enrollment
Kuali
Student Service Contracts
School A
Using Legacy Student Accounts
Adapter
School B
Using Legacy Enrollment
Adapter
The service contracts allow schools to adopt KS in an incremental fashion

33. Configurability & Extensibility
Types – Simple Inheritance mechanism
States – Lifecycle State of the object
Dictionary – Softcoding Validations
Workflow – Varying Approval Processes
Rules – Configurable Calculations
This is how we achieve extensibility and configurability
Contracts do NOT define the length and detailed enumerations of a field… that is left to the dictionary

34. Kuali Student SOA - Configurability
Class II Service
Credit Course
Class I Service
Learning Unit
Type Definition
Program
(Major, Minor, etc)
Types and Dictionary control the expression of learning unit as either a course or a type of program

35. Existing Service Contracts From CM
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
Different governance structure
Different implementation rules
Class I
Part of KS proper
Single focus, self-contained = atomic
May or may not be "business-speak"
Expect they will be the most stable and therefore have the most rigorous governance
Examples include: LU Service, Learning Objective Service, Learning Result Catalog Service, Comment Service, and Document Service
Class II
Composed services than may refer to more than one underlying Class I service = composite
Described in terminology that can be understood (and validated) by business users/analysts
Expect they will change as institutions adopt them. The changes will be requested through KS change management process and done by KS service team.
Examples include: Course Service, Program Service
Class III
KS Contributions
Not part of KS proper but may become so
Examples include: Living Learning Service that UMD may develop
Class IV
RICE services
Not part of KS but part of Kuali
Governance controlled by Kuali Working Groups
Examples include: KEW interfaces, KIM interfaces

36. Additional Service Contracts for Enrollment
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

37. Other Services for Enrollment (not classified yet)
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…
Interface things….

38. Middleware– Rice

39. Role of Rice Middleware
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
Interface things….

40. Rice Architecture

41. 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

42. 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

43. KIM Architecture

44. KIM Highlights 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.

45. 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

46. 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
2a) Only a fiscal officer is allowed to approve certain documents
fiscal office is just a user that in that role, and a rule is just a criteria
that checks if the user matches FO

47. KEW Highlights 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
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

48. KSB 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

49. KSB Architecture Explain
- Connectors : Allows any application, not just Kuali apps, to connect to the bus for services
- Exporters : An easy way for rice-enabled apps to put services on the bus
- Bridges : A way for non-Kuali services to use the KSB to export their services and get the QoS provided by KSB
Mention
- Security : Hit key points. More details in a few slides
- Transformation : messages can be changed on the way in and on the way out of the bus. This makes
it so that all types of message can play.
- Backbone : more to come

50. 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

51. 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
1) Example: KRA asks for service A from the KSB. Service A need to talk to Service B and C.
A talking to B and C can optionally use bus security to ensure authentication. Authorization
is then up to the services.

52. KRMS 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":
P credits of FirstYearScience (CLU set)
AND
P2 - Completed CALC101 with grade >= B+
p3 - Average of B+ on last 12 credits

53. Rice More Information Rice 2.0 Documentation
rc2/reference/html/Intro_To_Rice.html#d967e295
Kuali Days 2011 Presentations
1+presentations

54. Expert Review of Architecture

55. 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
Think Course Catalog on Steriods….