1

A Community Source Student Services System

Richard Spencer

Leo Fernig

CANHEIT, HalifaxJune 12, 2006

2

Mellon funded planning study Goals

– level of interest in an open source SSS?– need for an open source SSS?– any existing applications to use as a base?

Participants– University of Indiana, Georgetown University, San

Joaquin Delta College, UBC, consultants and others Consultation

– meetings at JA-SIG and Sakai conferences– SOA workshop in Vancouver– focus groups at AACRAO– consultation with vendors

3

3 developments that enable a CS SSS open and community source software development service oriented architecture (SOA) Web services

The SSS vision focus on the end user support all types of learning build a modular system

– integrate modules with existing systems

use workflow and rules engines– cross departmental and system boundaries

– implement “your practices”, not “best practices”

4

Open and CommunitySource

5

The evolution of Open Source

CoreInfrastructure

Tools andcomponents

Enterprisesolutions

Linux (1991)

1990

Apache (1995)

1995 2000 2005

PostgreSQL (1999)

Eclipse (2004)

uPortal (2001)

Sakai(2004)

Kuali(2004)

Moodle(2001)

jBoss (1999)

SSS (2006) ???

6

Open vs. community source

Open source Open membership

Large developer community

Individuals may decide priorities & projects

Local development can lead to different versions

Source code is open for review and change

Corporate contributions welcome

Community source Membership in a community

Smaller development community

Priorities established by community

Locally developed components are compatible

Source code may be included in commercial products

Institutional and corporate contributions welcome

7

Community source objectives Productivity

– more developers working on project Reliability

– more eyes looking for bugs Innovation

– institutions are free to innovate and share Direction

– partners can have input into Community projects Evolution

– community can ensure sustained development Partnerships

– include commercial partners

8

A student services system

9

SOA goals break business processes down into:

– process or control logic (orchestration service layer)– business logic (business service layer)– infrastructure functions (application service layer)

use standard data models and XML schemas build agnostic, reusable “services” to provide the

business logic and application functions use rules engines for the internal logic use workflow for the process logic loosely couple components agility - make process change easier!

10

Community source SSS possibilities True service analysis and orientation

Common entity models, data standards and XML schemas

Web services for loose coupling

Combining modules developed at different schools

Combining open source and commercial components

Using commercial service providers to implement and support systems and system components

11

Imagining a next generationstudent services system

12

The Expedia model Where do you want to go When do you want to go there You can choose:

– the airline– the class

You can sort the results by– price– departure or arrival time

if you like one of the choices.....– provide your name and payment information

13

How we often deal with applicants Give me your personal information first

– including your name, gender, date of birth... Here is a list of every program we offer Choose no more than two Pay us We will let you know if we can admit you .....but give us a few weeks to figure this out If yes, we will give you a registration time Then you can search for the courses you need If no,

– we keep your money anyway

14

Letting studentsadmit themselves

15

Self evaluation and admission If there are specific admission requirements:

– e.g.: required courses, grades or gpas

Students choose a program & enter their own courses and grades

A rules engine determines if they are admissible– they get a full explanation of:

what credentials were used, what was missing how the admission gpa was calculated why they did or didn’t qualify for admission

They can admit themselves..– and print their admission letter in real time

16

Reflecting on self-admission Students:

– do the grade submission work– get an immediate answer– can see the rules and how they have been applied

The process allows:– a student to try multiple “what if” scenarios– counselors to advise students on program requirements

The rules engine could allow the student to:– select a program, and see what is required to enter it– enter what they have, and see what they are eligible for

Staff can concentrate on value added work

The process is scalable!

17

Applicantlogin

Identityservice

Evaluate applic’t/offer choices

Program/aidservices

Informationcollection

Prior inst.services

Applicantprofile

Choice not availableRegistration

serviceOutcome

Choice available

18

What we have learned

19

The vision is right Focus on end users Support all kinds of learning Modular, standards based, loose coupled SOA, web services, and enterprise services Workflow, rules engines (decision services) Make it easy to redesign business processes Extend functionality into new areas Community source development Scalable, rule based, self-service processes

20

The need is there add functionality to existing systems

– ERPs can’t do everything– re-use some existing functionality

replace old technology– don’t want to install a monolithic ERP system

future path for in-house systems– one institution can no longer develop a complete

student system

get off the ERP upgrade path– improvements don’t always reflect cost and effort

Delaware:•housing•dining•course approval•judicial referral•course & faculty evaluation•advising notesIndiana•course trading

21

The next steps International participation in planning

Entity models, XML schemas

Service oriented analysis of key processes– some process redesign

Web services standards

Reference infrastructure

Identify partners who will build modules

Form a partnership

Build the first modules

22

...and now to cover Leo’s part

23

Development strategy for a student system

• It is too big to be built as a single monolithic system• It has to be built as a set of independent components• These components are collections of services• The services are loosely coupled using Web services

• It has to be built with open technologies• On an open source infrastructure • On open standards• With open source tools

24

25

Business services• Agnostic• Composable

Composed services• Aggregations • Orchestrations

A more detailed decomposition of services

Infrastructure services• Enterprise wide• Student System specific

26

Services are built on the same model

27

Anatomy of a service

A service is composed of:1. A container

1. Lifecycle management2. Security3. Caching/logging services

2. An interface defined in WSDL1. Data structures2. Method signatures

3. Implementation code1. Java classes

28

Anatomy of a service bus

A service bus is composed of:

1. A canonical XML2. Lightweight service containers3. A messaging system backbone

29

A simple example: Processing an SAT score

An SAT score arrives via ftp:

1. It is converted to standard (canonical) XML2. Both messages are logged3. The SAT is evaluated4. The SAT and the evaluation are added to the

applicant’s file

In reality these services would deal with any tests: GRE,TOEFL, LSAT

30

A simple example: Message flow

36

Are the technologies available?

1. Core infrastructure

2. Web service standards

3. Web service technologies

4. Application components

37

Core infrastructure

Linux (1991)

1990

Apache (1995)

1995 2000 2005

PostgreSQL (1999)

Eclipse (2004)

uPortal (2001)

Sakai(2004)

CoreInfrastructure

Tools andcomponents

Enterprisesolutions

Kuali(2004)

Moodle(2001)

jBoss (1999)

38

Web service standards1. W3C standards:

1. XML schema2. WSDL3. SOAP

2. Other web service standards (mainly OASIS):1. WS-transaction2. WS-coordination3. WS-security4. BPEL (Business Process Execution Language)

3. Web Service Interoperability Group1. Basic Profile2. Basic Security Profile

39

Web service tools

1. Tools for authoring XML schemas2. Tools for authoring WSDL’s 3. Web service run-time containers

For example:1. WST Eclipse tools for authoring XML schemas2. Axis (Apache) graphical tools for authoring

WSDL’s3. Web service run-time containers

40

ConclusionThree prerequisites for a student system

1. An entity model1. A high level entity model2. A set of XML schemas (a canonical xml)

2. A service model1. A high level service decomposition model2. A common set of WSDL’s

3. Technology infrastructure1. Core infrastructure2. Web services standards3. Web service tools and technologies4. Application components