Imagining a Community Source Student Services System

Leo Fernig

Richard SpencerSOA 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 modelLooking for the right level of abstraction..

People

Groups

Learning units (knowledge discovery units?)

Learning results

Resources

Rules

Also

enrolments; interactions

The layers of the Student Service System

The layers of the Student Service System

Portal

The layers of the Student Service System

Processes

The layers of the Student Service System

Service bus

The layers of the Student Service System

Services

Rules engines

Business drivers

• Unmediated interactions

• Transparency

• Flexibility

Technology solution

• Rules engine technology

• Rules authoring software

An example process

Step 1: Confirm the identity of the user and get their permissions

An example process

Step 2: Get the student’s academic record

An example process

Step 3: Do an evaluation to see if they meet the institutions admissions requirements

An example process

Step 4: Communicate the result to the applicant

The layers of the Student Service System

Core software stack

The core infrastructure

It is now possible to run an extremely large transactionalsystem 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 evolution of Open Source

Linux (1991)

1990

Apache (1995)

1995 2000 2005

PostgreSQL (1999)

Eclipse (2004)

uPortal (2001)

Sakai(2004)

CoreInfrastucture

Tools andcomponents

Enterprisesolutions

Kuali(2004)

Different approaches to development

Java Community process• Develop a standard • Develop a reference implementation

Integrated application development • Sakai• Kuali

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

Open source • Linux, Jboss• Developers working in a common CVS repository• Writing to an existing standard

27

A family of community solutions?

A possible future?