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

2. 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. 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 Oriented Architecture implemented using Web Services. –To achieve sustainability through community source distribution and wide spread adoption.

4. 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. 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. 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. 7 Founder and Partner Requirements 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

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

9. 9 Program Approach Why do we need to do it differently? Complexity and scale of what we are trying to do requires structure and clear project management. Even more so since we are trying to do it with 5-7 different institutional perspectives. We are fundamentally changing the underlying technical architecture. Re-architecting versus evolving a system requires more up front planning and investment Service Orientation requires an up front investment to achieve the goals of –Service modularity –Service re-usability  Clear methodology and approach  Architecture First !

10. 10 Program Approach A structured approach that is easily understood by all stakeholders is essential to ensure program success. Concepts include: –Well defined phases of approximately 4-6 months each –Clear definition of deliverables at each stage –Phase deliverables should be tangible assets. In case of failure of the entire project, there is still value gained and useable deliverables for the investment –Ownership of deliverables is clearly defined –QA reviews and checkpoints at the end of each phase. –Sign off of phase deliverables as complete –At the end of each phase, the plans for the next phase will be updated based on the new information available. The plans will remain flexible and are modified to meet the realities of the day Agility, Phases, Timeboxes, and Iterations

11. TechnicalFunctional 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) 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 Program Management &Communications Gate Contract Design R2 (Domain 2) Release 1 & Implement Test Re-plan / Re-Architect / Implement & Transition to Support Kuali Student – Phased Modular Approach Develop Configuration Application - Configuration Infrastructure - Proof of Concept Prototype

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

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

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

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

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

17. 17 Technical Architecture

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

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

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

21. 21 Application Architecture

22. 22 Technical Architecture

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

24. 24 Developers Workbench

25. 25 Developers Workbench Run-Time –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) 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) Systems Infrastructure –Application Server (Tomcat, JBoss, Geronimo, Glassfish) –Load Balancing (institution-choice) –Firewall (institution-choice) –LDAP (institution-choice)

26. 26 Stereotype for the UI layer

27. 27 Stereotype for Business Agnostic Service

28. 28 Module Stereotypes 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. 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.

29. 29 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 do we aggregate UI components on the portal? Portal –How will UI components be aggregated in the portal?  A portlet rendered in the portal?  A collection of portlets or channels?

30. 30 Module Stereotypes Security Concerns Authentication Authorization Message Security Authn/Authz are provided by services. Each consumer of a service needs to be authenticated. The figure shows: 1.A call is made to an authentication service that responds with a security context. 2.All POJO’s have access to the context which include: User details Permissions For example, we could use CAS as the authentication provider. Acegi as the framework to provide the security context.

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

32. 32 Security Guidelines 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 3 rd -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

33. 33 Transactional Integrity 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.

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

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

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

37. 37 Prototype Scenarios 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, Infrastructure Services, 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.

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

39. 39 “SOA Development Platform” 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

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