Kuali Student Service System

1
Kuali Student Service System

• A SOA Development Platform
• June 27, 2007

2
Background

• Many institutions finding that their student
  systems no longer meet their needs
• Vendor solutions are expensive and do not provide
  the functionality that custom solutions do today
• Ability to continue to develop in-house systems
  is declining
• Increasingly complex technology requires
  specialist resources
• Competing for the same IT resources in a
  constrained market
• User requirements and expectations increasing
  exponentially
• Budgets and funding constrained
• Institutions looking to a collaboration and open
  source system development to solve these problems
• Feasibility Study conducted in early 2006
• Workshops to explore possibilities with partners
  in late 2006
• Founding institutions for Kuali Student -
  February 2007

3
Kuali Student Vision

• A Next Generation Student System
• To provide person centric services that support
  students and other users by anticipating their
  needs and reducing the time it takes to complete
  administrative tasks.
• To support a wide range of learners and learning
  activities in a wide range of institutions by
  using a flexible, configurable, data model.
• To support a wide range of academic and related
  business processes, including those that cross
  departments, systems and institutions, in ways
  that work best for each institution, by using
  rules based business logic, and configurable
  processes.
• To ensure a modular design by using a Service
  Oriented Architecture implemented using Web
  Services.
• To achieve sustainability through community
  source distribution and wide spread adoption.

4
Specific Objectives

• To develop a next generation Student Service
  System architecture that follows the principles
  of Service-Orientation, implemented using Web
  Services.
• To develop the Service Contract specifications
  for the services required to implement the
  Student Service System. This will enable
  development work to be completed by a large
  community, not just the originating Founders.
• To develop, and release for implementation, a
  software product consisting of a set of Services
  that have been defined to be the core functions
  of a next generation Student Service System -
  Kuali Student.
• To define and publish standards for development
  that can be used by other members of the
  community to develop Services that are not within
  the scope of the core product.

5
Specific Objectives

• To ensure the core Services of Kuali Student are
  successfully implemented by the Founding
  Institutions.
• To promote the adoption and implementation of
  Kuali Student by a wide variety of educational
  institutions within North America and
  internationally.
• To build a community of interest that will
  sustain future maintenance, enhancement and
  development of the product.
• To define product development and support
  processes that will be used to assist the
  community to implement the software and to
  provide operational support for the product.
• To continue to evolve the technology and
  architecture of Kuali Student over time to keep
  up with new industry standards, tool releases and
  trends.

6
Founder Partners

• Founders
• University of British Columbia (Lead)
• University of Maryland College Park
• Florida State University
• University of California, Berkeley
• San Joaquin Delta College
• Partners
• Massachusetts Institute of Technology
• Carnegie Mellon University

7
Founder and Partner Requirements

• Founder
• Align with the vision
• 1 million / year for 5 years in staff or cash
  resources
• 2 senior reps on the Board
• Representation on the Technical and Functional
  Steering Committees
• Commit to implement most modules
• Adhere to the governance of the Project Charter
• Active advocate to the community

• Partner
• Align with the vision
• Allocate resources to the project (typically 2 or
  3 staff)
• Not represented on the Board
• May have a representative on the Technical and/or
  Functional Steering Committee
• May commit to implement one or more modules
• Adhere to the governance of the Project Charter
• Active advocate to the community

8
Kuali Student Service System Team Organization
Architectural Phase
Technical Steering Committee Chair Leo Fernig
Functional Steering Committee Chair Audrey
Lindsay
Program Director Cath Fairlie
General Institutional Resources QA
Manager Configuration Manager UI
Expert Documentation Coordinator Project
Analyst/Admin Program Communications
Chief Technical Architect / (Project Manager)Leo
Fernig
Services / Application Architect / (Project
Manager) Gord Uyeda
Business Analysts
Lead Subject Matter Experts
Technologists (or Lead Developers)
Development Infrastructure Systems
Infrastructure DBA Security
Subject Matter Experts
Representation from each Founding
Institution May be consulted from time to
time during Architectural Phase
9
Program Approach

• Why do we need to do it differently?
• Complexity and scale of what we are trying to do
  requires structure and clear project management.
  Even more so since we are trying to do it with
  5-7 different institutional perspectives.
• We are fundamentally changing the underlying
  technical architecture. Re-architecting versus
  evolving a system requires more up front planning
  and investment
• Service Orientation requires an up front
  investment to achieve the goals of
• Service modularity
• Service re-usability
• ? Clear methodology and approach
• ? Architecture First !

10
Program Approach

• A structured approach that is easily understood
  by all stakeholders is essential to ensure
  program success. Concepts include
• Well defined phases of approximately 4-6 months
  each
• Clear definition of deliverables at each stage
• Phase deliverables should be tangible assets. In
  case of failure of the entire project, there is
  still value gained and useable deliverables for
  the investment
• Ownership of deliverables is clearly defined
• QA reviews and checkpoints at the end of each
  phase.
• Sign off of phase deliverables as complete
• At the end of each phase, the plans for the next
  phase will be updated based on the new
  information available. The plans will remain
  flexible and are modified to meet the realities
  of the day
• Agility, Phases, Timeboxes, and Iterations

11
(No Transcript)
12
10 Guiding Technical Principles

• SOA Methodology
• Greater emphasis on up-front design of entities
  and service contracts (top-down). The artifacts
  of the design phase are entity models and service
  definitions.
• Services should be autonomous they are not
  controlled or constrained by another service and
  therefore may run remotely. This is a strong
  bias there will be cases where this is
  impractical for performance, security, or other
  reasons.
• Services should be loosely coupled they are
  modeled and exposed through an interface that is
  separate from its implementation. Through
  loose-coupling, services can by implemented in
  any environment as long as implementation
  fulfills the service contract.
• There is a high degree of emphasis placed on the
  identification of re-usable services.

13
10 Guiding Technical Principles

• Web Services
• The preferred implementation of the SOA is Web
  services.
• They are simple, universal, and platform neutral.
  
• Web services means SOAP and WSDL.
• XML is the platform.
• Standards Based
• Kuali Student will follow open standards wherever
  feasible, and in the following areas (and others
  where applicable)
• W3C Web services framework
• WS-
• Industry standards such as PESC-AACRAO
• Java community standards such as JSR 286
  (portlet), JSR 94 (rules)
• Accessibility Standards
• Internationalization standards

14
10 Guiding Technical Principles

• Separate Governance Process for Service Contracts
• Service contracts are the business assets of an
  SOA-based system, are the public definition of
  the system, and must be the most stable part of
  the system.
• The governing body has representation from each
  service domain, the involved business units, and
  technical subject matter experts.
• Management of service contracts may be extended
  to external contracts.
• Service contracts created by an institution
  (e.g., for purposes of customization, or for the
  purposes of consumption of external services)
  will be maintained by the institution.

15
Application Architecture
16
Component Abstraction

• Interface (UI) components will be abstracted from
  the orchestration layer and the business service
  layer.
• Kuali Student will be delivered through an
  existing open source portal product to allow
  abstraction of the presentation layer.
• Business rules and business process logic will be
  abstracted from the code base.
• Rules engines are the preferred vehicles for
  abstracting business rules
• Workflow and BPEL engines are the preferred
  vehicles for abstracting business process logic.
• Abstraction of the Data Layer
• Kuali Students data model will be derived from
  simple abstractions such as time, people,
  learning units, and learning results.
• Data access will be abstracted in the data layer
  to provide database independence
• Data access will be abstracted through an ORM
  framework and as a rule it will be services that
  provide data

17
Technical Architecture Principles

• Kuali Student Will Be Built Entirely On An Open
  Source Software Stack
• Compatible with the outbound Educational
  Community License (ECL)
• Reference distributions of Kuali Student are
  entirely open source.
• It is not within the scope of Kuali Student to
  build infrastructure components.
• Kuali Student will use existing open source
  products for BPEL engines, an Enterprise Service
  Bus, Workflow and Rules Engine Technology and UI
  frameworks, although the technical team may need
  to develop web service wrappers for existing
  products.
• Code that is written as part of the core Kuali
  Student product should be written in Java and
  Java will be the platform of choice for Kuali
  Student.

18
Technical Architecture
19
Leveraging Open Source

• SOA / Web Services Stack
• Portal (uPortal)
• Rules Engine (JBoss Rules, Open Rules)
• Authentication and Authorization (CAS, Acegi,
  JAAS)
• Data Binding Tools (jibx, Castor, JaxB)
• Web Services Engine (Axis 2, Xfire, JAX-WS,
  Spring WS, JBoss WS)
• Orchestration Workflow (KEW, jBPM, BPMScript,
  Intalio, Agila, Pi-Calculus)
• Service Registry (jUDDI, Infravio, UDDI)
• ESB (KSB, ServiceMix, JBoss ESB, Mule, Open ESB,
  Celtix)
• Database (mySQL)
• Systems Infrastructure Components
• Application Server (Tomcat, JBoss, Geronimo,
  Glassfish)
• Load Balancing (institution-choice)
• Firewall (institution-choice)
• LDAP (institution-choice)

20
Developers Workbench
21
Developers Workbench

• Design Tools (MagicDraw)
• Build Tools (Maven, Ant)
• Source Code Management (Subversion, Aegis,
  GNU-Arch, CVS)
• MVC / Presentation Layer Framework (Spring,
  Struts, JSF)
• User Interface Toolkits (Dojo)
• Development Environment (Eclipse and Plug-Ins)
• ORM Tools (Hibernate, OJB, TopLink, Castor JDO,
  Ibatis, Torque, Jaxor)

22
Stereotype for the UI layer
23
Stereotype for Business Agnostic Service
24
Module Stereotypes

• Typical User Interface Module
• Dispatcher receives request which is handed to
  the controller.
• The controller executes business logic.
• The model is mapped to a view which is returned
  to the user as the response.

• Typical Business Service
• Input messages is an XML Document
• Axis can handle security and other SOAP headers.
• Process logging on input and output.
• XML data is bound via JIBX or other.
• Logging, caching, etc. handled by Spring AOP.
• Business Rules handled by rules engine.

25
Module Stereotypes

• Differences in the SOA World
• The controller will be interacting with one or
  more Web services.
• The view template may be built dynamically by
  invoking services that return components.
• Questions
• Can a BPEL or workflow engine be one of the
  services called? Can it serve in some cases as
  the controller or view resolver?
• Should a framework such as Spring MVC be used for
  the MVC pattern? If so
• How do we integrate Ajax? Is the MVC component
  now on the client?
• How do we aggregate UI components on the portal?
• Portal
• How will UI components be aggregated in the
  portal?
• A portlet rendered in the portal?
• A collection of portlets or channels?

26
Module Stereotypes

• Security Concerns
• Authentication
• Authorization
• Message Security
• Authn/Authz are provided by services.
• Each consumer of a service needs to be
  authenticated.
• The figure shows
• A call is made to an authentication service that
  responds with a security context.
• All POJOs have access to the context which
  include
• User details
• Permissions
• For example, we could use
• CAS as the authentication provider.
• Acegi as the framework to provide the security
  context.

27
Other Considerations

• Other Technical Architecture Considerations to be
  solved and implemented within the module
  stereotypes.
• Security Guidelines
• Transactional Integrity
• Standards
• Solve these problems once so the developers can
  focus on business requirements and solutions

28
Security Guidelines

• Assumptions
• The network is not secure. Any information going
  over the network needs to be encrypted. For this
  project TLS cryptographic algorithms are
  sufficient.
• There is no need for a proxy i.e., there are no
  services we do not trust with the information we
  send to it.
• The issue of security domains is not yet
  resolved we need to determine how Kuali Student
  will work with other domains such as Sakai, Kuali
  Financials, and 3rd-party systems.
• Legacy systems will be accessed through a service
  layer in which security is the responsibility of
  the implementer.
• Security is managed at three levels
• Transport (e.g., https)
• Service (e.g., WS-Security)
• Application (e.g., authorization)
• Security Issues to be addressed
• Authentication
• Authorization (strong need for federation)
• Privacy and Integrity
• Non-repudiation

29
Transactional Integrity

• WS-Coordination
• Provides context management
• Is asynchronous by default
• WS-Transaction
• Is layered upon WS-Coordination, which is
  asynchronous.
• Extends WS-Coordination to provide a transaction
  context.
• Augments WS-Coordination activation and
  registration services to build a fully-fledged
  transaction coordinator.
• Control relationship between service and
  participant through API such as JAXTX
• WS-Transaction Models
• Atomic Transactions
• Short duration interactions
• Similar to traditional transaction systems
• ACID Properties
• Atomicity Success and commit or failure and
  rollback.
• Consistency - Transactions produce consistent
  results and preserve application specific
  invariants.
• Isolation Intermediate states not visible to
  others appearance of serial execution achieved
  by locking.
• Durability Effects of a committed transaction
  are not lost.

30
Standards

• We do not want to replace vendor lock-in with
  product lock-in.
• We do want to promote modularity, plug-and-play,
  and maintain the ability to switch out technology
  down the road when necessary.
• We will accomplish this by
• Choosing products that are standards-compliant.
• Following standards in development and
  implementation.

31
Deployment Landscape

• All services must be able to be deployed remotely
  without change to code or architecture.
• Implementers must have flexibility in making
  deployment decisions based on performance,
  security, and cost.
• Need to design and configure the Systems
  Infrastructure for the DEV, TEST, QA, PROD
  environments to accommodate and test this
  flexibility
• The development environment should be as simple
  as possible

32
Configuration Application

• A set of core infrastructure services for an
  enterprise application
• The Data Dictionary Service
• The Search Service
• The Rules Definition Service
• The Process Configuration Service
• The Security Configuration Service

33
Prototype Scenarios

• In order to test the proof-of-concepts and the
  evolving modules, testing scenarios need to be
  developed that are wide and deep.
• Depth
• Test the SOA layers (UI, Orchestration, Business
  Services, Infrastructure Services, Data
  Services).
• Test the SOA Stack (Web services, AuthN/AuthZ,
  Business Rules Engine, BPEL/Workflow, Registry,
  Enterprise Service Bus, Portal,
  Configuration/Dynamic Data Dictionary, Database).
• Width
• Core abstractions (Person, Time, Learning Unit,
  ).
• Wide range of functional requirements the
  represents the scope.
• Connectors to external systems.
• Best scenarios are those that developers are
  familiar with, although this may be difficult for
  every module.
• Should help functional users visualize the system
  as it evolves rather than waiting for the module
  to be completed.

34
Challenges

• Complexity
• WSDL, SOAP, ORM, BPEL, Rules, Stubs Skeletons,
  POJOs, Binding,
• Monitoring and managing SOA applications.
• Requirement for a large investment in
  infrastructure management.
• Performance
• SOA and Web services put a strain on all parts of
  the infrastructure
• Working in a virtual world with a virtual
  organization
• Communication
• Management
• Daily progresses

35
SOA Development Platform

• A virtual organization working with collaboration
  tools
• A working prototype
• An application to configure the component
  abstractions
• A Developers Workbench
• A Service-Oriented Architecture with an
  integrated Web Services Stack

36
Questions?

• Reference information
• www.student.osnext.org
• Information through late 2006 when founders were
  first identified.
• Notes on meetings, conference presentations,
  meetings with vendors, etc.
• www.educationscommons.org
• Various workshops held during 2006.
• SOA, service, entity, and business process
  modeling, in-depth review of Kuali components.
• Soon public Web site for Kuali Student at
  www.kuali.org