Kuali Student Architecture Overview February 2011

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

Architecture Drivers & Philosophy

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

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

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

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

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

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

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.

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

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)

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

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

Layer – Presentation (UI)

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

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

CM Application Flow (GWT Based)

CM Application Architecture (GWT Based)

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.

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

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

Kuali Student has four high level entities KS 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

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.

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.

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

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

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

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

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

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

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

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

Middleware– Rice

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

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

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.

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

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

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

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

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

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

Rice More Information 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

Expert Review of Architecture

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