Imagining a Community Source Student Services System

1. Imagining a Community Source Student Services System Leo Fernig Richard Spencer SOA Workshop Vancouver March 24, 2006

2. Community Source Objectives • Greater control over the future of our systems • Leverage the capabilities of our developers • Increase our ability to meet the needs of users • Combine components from different schools • Combine open source and commercial components • Use commercial service providers to implement and support some systems and system components

3. Challenges • Agreeing on standards • Project design and management • Integrating components with existing systems • Combining components built by different teams

4. Some concepts for enterprise systems

5. Goals for enterprise systems • Scalable, rule based, self-service processes • Focus on needs of end users (not just staff in central departments) • Retain departmental stewardship of systems • HR, Finance, Plant, Admissions, Registrars, etc. • An architecture that • supports different academic and business processes • supports complete business processes • allows business processes to easily span systems

6. Shared Enterprise Services • Portal • Identity • Workflow • Decision • Data • Communication • Scheduling and resource optimization

7. Portal • Provide access to all enterprise systems • Users can customize some things • Systems can personalize for users • Channels available to, and used by, all systems • Primary means of presenting information to users • Manage logon to and logoff from systems

8. Identity • Meta directory of basic identity information • References to multiple repositories • Authentication and authorization • for users and applications • Role and group management • role based access to systems and services • decentralized administration of roles and groups • Represent organizational structures • academic and administrative • Support federation

9. Workflow • Available to all applications • Uses roles and organizational structure from identity management system • understands delegated authority • Easy to configure • Applies rules to processes • Handles cross system and cross silo processes • Directs work to positions where decisions are required

10. Some concepts for student systems

11. Goals for student systems • Focus on the end user • expand choices, simplify selection • Use enterprise service • Use internal rules engines (decision services) • Provide maximum configuration flexibility • aim: could system handle any variation we can think of? (i.e. accommodate “our” practices) • not: which subset of the various approaches will be supported (i.e. not just support “best” practice) • Extend it into the research and other domains?

12. Entity model Looking for the right level of abstraction.. • People • Groups • Learning units (knowledge discovery units?) • Learning results • Resources • Rules Also • enrolments; interactions

13. The layers of the Student Service System

14. Portal The layers of the Student Service System

15. The layers of the Student Service System Processes

16. The layers of the Student Service System Service bus

17. The layers of the Student Service System Services

18. Business drivers • Unmediated interactions • Transparency • Flexibility • Technology solution • Rules engine technology • Rules authoring software Rules engines

19. Step 1: Confirm the identity of the user and get their permissions An example process

20. Step 2: Get the student’s academic record An example process

21. Step 3: Do an evaluation to see if they meet the institutions admissions requirements An example process

22. Step 4: Communicate the result to the applicant An example process

23. The layers of the Student Service System Core software stack

24. It is now possible to run an extremely large transactional • system entirely on license free software • OS Linux • J2EE container JBoss • HTTP server Apache • Soap server Axis (Apache) • DB MySQL, PostgreSQL • More important: standards • JDBC standards for database connectivity • ANSI SQL • W3C standards for HTML, XML, XSD, SOAP • J2EE standards for Servlets, JSP, JMS etc The core infrastructure

25. The evolution of Open Source Kuali(2004) Enterprise solutions Sakai(2004) uPortal (2001) Tools and components Eclipse (2004) PostgreSQL (1999) Apache (1995) Core Infrastucture Linux (1991) 1990 1995 2000 2005

26. Establishing standards. • W3C, WS-I • PESC, AACRAO in the SIS business domain • Products are created to these standards • XML parsers written to W3C standards • EDI software written to T130 transaction set Different approaches to development • Java Community process • Develop a standard • Develop a reference implementation • Integrated application development • Sakai • Kuali • Open source • Linux, Jboss • Developers working in a common CVS repository • Writing to an existing standard

27. A possible future? A family of community solutions?