Kuali Student Service System - PowerPoint PPT Presentation

1 / 27
About This Presentation
Title:

Kuali Student Service System

Description:

2 senior reps on the Board. Representation on the Technical and Functional ... Kuali Student will use existing open source products for BPEL engines, an ... – PowerPoint PPT presentation

Number of Views:67
Avg rating:3.0/5.0
Slides: 28
Provided by: cana7
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com