Kuali Student Service System

1. Kuali Student Service System Where We Are Where We’re Going David S Alderson dalderso@umd.edu JA-SIG Conference, Denver June 2007

2. Founders and Partners • Founders • University of British Columbia (Lead) • University of Maryland College Park • Florida State University • University of California, Berkeley • San Joaquin Delta College • Partners • Massachusetts Institute of Technology • Carnegie Mellon University

3. Kuali Student Vision • To provide person centric services that support students and other users by anticipating their needs and reducing the time it takes to complete administrative tasks. • To support a wide range of learners and learning activities in a wide range of institutions by using a flexible, configurable, data model. • To support a wide range of academic and related business processes, including those that cross departments, systems and institutions, in ways that work best for each institution, by using rules based business logic, and configurable processes. • To ensure a modular design by using a Service Oriented Architecture implemented using Web Services. • To achieve sustainability through community source distribution and wide spread adoption.

4. Educational Community License – ECL V2.0 Kuali Student will be built entirely on an open source software stack compatible with the outbound Educational Community License (ECL). Kuali Student will adhere to the Kuali Foundation’s IP management policies for inbound licensing and assessment of 3rd-party licenses Licensing

5. Founder Commitment • Align with the vision of Kuali Student • Contribute at least $1,000,000 per year, in cash and/or staff resources, for the 5 year period of July 2007 – June 2012. • Adhere to the governance structure, decision-making processes, and project management disciplines, including the service oriented analysis methodology as laid out in the Program Charter. • Commit to run most or all modules of the core product in production. • Designate senior representatives for the Program Board that will direct program resources. • Use the Educational Community License for all work products created by the core members. • Be an active advocate for the Program, including executive level communications to the community. • Develop appropriate local expertise in Service Oriented Architecture.

6. Partner Commitment • Align with the vision of Kuali Student • Allocate resources, in the form of cash and/or staff, toward the development of Kuali Student. The development resources may be allocated to core system scope undertaken by the Founders or may be allocated to modules complementary to the core system scope. • May commit to implementing one or more Kuali Student modules (core or non-core) in production. • Participate on either the Technical or Functional Steering Committees – attending scheduled meetings. • Participate in workshops to ensure the Kuali Student System meets the needs of the broadest possible community • Use the Educational Community License for all work products • Act as an advocate for the Program.

7. History • student.osnext.org • Information through late 2006 when founders were first identified. • Notes on meetings, conference presentations, meetings with vendors, etc. • educationcommons.org • Various workshops held during 2006. • SOA, service, entity, and business process modeling, in-depth review of Kuali components. • Soon: public Web site for Kuali Student

8. Kuali Student Service System Team Organization – Architectural Phase Kuali Student Board CIOs* Registrars* Extended Board AACRAO Mellon Foundation Kuali Foundation *Functional Steering Committee *Technical Steering Committee Program Director General Institutional Resources ** QA Manager Configuration Manager UI Expert Documentation Coordinator Project Analyst/Admin Program Communications Services / Application Architect / (Project Manager) Chief Technical Architect / (Project Manager) Business Analysts Lead Subject Matter Experts* Technologists (or Lead Developers)* Development Infrastructure Systems Infrastructure DBA Security Subject Matter Experts* * Representation from each Founding Institution ** May be consulted from time to time during Architectural Phase

9. Kuali Student Service System Team Organization – Development Phase Kuali Student Board CIOs* Registrars* Extended Board AACRAO Mellon Foundation Kuali Foundation *Functional Steering Committee *Technical Steering Committee Program Director Development Node Resources Project Manager Program Wide Resources Chief Technical Architect Services Architect QA Manager Configuration Manager UI Expert Program Communications Documentation Coordinator Project Analyst/Admin Module Teams Lead Subject Matter Expert Lead Developer Development Infrastructure Systems Infrastructure DBA Security Business Analyst Testing Coordinator Subject Matter Experts* Testers* Developers *Representation from each Founding Institution

10. Scope Tier 1 – Critical Core Components Curriculum Development Customer Contact Enrollment Degree Audit/Academic Evaluation Student Financials Concierge (data collection) Application Connectors (e.g., Package Systems in Tier 2, FMS, Facilities, etc.) Data Marts and Reports for Tier 1 Tier 2 – Core, But Will Be Addressed Later • Admissions • Scheduling • Awards and Financial Aid • Concierge Application • Data Marts for Tier 2 Tier 3 - Out of scope for founders, may be developed by others • Recruitment, Event Management, Housing, Athletics, Alumni, Family Financial Planning, Elections, Student Life Out of Scope • Campus Calendar, Portfolio, LMS, Facilities Mgmt, Library, Parking

11. What’s First? Our Very Own Magic Quadrant Enrolment Awards Admissions StudentFinancials Customer Contact Risk Degree Audit Scheduling Concierge Curriculum Development Value to Community (Founding Institutions) Core Person & Group Mgmt Person & Group Relationships/Communication Configuration Services Curriculum Development Learning Unit Reporting Tech Arch Security Portal Web services Database Etc.

12. Phased, Modular Approach Functional (Users & IT Functional) Technical (IT Architects & Developers) Jul 2007 Nov 2007 Dec 2007 Apr 2008 May 2008 Sep 2008 Oct 2008 Mar 2009 Apr 2009 May 2009 Jun 2009 July 2009 • Application Architecture • - Business Requirements • Process models • ER models • High Level Service Models • Technical Architecture • Technology proofs • SOA standards Service Modeling R1 (Infrastructure and Cur. Dev.) • Development Infrastructure • Developers workbench • Procedures • Standards Contract Design R1 (Infrastructure & Domain 1) • Develop Configuration • Application • Configuration Infrastructure • Proof of concept Pilot Program Management &Communications Gate Service Modeling R2 (Domain 2) Software Design & Development R1 (Infrastructure and Cur. Dev.) Adjust plans and repeat for Releases 2/3/4 One Release every 8 months Contract Design R2 (Domain 2) Release 1 & Implement Test Re-plan / Re-Architect / Implement & Transition to Support

13. Highest Level Phases – Schedule and Checkpoint Strategy Invest in Architecture Phase Invest for 2 years – Develop Tier 1 functionality Year 1 Gate If decide not to proceed, tangible assets can be used for in-house development If partnerships fail – take code in-house and continue with development – assets not lost Assess if additional partners are needed to participate in development of remaining functionality Build Community of Adopters Year 3 Gate Invest for 2 years – Develop Tier 2 functionality with Partners At end of year 5 move to community sustainment model – adopters help fund the on-going enhancements If community fails – take code in-house and continue with development – assets not lost Year 5 Gate

14. Technology Risk (9) Business Analysis Risk (SOA) (9) Lack of Appropriate Skills (9) Failure of the Partnership (6) Size, Scope, and Complexity (6) SOA Top-Down (6) Standards Compliance (6) SME Staff Availability (6) Budget / Cost Estimates (6) Funding (6) Departure of Key Members (Board, Steering, other) (6) The Big Risks (RI = 6+)

15. 10 Guiding Technical Principles • Service Oriented Architecture • SOA Methodology • Web Services • Standards Based • Separate Governance Process for Service Contracts • Component Abstraction • Business Process and Business Rules • Presentation Layer and Use of Open Source Portal • Data Layer • Leveraging of Open Source • System Will Be Built Entirely on an Open Source Software Stack • Infrastructure Will Be Composed of Existing Open Source Products • Development • Java as the Language and Platform of Choice

16. Service Oriented Architecture • SOA Methodology • Greater emphasis on up-front design of entities and service contracts (top-down). • The artifacts of the design phase are entity models and service definitions. • Services should be autonomous; they are not controlled or constrained by another service and therefore may run remotely. This is a strong bias; there will be cases where this is impractical for performance, security, or other reasons. • Services should be loosely coupled; they are modeled and exposed through an interface that is separate from its implementation. Through loose-coupling, services can by implemented in any environment as long as implementation fulfills the service contract. • There is a high degree of emphasis placed on the identification of re-usable services.

17. Service Oriented Architecture • Web Services • The preferred implementation of the SOA is Web services. • They are simple, universal, and platform neutral. • Web services means SOAP and WSDL. • “XML is the platform.” • Standards Based • Kuali Student will follow open standards wherever feasible, and in the following areas (and others where applicable): • W3C Web services framework • WS-* • Industry standards such as PESC-AACRAO • Java community standards such as JSR 168 (portlet), JSR 94 (rules), etc. • Internationalization standards

18. Service Oriented Architecture • Separate Governance Process for Service Contracts • Service contracts are the business assets of an SOA-based system, are the public definition of the system, and must be the most stable part of the system. • The governing body has representation from each service domain, the involved business units, and technical subject matter experts. • Management of service contracts may be extended to external contracts. • Service contracts created by an institution (e.g., for purposes of customization, or for the purposes of consumption of external services) will be maintained by the institution.

19. 10 Guiding Technical Principles • Service Oriented Architecture • SOA Methodology • Web Services • Standards Based • Separate Governance Process for Service Contracts • Component Abstraction • Business Process and Business Rules • Presentation Layer and Use of Open Source Portal • Data Layer • Leveraging of Open Source • System Will Be Built Entirely on an Open Source Software Stack • Infrastructure Will Be Composed of Existing Open Source Products • Development • Java as the Language and Platform of Choice

20. Component Abstraction / SOA Layers

21. 10 Guiding Technical Principles • Service Oriented Architecture • SOA Methodology • Web Services • Standards Based • Separate Governance Process for Service Contracts • Component Abstraction • Business Process and Business Rules • Presentation Layer and Use of Open Source Portal • Data Layer • Leveraging of Open Source • System Will Be Built Entirely on an Open Source Software Stack • Infrastructure Will Be Composed of Existing Open Source Products • Development • Java as the Language and Platform of Choice Note: development environment not constrained to all open source

22. SOA / Web Services Stack Web Services Engine (Axis 2, Xfire, JAX-WS, Spring WS, JBoss WS) Rules Engine (JBoss Rules, Open Rules) Orchestration & Workflow (KEW, jBPM, BPMScript, Intalio, Agila, Pi-Calculus) Service Registry (jUDDI, Infravio, UDDI) Authentication and Authorization (CAS, Acegi, JAAS) Data Binding Tools (jibx, Castor, JaxB) ESB (KSB, ServiceMix, JBoss ESB, Mule, Open ESB, Celtix) Portal (uPortal) ORM Tools (Hibernate, OJB, TopLink, Castor JDO, Ibatis, Torque, Jaxor) Database (mySQL) Infrastructure Components (incomplete) Application Server (Tomcat, JBoss, Geronimo, Glassfish) Load Balancing (institution-choice) Firewall (institution-choice) LDAP (institution-choice) Leveraging Open Source

23. 10 Guiding Technical Principles • Service Oriented Architecture • SOA Methodology • Web Services • Standards Based • Separate Governance Process for Service Contracts • Component Abstraction • Business Process and Business Rules • Presentation Layer and Use of Open Source Portal • Data Layer • Leveraging of Open Source • System Will Be Built Entirely on an Open Source Software Stack • Infrastructure Will Be Composed of Existing Open Source Products • Development • Java as the Language and Platform of Choice Note: development environment not constrained to all open source

24. MVC / Presentation Layer Framework (Spring, Struts, JSF) ORM Tools (Hibernate, OJB, TopLink, Castor JDO, Ibatis, Torque, Jaxor) User Interface Toolkits (Dojo) Development Environment (Eclipse and Plug-Ins) Source Code Management (Subversion, Aegis, GNU-Arch, CVS) Build Tools (Maven, Ant) Design Tools (MagicDraw) Development Tools and Frameworks

25. Technical Architecture Functional (Users & IT Functional) Technical (IT Architects & Developers) Jul 2007 Nov 2007 Dec 2007 Apr 2008 May 2008 Sep 2008 Oct 2008 Mar 2009 Apr 2009 May 2009 Jun 2009 July 2009 • Application Architecture • - Business Requirements • Process models • ER models • High Level Service Models • Technical Architecture • Technology proofs • SOA standards Service Modeling R1 (Infrastructure and Cur. Dev.) • Development Infrastructure • Developers workbench • Procedures • Standards Contract Design R1 (Infrastructure & Domain 1) • Develop Configuration • Application • Configuration Infrastructure • Proof of concept Pilot Program Management &Communications Gate Service Modeling R2 (Domain 2) Software Design & Development R1 (Infrastructure and Cur. Dev.) Adjust plans and repeat for Releases 2/3/4 One Release every 8 months Contract Design R2 (Domain 2) Release 1 & Implement Test Re-plan / Re-Architect / Implement & Transition to Support

26. Product Selection Criteria Product Space Security Guidelines Transactional Integrity Module Stereotypes Deployment Guidelines Standards Scenario Criteria Technical Architecture

27. Phase I – Quick Assessment Licensing Standards Adopters Supporting Organization Implementation Language and Environment Last Stable Version Internationalization / Localization 3rd-party Reviews Books Published About Software Followed by Industry Analysts Product Selection Criteria

28. Phase II – In-Depth Assessment Externals Functionality Usability Internals Quality Security Architecture Standards and Interoperability Scalability Performance Tools Integration and Plug-Ins Support Community Adoption Organization Longevity and Ongoing Reputation and Professionalism Note: There will be a bias towards other Kuali-based components in the evaluation of products. Product Selection Criteria

29. Product Selection Criteria Product Space Security Guidelines Transactional Integrity Module Stereotypes Deployment Guidelines Standards Scenario Criteria Technical Architecture

30. The SOA Stack

31. Run-Time Web Services Engine (Axis 2, Xfire, JAX-WS, Spring WS, JBoss WS) Rules Engine (JBoss Rules, Open Rules) Orchestration & Workflow (KEW, jBPM, BPMScript, Intalio, Agila, Pi-Calculus) Service Registry (jUDDI, Infravio, UDDI) Authentication and Authorization (CAS, Acegi, JAAS) Data Binding Tools (jibx, Castor, JaxB) ESB (KSB, ServiceMix, JBoss ESB, Mule, Open ESB, Celtix) Portal (uPortal) Database (mySQL) Development MVC / Presentation Layer Framework (Spring, Struts, JSF) ORM Tools (Hibernate, OJB, TopLink, Castor JDO, Ibatis, Torque, Jaxor) User Interface Toolkits (Dojo) Development Environment (Eclipse and Plug-Ins) Source Code Management (Subversion, Aegis, GNU-Arch, CVS) Build Tools (Maven, Ant) Design Tools (MagicDraw) Infrastructure (incomplete) Application Server (Tomcat, JBoss, Geronimo, Glassfish) Load Balancing (institution-choice) Firewall (institution-choice) LDAP (institution-choice) Stacks and Tools (revisited)

32. Product Selection Criteria Product Space Security Guidelines Transactional Integrity Module Stereotypes Deployment Guidelines Standards Scenario Criteria Technical Architecture

33. Assumptions The network is not secure. Any information going over the network needs to be encrypted. For this project TLS cryptographic algorithms are sufficient. There is no need for a proxy; i.e., there are no services we do not trust with the information we send to it. The issue of security domains is not yet resolved; we need to determine how Kuali Student will work with other domains such as Sakai, Kuali Financials, and 3rd-party systems. Legacy systems will be accessed through a service layer in which security is the responsibility of the implementer. Security is managed at three levels Transport (e.g., https) Service (e.g., WS-Security) Application (e.g., authorization) Security Issues to be addressed Authentication Authorization (strong need for federation) Privacy and Integrity Non-repudiation Security Guidelines

34. Product Selection Criteria Product Space Security Guidelines Transactional Integrity Module Stereotypes Deployment Guidelines Standards Scenario Criteria Technical Architecture

35. WS-Coordination Provides context management Is asynchronous by default WS-Transaction Is layered upon WS-Coordination, which is asynchronous. Extends WS-Coordination to provide a transaction context. Augments WS-Coordination activation and registration services to build a fully-fledged transaction coordinator. Control relationship between service and participant through API such as JAXTX WS-Transaction Models Atomic Transactions Short duration interactions Similar to traditional transaction systems ACID Properties Atomicity – Success and commit or failure and rollback. Consistency - Transactions produce consistent results and preserve application specific invariants. Isolation – Intermediate states not visible to others; appearance of serial execution; achieved by locking. Durability – Effects of a committed transaction are not lost. Can be nested Not suitable for long-lived transactions (minutes, hours, days, weeks, …) Business Activities For long running computations, loosely coupled systems, and components that do not share data, location or administration. Rather than rollback, uses compensation techniques to restore state. How compensation takes place is not WS-Transaction responsibility, but is that of the services. Transactional Integrity

36. Product Selection Criteria Product Space Security Guidelines Transactional Integrity Module Stereotypes Deployment Guidelines Standards Scenario Criteria Technical Architecture

37. Typical Business Service Input messages is an XML Document Axis can handle security and other SOAP headers. Process logging on input and output. XML data is bound via JIBX or other. Logging, caching, etc. handled by Spring AOP. Business Rules handled by rules engine. Module Stereotypes Typical User Interface Module • Dispatcher receives request which is handed to the controller. • The controller executes business logic. • The model is mapped to a view which is returned to the user as the response.

38. Module Stereotypes Differences in the SOA World • The controller will be interacting with one or more Web services. • The view template may be built dynamically by invoking services that return components. Questions • Can a BPEL or workflow engine be one of the services called? Can it serve in some cases as the controller or view resolver? • Should a framework such as Spring MVC be used for the MVC pattern? • If so, how do we integrate Ajax? • Is the MVC component now on the client? • How will UI components be aggregated in the portal? • A portlet rendered in the portal? • A collection of portlets or channels?

39. Product Selection Criteria Product Space Security Guidelines Transactional Integrity Module Stereotypes Deployment Guidelines Standards Scenario Criteria Technical Architecture

40. All services must be able to be deployed remotely without change to code or architecture. Implementers must have flexibility in making deploymentdecisions based on performance, security, and cost. The development environment should be as simple as possible. Strategy Every service and user interface component has its own deploy and build script.This means that Kuali Student is a collection of many small builds rather that the one large build script in a traditional J2EE application. There is a service registry entry for each environment (production, test, each developer’s sandbox). There is a registry of service consumers (a list of dependencies, or a map of operations being invoked by each service). This will help keep track of which services need to be changed when a service contract changes. Developers may work on a single service (e.g., within their sandbox) and connect to any services they need in other environment(s). The purpose is to allow developers to test individual services without requiring they have the entire Kuali Student on their machine (they do need connectivity to the other services however). The Apache release naming convention will be used; however, in the SOA context, release numbers are pushed down from the overall Kuali release number. Deployment Guidelines

41. Developer’s sandbox example Joe is going to change the implementation of Service C. Joe checks out the code for Service C and the build file for Service C. Joe changes the registry for his sandbox to point to Service C on his computer (Joescomputer:7180/webservices/serviceC) Note that Service C appears in three environments: Production Test Joe’s sandbox Deployment Guidelines

42. Product Selection Criteria Product Space Security Guidelines Transactional Integrity Module Stereotypes Deployment Guidelines Standards Scenario Criteria Technical Architecture

43. Standards • We do not want to replace vendor lock-in with product lock-in. • We do want to promote modularity, plug-and-play, and maintain the ability to switch out technology down the road when necessary. • We will accomplish this by • Choosing products that are standards-compliant. • Following standards in development and implementation.

44. Product Selection Criteria Product Space Security Guidelines Transactional Integrity Module Stereotypes Deployment Guidelines Standards Scenario Criteria Technical Architecture

45. Scenario Criteria • In order to test the proof-of-concepts and the evolving modules, testing scenarios need to be developed that are wide and deep. • Depth • Test the SOA layers (UI, Orchestration, Business Services, Orchestration, Infrastructure Services, Connectors, Data Services). • Test the SOA Stack (Web services, AuthN/AuthZ, Business Rules Engine, BPEL/Workflow, Registry, Enterprise Service Bus, Portal, Configuration/Dynamic Data Dictionary, Database). • Width • Core abstractions (Person, Time, Learning Unit, …). • Wide range of functional requirements the represents the scope. • Connectors to external systems. • Best scenarios are those that developers are familiar with, although this may be difficult for every module. • Should help functional users visualize the system as it evolves rather than waiting for the module to be completed.

46. Application Architecture Functional (Users & IT Functional) Technical (IT Architects & Developers) Jul 2007 Nov 2007 Dec 2007 Apr 2008 May 2008 Sep 2008 Oct 2008 Mar 2009 Apr 2009 May 2009 Jun 2009 July 2009 • Application Architecture • - Business Requirements • Process models • ER models • High Level Service Models • Technical Architecture • Technology proofs • SOA standards Service Modeling R1 (Infrastructure and Cur. Dev.) • Development Infrastructure • Developers workbench • Procedures • Standards Contract Design R1 (Infrastructure & Domain 1) • Develop Configuration • Application • Configuration Infrastructure • Proof of concept Pilot Program Management &Communications Gate Service Modeling R2 (Domain 2) Software Design & Development R1 (Infrastructure and Cur. Dev.) Adjust plans and repeat for Releases 2/3/4 One Release every 8 months Contract Design R2 (Domain 2) Release 1 & Implement Test Re-plan / Re-Architect / Implement & Transition to Support

47. Person Eliminate limitations of existing systems by recognizing that person is a high level entity and each may have multiple roles, associations, groups membership, etc. Time Start and end on any date and time. Each time unit has a unique identifier and time units (e.g., a class) may be nested within other units (e.g., a semester). Eliminates traditional boundaries such as fixed semesters. Learning Unit Idea borrowed from inventory management: LUN (Learning Unit Number). Learning units may be programs, specializations, courses, sections, individual contributions, etc. and may manage all credit and non-credit activities. Learning Result Represent any information about a student’s learning accomplishments. Can be very fine grained (an essay result) or coarse grained (a course grade, language proficiency, etc.). Learning Plan Current collection of information about a student’s learning accomplishments, activities, and intentions. Learning Resources A resource that is required to make learning units available. High Level Entities (Core Abstractions)

48. Requirements will be made up of: Archetypal cases A few cases that cover a majority. Attempt to come close to the 80/20 rule. Edge cases Cases that are radically different. Helps institutions work with trouble spots. The reference implementation will be delivered with business rules and orchestration made up of: A few archetypal templates Edge-case templates Requirements, Use Cases, Reference Implementation

49. Application Architecture a high level Service Oriented Analysis and Design of the entire student domain • Goals: • Discover cross-cutting services within entire system domain • Produce models to facilitate communication and understanding

50. Application ArchitectureEntire Student Domain User Signoff Signoff Use Case 3.8 partition Services Into Applications and Domains Object Model Interviews & Workshops 3.2 create Business Process Model Business Process model Service Stack diagram Service Definition 3.6 map Institutional Requirements to Kuali Features 3.9 validate against Concierge Design Principles 3.7 identify Service Candidates 3.1 create Conceptual Object Model 3.3 gather Institutional Specific Requirements (institutional responsibility) 3.4 collect and document Use Cases Existing Documentation Swim Lane diagram 3.5 Identify Rules Test Cases 3.5 Identify Data Abstraction Test Cases 3.5 Identify Orchestration Test Cases Service X-Refs diagram inputs outputs