Title: Kuali Student Service System
1Kuali Student Service System
- A SOA Development Platform
- June 27, 2007
2Background
- 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
3Kuali 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.
4Specific 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.
5Specific 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.
6Founder 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
7Founder 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
8Kuali 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
9Program 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 !
10Program 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)
1210 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.
1310 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
1410 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.
15Application Architecture
16Component 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
17Technical 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.
18Technical Architecture
19Leveraging 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)
20Developers Workbench
21Developers 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)
22Stereotype for the UI layer
23Stereotype for Business Agnostic Service
24Module 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.
25Module 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?
26Module 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.
27Other 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
28Security 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
29Transactional 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.
30Standards
- 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.
31Deployment 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
32Configuration 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
33Prototype 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.
34Challenges
- 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
35SOA 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
36Questions?
- 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