kuali student service system “a soa development platform” june 27, 2007

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 SystemTeam Organization – Architectural Phase

General Institutional Resources **QA ManagerConfiguration ManagerUI ExpertDocumentation CoordinatorProject Analyst/AdminProgram Communications

* Representation from each Founding Institution** May be consulted from time to time during Architectural Phase

Program DirectorCath Fairlie

*Technical Steering Committee

Chair: Leo Fernig

*Functional Steering CommitteeChair: Audrey Lindsay

Kuali Student Board

CIOs*Registrars*Chair Ted Dodds

Extended BoardAACRAOMellon FoundationKuali FoundationPartners

Chief Technical Architect / (Project Manager)Leo Fernig

Services / Application Architect / (Project Manager) Gord Uyeda

Business Analysts

Subject Matter Experts*

Technologists (or Lead Developers)*

Development InfrastructureSystems InfrastructureDBASecurity

Lead Subject Matter Experts*

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

TechnicalFunctional

Jul 2007

Nov 2007Dec 2007

Apr 2008May 2008

Sep 2008Oct 2008

Mar 2009Apr 2009May 2009Jun 2009July 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 forReleases 2/3/4

One Release every 8 months P

rogr

am M

anag

emen

t &

Com

mun

icat

ions

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

• Service Oriented Architecture– SOA Methodology– Web Services– Standards Based– Separate Governance Process for Service Contracts

• Leveraging of Open Source– System Will Be Built Entirely on an Open Source Software Stack– Infrastructure Will Be Composed of Existing Open Source

Products

• Component Abstraction– Business Process and Business Rules– Presentation Layer and Use of Open Source Portal– Data Layer

• Development– Java as the Language and Platform of Choice

13


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

14


• 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

15


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

16




Products



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




Products

• Component Abstraction– Presentation Layer and Use of Open Source Portal– Business Process and Business Rules– Data Layer


20

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

21

Application Architecture

22

Technical Architecture

23





Products


24

Developers Workbench

25

Developers Workbench

• Run-Time– 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)

• 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)

• Systems Infrastructure– Application Server (Tomcat, JBoss, Geronimo, Glassfish)

– Load Balancing (institution-choice)

– Firewall (institution-choice)

– LDAP (institution-choice)

26

Stereotype for the UI layer

27

Stereotype for Business Agnostic Service

31

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

35

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

36

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

37

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.

38

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

39

“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

40

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

kuali student service system “a soa development platform” june 27, 2007

Documents

kuali student service

student systems

architecture of kuali

core services of kuali

generation student system

kuali student vision

product development

wide range of institutions