Transcript Presentation Template

Kuali Student Service System
“A SOA Development Platform”
June 27, 2007
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
2
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.
3
Specific Objectives
• To develop a next generation Student Service System
architecture that follows the principles of ServiceOrientation, 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.
4
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.
5
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
6
Founder and Partner Requirements
Founder
Partner
– 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
– 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
7
Kuali Student Service System
Team Organization – Architectural Phase
Kuali Student Board
Extended Board
CIOs*
Registrars*
Chair Ted Dodds
AACRAO
Mellon Foundation
Kuali Foundation
Partners
*Functional
Steering Committee
*Technical
Steering Committee
Chair: Audrey Lindsay
Chair: Leo Fernig
Program Director
Cath Fairlie
General Institutional Resources **
QA Manager
Configuration Manager
UI Expert
Documentation Coordinator
Project Analyst/Admin
Program Communications
Development Infrastructure
Services / Application
Architect / (Project Manager)
Gord Uyeda
Business
Analysts
Lead Subject
Matter Experts*
Systems Infrastructure
DBA
Security
* Representation from each Founding Institution
** May be consulted from time to time during Architectural Phase
8
Subject Matter
Experts*
Chief Technical Architect
/ (Project Manager)
Leo Fernig
Technologists
(or Lead
Developers)*
Kuali Student – Phased Modular Approach
Functional
Gate
Adjust
plans and
repeat for
Releases
2/3/4
One
Release
every 8
months
Program Management &Communications
Jul 2007
Nov 2007
Dec 2007
Technical
Application Architecture
- Business Requirements
- Process models
- ER models
- High Level Service Models
Technical Architecture
-Technology proofs
-SOA standards
Service Modeling R1
(Infrastructure and
Cur. Dev.)
Development Infrastructure
- Developers workbench
- Procedures
- Standards
Apr 2008
May 2008
Contract Design R1
(Infrastructure & Domain 1)
Develop Configuration
Application
- Configuration Infrastructure
- Proof of Concept Prototype
Sep 2008
Oct 2008
Service Modeling R2
(Domain 2)
Software Design &
Development R1
(Infrastructure and
Cur. Dev.)
Contract Design R2
(Domain 2)
Mar 2009
Apr 2009
May 2009
Jun 2009
July 2009
Release 1 & Implement Test
Re-plan / Re-Architect / Implement & Transition to Support
10 Guiding Technical Principles
1. 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.
12
10 Guiding Technical Principles
2. 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.”
3. 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
13
10 Guiding Technical Principles
4. Separate Governance Process for Service
Contracts
– Service contracts are the business assets of an SOAbased 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.
14
Application Architecture
15
Component Abstraction
5.
Interface (UI) components will be abstracted from the orchestration
layer and the business service layer.
•
6.
Business rules and business process logic will be abstracted from the
code base.
•
•
7.
Kuali Student will be delivered through an existing open source portal
product to allow abstraction of the presentation layer.
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 Student’s 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
16
Technical Architecture Principles
8.
Kuali Student Will Be Built Entirely On An Open Source Software
Stack
•
•
9.
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.
10. 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.
17
Technical Architecture
18
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)
19
Developers Workbench
20
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)
21
Stereotype for the UI layer
22
Stereotype for
Business Agnostic Service
23
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
27
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
31
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
32
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
34
“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
35
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
36