A Community Source Student Services System: A Community Source Student Services System Richard Spencer Leo Fernig JA-SIG Summer Conference June 5, 2006 Vancouver, BC


Mellon funded planning study: 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


Slide3: 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'


Open and CommunitySource: Open and Community Source


Slide5: The evolution of Open Source Core Infrastructure Tools and components Enterprise solutions Linux (1991) 1990 Apache (1995) 1995 2000 2005 PostgreSQL (1999) Eclipse (2004) uPortal (2001) Sakai(2004) Kuali(2004) Moodle(2001) jBoss (1999) SSS (2006) ???


Open vs. community source: Open vs. community source Open source Open membership Large developer community Individuals may decide priorities andamp; 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


Community source objectives: 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


A student services system: A student services system


SOA goals: 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!


Community source SSS possibilities: 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


Slide11: Imagining a next generation student services system


The Expedia model: 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?


How we often deal with our customers: 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


Slide14: Letting students admit themselves


Self admission: Self admission If there are specific admission requirements: e.g.: required courses, grades or gpas Students choose a program andamp; 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


Reflecting on self-admission: 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!


Slide17:


Where we are going...: Where we are going...


Reasons for interest in a CS SSS : 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 andamp; faculty evaluation advising notes Indiana course trading


A next generation student system: 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


Next steps: 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


Slide22: Thank you.... and over to Leo


Development strategy for a student system: 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


Slide24:


A more detailed decomposition of services: 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: Services are built on the same model


Anatomy of a service: Anatomy of a service A service is composed of: A container Lifecycle management Security Caching/logging services An interface defined in WSDL Data structures Method signatures Implementation code Java classes


Anatomy of a service bus: Anatomy of a service bus A service bus is composed of: A canonical XML Lightweight service containers A messaging system backbone


A simple example: Admissions processing an SAT score: A simple example: Admissions processing an SAT score An SAT score arrives via ftp: It is converted to standard (canonical) XML Both messages are logged The SAT is evaluated 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: Message flow


A simple example: A message transformation service: 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: A simple example: WSDL for an academic decision service andlt;wsdl:typesandgt; andlt;xsd:import namespace='http://www.pesc.org/' schemaLocation='test.xsd'/andgt; andlt;xsd:import namespace='http://open.sis/schema/rules' schemaLocation='rules.xsd'/andgt; andlt;xsd:import namespace='http://open.sis/schema/result' schemaLocation='result.xsd'/andgt; andlt;/wsdl:typesandgt; andlt;wsdl:message name='EvaluationRequest'andgt; andlt;wsdl:part element='pesc:test' name='EvaluationRequest'/andgt; andlt;wsdl:part element='key:ruleKey' name='EvaluationRequest'/andgt; andlt;/wsdl:messageandgt; andlt;wsdl:message name='EvaluationResponse'andgt; andlt;wsdl:part element='res:result' name='EvaluationResponse'/andgt; andlt;/wsdl:messageandgt; andlt;wsdl:portTypesandgt; andlt;wsdl:operation name='evaluate'/andgt; andlt;wsdl:inout message='EvaluationRequest'/andgt; andlt;wsdl:output message='EvaluationResult'/andgt; andlt;/wsdl:operationandgt; Data definitions Message definitions Interface definition Schemas are defined elsewhere


A simple example: Fitting services into the component model: Message transform service Logging service Academic decision service Academic record service A simple example: Fitting services into the component model


Generalizing from the simple example: Generalizing from the simple example In reality we would not want a service that simply evaluated SAT scores. Instead….. A general Academic Decision Service Degree audit Pre-requisite checking in registration Evaluating admission requirements 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: Generalizing from the simple example Academic decision service Is used by: Admissions Registration Awards Degree Audit


Are the technologies available?: Are the technologies available? Core infrastructure Web service standards Web service technologies Application components


Core infrastructure: Core infrastructure Linux (1991) 1990 Apache (1995) 1995 2000 2005 PostgreSQL (1999) Eclipse (2004) uPortal (2001) Sakai(2004) Core Infrastructure Tools and components Enterprise solutions Kuali(2004) Moodle(2001) jBoss (1999)


Web service standards: Web service standards W3C standards: XML schema WSDL SOAP Other web service standards (mainly OASIS): WS-transaction WS-coordination WS-security BPEL (Business Process Execution Language) Web Service Interoperability Group Basic Profile Basic Security Profile


Web service tools: Web service tools Tools for authoring XML schemas Tools for authoring WSDL’s Web service run-time containers For example: WST Eclipse tools for authoring XML schemas Axis (Apache) graphical tools for authoring WSDL’s Web service run-time containers


An example tool: An example tool The graphical user interface for developing WSDL’s that comes with Axis and is an Eclipse plug-in.


ConclusionThree prerequisites for a student system: Conclusion Three prerequisites for a student system An entity model A high level entity model A set of XML schemas (a canonical xml) A service model A high level service decomposition model A common set of WSDL’s Technology infrastructure Core infrastructure Web services standards Web service tools and technologies Application components