slide 1 - princeton university - welcome
DESCRIPTION
TRANSCRIPT
A Community Source Student Services System
Richard Spencer
Leo Fernig
JA-SIG Summer ConferenceJune 5, 2006
Vancouver, BC
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 trends that enable a CS SSS open source software community source software development service oriented architecture
The SSS vision focus on the end user support non-traditional 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)– application 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 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
and there’s more.....– one way, return, multiple legs?– seniors or children, other special fares?– is there anything else we can help you with?
13
How we often deal with our customers Give me your personal information first
– including your name, gender, date of birth... Here is our list of 80 programs Choose one or two you think might fit Pay us We will let you know if we can admit you .....but it will take us a few weeks to figure this
out We will give you a registration time Then you can search for the courses you need.. ....no refund if you’re not eligible
14
Letting studentsadmit themselves
15
Self 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/aidservice
Informationcollection
Prior inst.service
Applic’t bio& other info
Choice not availableRegistration
serviceOutcome
Choice available
18
Where we are going...
19
Reasons for interest in a CS SSS 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
20
A next generation student system Focus on end users, Support non-traditional 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
21
Next steps Entity models, XML schemas
Web services standards
Reference infrastructure
Service oriented analysis of key processes– some process redesign
Governance structure
Identify partners
Identify first modules
Deploy resources
22
Thank you....and over to Leo
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 web services
• It has to be built with open technologies• On an open source infrastructure • On open standards• With open source tools
Business services• Agnostic• Composable
Composed services• Aggregations • Orchestrations
A more detailed decomposition of services
Infrastructure services• Enterprise wide• Student System specific
Services are built on the same model
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
Anatomy of a service bus
A service bus is composed of:
1. A canonical XML2. Lightweight service containers3. A messaging system backbone
A simple example: Admissions 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
A simple example: Message flow
A simple example: A message transformation service
• All messages in the Student System conform to a standard set of schemas (a canonical XML)
• Wherever possible we need to use existing industry standards. For example:• PESC http://www.pesc.org/• IMS http://www.imsglobal.org/
A simple example: WSDL for an academic decision service
<wsdl:types> <xsd:import namespace=“http://www.pesc.org/” schemaLocation=“test.xsd”/> <xsd:import namespace=“http://open.sis/schema/rules” schemaLocation=“rules.xsd”/> <xsd:import namespace=“http://open.sis/schema/result” schemaLocation=“result.xsd”/></wsdl:types>
<wsdl:message name=“EvaluationRequest”> <wsdl:part element=“pesc:test” name=“EvaluationRequest”/> <wsdl:part element=“key:ruleKey” name=“EvaluationRequest”/></wsdl:message><wsdl:message name=“EvaluationResponse”> <wsdl:part element=“res:result” name=“EvaluationResponse”/></wsdl:message>
<wsdl:portTypes> <wsdl:operation name=“evaluate”/> <wsdl:inout message=“EvaluationRequest”/> <wsdl:output message=“EvaluationResult”/></wsdl:operation>
Datadefinitions
Messagedefinitions
Interfacedefinition
Schemas are definedelsewhere
A. Message transform service
B. Logging service
C. Academic decision service
D. Academic record service
A simple example: Fitting services into the component model
Generalizing from the simple example
In reality we would not want a service that simplyevaluated SAT scores. Instead…..
1. A general Academic Decision Service• Degree audit• Pre-requisite checking in registration• Evaluating admission requirements
2. A general Academic Record Service that can handle any learning result:• Test results (SAT, TOEFL, GRE)• Transcript courses (and transfer credit)• Portfolio artifacts
Generalizing from the simple example
C. Academic decision service
Is used by:1. Admissions2. Registration3. Awards4. Degree Audit
Are the technologies available?
1. Core infrastructure
2. Web service standards
3. Web service technologies
4. Application components
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)
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
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
An example tool
The graphical user interface for developing WSDL’sthat comes with Axis and is an Eclipse plug-in.
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