Kuali Student Service System

streakconvertingΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 4 χρόνια και 18 μέρες)

102 εμφανίσεις

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

General Institutional Resources **

QA Manager

Configuration Manager

UI Expert

Documentation Coordinator

Project Analyst/Admin

Program Communications

* Representation from each Founding Institution

** May be consulted from time to time during Architectural Phase

Program Director

Cath Fairlie

*Technical

Steering Committee

Chair: Leo Fernig

*Functional

Steering Committee

Chair: Audrey Lindsay

Kuali Student Board


CIOs*

Registrars*

Chair Ted Dodds

Extended Board

AACRAO

Mellon Foundation

Kuali Foundation

Partners

Chief Technical Architect
/ (Project Manager)

Leo Fernig

Services / Application
Architect / (Project Manager)
Gord Uyeda

Business
Analysts

Subject Matter
Experts*

Technologists
(or Lead
Developers)*

Development Infrastructure

Systems Infrastructure

DBA

Security

Lead Subject
Matter Experts*

Technical

Functional

Jul 2007




Nov 2007

Dec 2007





Apr 2008

May 2008





Sep 2008

Oct 2008









Mar 2009

Apr 2009

May 2009

Jun 2009

July 2009

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


Contract Design R1

(Infrastructure & Domain 1)

Service Modeling R2

(Domain 2)

Software Design &

Development R1

(Infrastructure and

Cur. Dev.)

Adjust
plans and
repeat for

Releases
2/3/4


One
Release
every 8
months

Program Management &Communications

Gate

Contract Design R2

(Domain 2)



Release 1 & Implement Test

Re
-
plan / Re
-
Architect / Implement & Transition to Support

Kuali Student


Phased Modular Approach

Develop Configuration

Application

-

Configuration Infrastructure

-

Proof of Concept Prototype

12

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.

13

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

14

10 Guiding Technical Principles

4.
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

5.
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.


6.
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.


7.
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


17

Technical Architecture Principles

8.
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.

9.
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.

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

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



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

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