Kuali Student Service System

1. Kuali Student Service System “A SOA Development Platform” June 27, 2007

2. Background • Many institutions finding that their student systems no longer meet their needs • Vendor solutions are expensive and do not provide the functionality that custom solutions do today • Ability to continue to develop in-house systems is declining • Increasingly complex technology requires specialist resources • Competing for the same IT resources in a constrained market • User requirements and expectations increasing exponentially • Budgets and funding constrained • Institutions looking to a collaboration and open source system development to solve these problems • Feasibility Study conducted in early 2006 • Workshops to explore possibilities with partners in late 2006 • Founding institutions for Kuali Student - February 2007

3. Kuali Student Vision • A Next Generation Student System: • 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 OrientedArchitecture implemented using Web Services. • To achieve sustainability through community source distribution and wide spread adoption.

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

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

6. Founder & 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

7. Founder Align with the vision ~$1 million / year for 5 years in staff or cash resources 2 senior reps on the Board Representation on the Technical and Functional Steering Committees Commit to implement most modules Adhere to the governance of the Project Charter Active advocate to the community Partner Align with the vision Allocate resources to the project (typically 2 or 3 staff) Not represented on the Board May have a representative on the Technical and/or Functional Steering Committee May commit to implement one or more modules Adhere to the governance of the Project Charter Active advocate to the community Founder and Partner Requirements

8. Kuali Student Board CIOs* Registrars* Chair Ted Dodds Extended Board AACRAO Mellon Foundation Kuali Foundation Partners Kuali Student Service System Team Organization – Architectural Phase *Functional Steering Committee Chair: Audrey Lindsay *Technical Steering Committee Chair: Leo Fernig Program Director Cath Fairlie General Institutional Resources ** QA Manager Configuration Manager UI Expert Documentation Coordinator Project Analyst/Admin Program Communications Services / Application Architect / (Project Manager) Gord Uyeda Chief Technical Architect / (Project Manager)Leo Fernig 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 – Phased Modular Approach Functional Technical 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 Prototype 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

10. 10 Guiding Technical Principles • 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.

11. 10 Guiding Technical Principles • 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 286 (portlet), JSR 94 (rules)… • Accessibility Standards • Internationalization standards

12. 10 Guiding Technical Principles • 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.

13. Application Architecture

14. Component Abstraction • Interface (UI) components will be abstracted from the orchestration layer and the business service layer. • Kuali Student will be delivered through an existing open source portal product to allow abstraction of the presentation layer. • Business rules and business process logic will be abstracted from the code base. • Rules engines are the preferred vehicles for abstracting business rules • Workflow and BPEL engines are the preferred vehicles for abstracting business process logic. • Abstraction of the Data Layer • Kuali Student’s data model will be derived from simple abstractions such as time, people, learning units, and learning results. • Data access will be abstracted in the data layer to provide database independence • Data access will be abstracted through an ORM framework and as a rule it will be services that provide data

15. Technical Architecture Principles • Kuali Student Will Be Built Entirely On An Open Source Software Stack • Compatible with the outbound Educational Community License (ECL) • Reference distributions of Kuali Student are entirely open source. • It is not within the scope of Kuali Student to build infrastructure components. • Kuali Student will use existing open source products for BPEL engines, an Enterprise Service Bus, Workflow and Rules Engine Technology and UI frameworks, although the technical team may need to develop web service wrappers for existing products. • Code that is written as part of the core Kuali Student product should be written in Java and Java will be the platform of choice for Kuali Student.

16. Technical Architecture

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

18. Developers Workbench

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

20. Stereotype for the UI layer

21. Stereotype for Business Agnostic Service

22. Other Considerations • Other Technical Architecture Considerations to be solved and implemented within the module stereotypes. • Security Guidelines • Transactional Integrity • Standards • Solve these problems once so the developers can focus on business requirements and solutions

23. Deployment Landscape • All services must be able to be deployed remotely without change to code or architecture. • Implementers must have flexibility in making deployment decisions based on performance, security, and cost. • Need to design and configure the Systems Infrastructure for the DEV, TEST, QA, PROD environments to accommodate and test this flexibility • The development environment should be as simple as possible

24. Configuration Application • A set of core infrastructure services for an enterprise application: • The Data Dictionary Service • The Search Service • The Rules Definition Service • The Process Configuration Service • The Security Configuration Service

25. Challenges • Complexity • WSDL, SOAP, ORM, BPEL, Rules, Stubs & Skeletons, POJOs, Binding, … • Monitoring and managing SOA applications. • Requirement for a large investment in infrastructure management. • Performance • SOA and Web services put a strain on all parts of the infrastructure • Working in a virtual world with a virtual organization • Communication • Management • Daily progresses

26. A virtual organization working with collaboration tools A working prototype An application to configure the component abstractions A Developers Workbench A Service-Oriented Architecture with an integrated Web Services Stack “SOA Development Platform”

27. Questions? • Reference information: • www.student.osnext.org • Information through late 2006 when founders were first identified. • Notes on meetings, conference presentations, meetings with vendors, etc. • www.educationscommons.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 at www.kuali.org