Vista Pilot Project Charter

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

15 Αυγ 2012 (πριν από 4 χρόνια και 8 μήνες)

654 εμφανίσεις


Kuali Student Service System

Technical Architecture Phase 1 Recommendations


Technical
Architecture
Phase 1 deliverables

3/15/2013

1






Kuali Student Service System

Technical Architecture Phase 1
Recommendations




December 31 2007




Kuali Student Technical Team




Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


1


Table of Contents


1

OVERVIEW

................................
................................
................................
........................

4

1.1

R
EASON FOR THE
I
NVESTIGATION

................................
................................
...................

4

1.2

S
COPE OF THE
I
NVESTIGATION

................................
................................
.......................

4

1.3

M
ETHODOLOGY OF THE
I
N
VESTIGATION

................................
................................
..........

4

1.4

C
ONCLUSIONS

................................
................................
................................
...............

5

1.5

D
ECISIONS THAT HAVE B
EEN DELAYED

................................
................................
............

6

2

STANDARDS

................................
................................
................................
.....................

7

2.1

I
NTRODUCTION

................................
................................
................................
..............

7

2.2

W3C

STANDARDS

................................
................................
................................
..........

7

2.3

OASIS

STANDARDS

................................
................................
................................
.......

7

2.4

J
AVA COMMUNITY STANDA
RDS

................................
................................
........................

8

2.4.1

Java web services: JSR 222 and JSR 224

................................
............................

8

2.4.2

JBI: JSR 208

................................
................................
................................
.........

8

2.4.3

Rules engine: JSR 94

................................
................................
...........................

8

2.4.4

Portlets: JSR 286

................................
................................
................................
..

8

3

THE PORTAL

................................
................................
................................
.....................

9

3.1

C
OMMENTS ON
S
ELECTION

................................
................................
............................

9

3.2

S
ELECTION
C
RITERIA AND
E
VALUATION

................................
................................
..........

9

3.2.1

Widespread adoption

................................
................................
............................

9

3.2.2

Community of interest

................................
................................
...........................

9

3.2.3

S
tandards compliance

................................
................................
.........................
10

3.3

I
SSUES

................................
................................
................................
.........................
10

4

THE DATABASE

................................
................................
................................
...............
11

4.1

C
OMME
NTS ON
S
ELECTION

................................
................................
...........................
11

4.2

S
ELECTION
C
RITERIA AND
E
VALUATION

................................
................................
.........
11

4.3

I
SSUES

................................
................................
................................
.........................
12

5

SERVLET ENGINES

................................
................................
................................
.........
13

5.1

C
OMMENTS ON
S
ELECTION

................................
................................
...........................
13

6

XML
-
JAVA BINDING
................................
................................
................................
.........
14

6.1

C
OMMENTS ON
S
ELECTION

................................
................................
...........................
14

6.2

S
ELECTION
C
RITERIA AND
E
VALUATION

................................
................................
.........
14

6.3

I
SSUES

................................
................................
................................
.........................
14

6.3.1

Performance concerns

................................
................................
.........................
14

7

WEB
-
SERVICE ENGINES

................................
................................
................................
.
16

7.1

R
EASONS FOR THE
S
ELECTION

................................
................................
......................
16

7.2

I
SSUES

................................
................................
................................
.........................
16

8

RULES ENGINES

................................
................................
................................
..............
17

8.1

C
OMMENTS ON
S
ELECTION

................................
................................
...........................
17


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


2

8.2

S
ELECTION
C
RITERIA AND
E
VALUATION

................................
................................
.........
17

8.3

I
SSUES

................................
................................
................................
.........................
18

8.4

F
IGURE
1



KS

BRMS

................................
................................
................................
..
19

9

BPEL

................................
................................
................................
................................
.
20

9.1

S
ELECTION
C
RITERIA AND
E
VALUATION

................................
................................
.........
20

9.1.1

Potential Uses

................................
................................
................................
......
21

9.2

I
SSUES

................................
................................
................................
.........................
21

10

ESB

................................
................................
................................
................................
22

10.1

S
ELECTION
C
RITERIA AND
E
VALUATION

................................
................................
......
22

10.1.1

Criteria

................................
................................
................................
.................
22

10.1.2

Product Space

................................
................................
................................
.....
22

10.1.3

WS
-
* Compatibility

................................
................................
...............................
23

10.2

C
OMMENTS ON
S
ELECTION

................................
................................
........................
24

10.3

I
SSUES

................................
................................
................................
.....................
24

11

TRANSACTIONS

................................
................................
................................
...........
25

11.1

C
OMMENTS ON
S
ELECTION

................................
................................
........................
25

11.2

I
SSUES

................................
................................
................................
.....................
25

11.2.1

Mitigation

................................
................................
................................
.............
25

11.2.2

Next Steps

................................
................................
................................
...........
26

12

WORKFLOW

................................
................................
................................
.................
27

12.1

P
OSSIBLE INTEGRATION
ISSUES

................................
................................
.................
27

12.2

I
NTEGRATION APPROACH

................................
................................
...........................
27

12.3

P
OSSIBLE FURTHER ENHA
NCEMENTS
................................
................................
..........
28

13

SWAPPABLE INFRASTRUC
TURE

................................
................................
...............
29

13.1

W
HAT DO WE MEAN BY

SWAPPABLE INFRASTRUC
TURE
”?

................................
............
29

13.2

W
HAT ARE THE MAIN DRI
VERS BEHIND THE CONC
EPT OF SWAPPABLE INF
RASTRUCTURE
?

31

13.3

W
HAT ARE THE CONSTRAI
NTS AROUND SWAPPING
OUT DIFFERENT LAYERS

OF THE
INFRASTRUCTURE
?

................................
................................
................................
.................
31

13.3.1

Operating system

................................
................................
................................
.
31

13.3.2

Portal

................................
................................
................................
...................
32

13.3.3

Database

................................
................................
................................
.............
32

13.3.4

Service engine layer

................................
................................
............................
32

13.3.5

ESB

................................
................................
................................
.....................
32

13.3.6

Workflow

................................
................................
................................
..............
33

13.3.7

Rules engine

................................
................................
................................
........
33

13.4

W
HERE DOES RESPONSIBI
LITY LIE FOR TESTING

ASSUMPTIONS ABOUT SW
APPABLE
INFRASTRUCTURE
?

................................
................................
................................
.................
34

13.4.1

Database

................................
................................
................................
.............
34

13.4.2

Operating system

................................
................................
................................
.
34

13.4.3

Portal

................................
................................
................................
...................
34

13.4.4

Service engine layer

................................
................................
............................
34

14

APPENDIX A STANDARDS

................................
................................
..........................
35


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


3

15

APPENDIX B DATABASE
S

................................
................................
.........................
36

15.1

D
ATABASE PERFORMANCE
STATISTICS

................................
................................
.......
36

15.2

P
RODUCT
C
OMPARISON
M
ATRIX

................................
................................
................
37

15.3

A
PPENDIX
C

S
ERVLET ENGINES

................................
................................
.................
38

15.4

S
ERVLET
E
NGINES
P
ERFORMANCE

................................
................................
............
38

15.5

P
RODUCT
D
ATA
M
ATRIX

................................
................................
............................
39

16

APPENDIX D XML BIND
ING FRAMEWORK

................................
...............................
40

16.1

XML

B
INDING
P
ERFORMANCE

................................
................................
....................
40

16.2

P
RODUCT
D
ATA
M
ATRIX

................................
................................
............................
41

17

APPENDIX E WEB SERVI
CE ENGINES

................................
................................
.......
43

17.1

E
NGINE
P
ERFORMANCE

................................
................................
.............................
43

17.2

P
RODUCT COMPARISON MA
TRIX

................................
................................
.................
45

18

APPENDIX F RULES ENG
INES

................................
................................
....................
47

18.1

P
RODUCT COMPARISON MA
TRIX

................................
................................
.................
47

18.2

R
ULES
E
NGINE
P
ERFORMANCE

................................
................................
..................
50

18.2.1

Setup

................................
................................
................................
...................
50

18.2.2

Test Searching Through

an
ArrayList
................................
..............................
50

18.2.3

Stateless vs. Stateful Session

................................
................................
..............
51

18.2.4

Test Number of Session Invocations

................................
................................
....
52

18.2.5

Test Number of Rule Package Invocations for One Session

................................
53

18.2.6

Test Stateful Sessions in Parallel Threads

................................
...........................
55

18.2.7

Test Stateless Session in Parallel Threads

................................
..........................
56

18.2.8

Test Rule Package Execution Time

................................
................................
.....
57

18
.2.9

Test Rule Package Compilation Time

................................
................................
..
58

18.2.10

Test Rule Package Memory Usage

................................
................................
..
58

18.2.11

Test Rule Package Serialization and

Deserialization

................................
........
59

19

APPENDIX G BPEL ENGI
NES

................................
................................
......................
60

19.1

BPEL

T
ESTS

................................
................................
................................
............
60

19.2

A
PACHE
ODE

I
NITIALIZATION
P
ROBLEM

................................
................................
......
64

20

APPENDIX H ESB

................................
................................
................................
.........
65


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


4

1

Overview

1.1

Reason for the
I
nvestigation

As the Kuali Student Technical Guiding Principles stat
es,
Kuali Student is committed to a
Service Oriented Architecture (SOA) built entirely on an open
-
source Web

Service technology
stack. There are several reasons for this:

1)

The
Web Service technology stack is
currently
the only practical
open source
impleme
ntation of SOA
in that

it addresses fundamental issues of enterprise computing
such as: reliability, transactional consistency and security.

2)

Web Services
technology allows
applications to be decoupled from

the technical
infrastructure. Technology will cha
nge during the life of Kuali Student and
we cannot
afford to

be tied to a specific infrastructure implementation.
Web Services
standards

(WS*)

should

give us this loose coupling.

3)

The student domain extends beyond what is traditionally considered as the St
udent
System

into

housing, athletics,
student
clubs etc. Kuali Student encourages third party
solutions in these areas without mandating any specific technology (
for example, Web
Services works with
.
NET
,
PHP
,
J
ava,
CFM

etc
.
).


1.2

Scope of the
I
nvestigation

The purpose of the investigation was to choose core
W
eb service technologies. The key piece
here is a
W
eb service engine and an
XML
-
J
ava binding framework. Orchestration is also
considered a core part of the SOA built on web
-
services,
and so
BPEL engine
s and
Enterprise
Service Buses (
ESB
s) were also investigated
. Other technologies that are not strictly speaking
“W
eb

S
ervices


but are critical to the technical vision of Kuali
Student,

were
investigated
:

1.

R
ules engine
s

2.

R
elational database engine
s

3.

Portals


WS
-
Security

was investigated to the degree necessary to perform a proper evaluation of the
related stack components. The full

implementation of a security framework
will be completed by
the Identity Team in Phase 2.


The selection and implementation of d
evelopment frameworks (UI MVC framework, ORM
framework, build framework
,

etc
.
)
will take place in P
hase 2.


1.3

Methodology of the
I
nvestigation

Each product was examined from a number of perspectives:

1)

Global criteria such as product adoption and size of the

p
roduct’s

development team

2)

Standards compliance

3)

Licensing

4)

Product specific criteria (such as clustering and federation in the case of ESB)

5)

Performance metrics



Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


5

However, t
his was not a paper based exercise.
All

technologies we
re downloaded and tested
,
and t
hese tests were used to determine product capabilities (which often differed from the
capabilities published on the Web) and to get a solid sense of the performance of
the products
.


The products that were selected have been bundled in a simple Proof
-
of
-
Co
ncept application
which is available for download. The Proof
-
of
-
Concept is described in a separate document.

See

http://www.kuali.org/communities/ks/poc


for more information.


1.4

Conclusions

Our invest
igations
revealed that open source offerings are not as mature as we would have
liked. This was particularly evident in the lack of an implementation of WS
-
Transaction.
Nonetheless, the investigating teams did not find anything that contradicted our or
iginal
assumption
:

namely that web services are replacing J2EE as the dominant paradigm of
enterprise computing.

.

The reasoning behind our choices can be summarized very briefly:

1.

The Portal:
uPortal was selected, partly because of a community of interes
t and partly
because it is the most successful
p
ortal product in the open source community.

2.

The database: Although the project started with MySQL as a choice, this was changed
to Apache Derby. Derby can be embedded, it is under the Apache license and, in
some
tests, it outperforms MySQL.

3.

Web service engines:
In the Java world, Java annotations and JAX
-
WS have become
the
de
-
facto

standard and

this limits the choice of
quality
web service engines to CXF
and Metro.

4.

Rules engines: Only Drools met both our basi
c functional requirements and licensing
requirements.

5.

BPEL engine:
The choice was limited to ODE and OpenBPEL (Sun). Some core BPEL
functionality was missing from ODE.

6.

ESB: There is no clear industry standard

for ESB’s.
T
he closest thing to a

standard is

JBI and that limit
s the choice to OpenESB (Sun) and ServiceMix
.
ServiceMix was
chosen partly because of our commitment of a component based infrastructure (we
know our proof
-
of
-
concept will run on Glassfish).

7.

Workflow: There does not appear to be any ful
ly WS* enabled workflow engine.
Consequently, the fact that Kuali Enterprise Workflow is not web service enabled is not a
meaningful objection. And there is an obvious

community of interest with Kua
li
Workflow.


T
o summarize

current choices:

1.

Portal:



u
Portal (v2.6.1)

2.

Database:


Derby (v10.3)

3.

Rules engine:


Drools (v4.0)

4.

Web service engine:

CXF (v2.0.2) or Metro (v1.0
FCS
)

5.

Web Container:

Tomcat (v6.x)

6.

BPEL engine:


Open BPEL (from Sun)

7.

ESB:



Apache ServiceMix (v3.2.1)

8.

Workflow:


Kuali Enterprise Wor
kflow




Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


6

This remainder of this document describes the details of the decisions. Performance metrics
and comparison tables can be found in the various appendices.


1.5

Decisions that have been delayed


There
are two areas in which we did not complete our dec
ision
-
making process
:

1.

Transactions

2.

Workflow

Both are
key to meeting the technical vision for Kuali Student
.


Transactions

(more in
Section 11
)

Without a proper implementation of WS
-
Transaction we cannot build a truly inte
roperable set of
W
eb

services.
The specification for WS
-
AT
is still quite new, having been approved in
April
2007
;
there are still questions over its adoption

(e.g., how widespread will adoption be?)
. Once
these hurdles have been overcome, implementation
s should follow.


The Kuali Student decision strategy will be to monitor the open source WS* offerings over the
next 6 months for new developments in WS
-
AT. If nothing solid emerges by May 2008, a
decision will be made as outlined in
Section 11.1

(which include creation of an in
-
house
implementation, extension of an open source solution, vendor assistance, etc.).


Workflow

(more in
Section 12
)

1.

Workflow is central to the vision of Kuali Student
as

a

highly configurable set of
applications.
Because there are no fully WS* compliant workflow engines, the current
recommended approach for KS is to modify Kuali Enterprise Workflow.


Both these approaches are discussed in greater detail below.





Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


7

2

Standar
ds

2.1

Introduction

In order to meet the both the Kuali Student
technical guiding principles

and SOA architecture
guidelines such as component abstraction, reusability, loose coupling, and autonomy, widely
accepted industry standards must be used to guide the
choice of components and the
development of the system. An example of how this benefits is abstraction of the database
component. It is possible to swap databases if:

1.

The database is ANSI SQL compliant;

2.

There are JDBC compliant drivers for it;

3.

The code u
nderneath doesn’t incorporate any proprietary functionality.



As stated in the Kuali Student guiding principles, w
e want this ability to ‘plug in’ and ‘plug out’
infrastructure pieces
(component abstraction)
for all infrastructure components
.
Kuali Stude
nt is
a five to seven year effort. We do not want to be saddled with our initial technology choices for
the remainder of the project

and beyond
. So, an important part of the effort in
P
hase 1 has
been
to
understand
available
standards in greater detail.


SOA architecture guidelines affect a wide array of elements in evaluating a Web Service stack.

For example, we estimate that the Kuali Student core system will be delivered through about 50
services (possibly a bit more). This is an order
-
of
-
magnitude

e
stimate that is important in
several areas such as performance and registry complexity.

.

2.2

W3C standards

XML schema,
SOAP and

WSDL are the core standards
of web services
.
The
y are
all mature
standards developed and supported by W3C.

Kuali Student’s Web Se
rvices will be published
as WSDL’s and the domain models as schemas.
It’s worth noting here that the Web Service
engine
CXF support SOAP 1.2 and WSDL 2.0.


2.3

OASIS standards

Two OASIS standards are of particular importance to Kuali Student: WS
-
Security and
WS
-
Transaction (WS
-
TX).


In J2EE, transactional contexts and security contexts are managed by the container. In
W
eb
services

the transactional context and the security context can span across multiple services
deployed on different machines and the contex
ts are themselves managed by
W
eb services
.
The standards that define how this works are WS
-
Security and WS
-
Transaction (and these
build on more basic standards like WS
-
Policy).
It is these WS* standards that make
W
eb
-
services a viable platform for SOA (S
OAP and WSDL provide a general messaging
framework
; security and transaction
capabilities provide the framework for conducting
business).


The realization of Web services security and transaction capabilities is limited.
CXF supports
WS
-
Security but it do
es not support WS
-
Transaction. Metro appears to support both

(and

Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


8

does to the degree tested)

but the implementation of WS
-
AT does not work with Tomcat.

This
clearly poses a dilemma at this point in time.


As a result, t
he implementation of security acros
s
W
eb services
will be

one of the projects of
P
hase
II

of the Kuali Student Technical Architecture project.
Kuali Student recognizes that
t
he lack of a working implementation of WS
-
Transaction is a serious problem and our strategy
for dealing with it is
outlined in
S
ection 1
1
.

2.4

Java community standards

Although Kuali Student encourages third party contributions
that may utilize non
-
Java
technologies (such as .NET), as long as the technology is WS* compliant,
core Kuali St
udent
applications

are developed in Java

(this is a Kuali Student Technical Guiding Principle)
. For
that reason it is important that infrastructure
components

implement the appropriate Java
standards.

2.4.1

Java web services: JSR 222 and JSR 224

The two key sta
ndards
that govern the implementation of web services in Java are
:

1.

JSR 222: Java Architecture for XML Binding (JAXB) 2.0

2.

JSR
224 Java API for XML
-
Based Web Services


2.0


Kuali Student’s decision to follow the JSR 224 standard (JAX
-
WS) narrows the Web Serv
ices
e
ngine field to Sun Metro and CXF

and the
the XML
-
Java Bindin
g Framework to

Sun’s JAXB
reference implementation
.

A
xis 2.0 does not implement JAX
-
WS and that is
one

key reason it
was not selected.


2.4.2

JBI: JSR 208

There is no industry standard covering E
SB’s. The closest to a general standard is the JBI
standard
covered by
JSR 208: Java

Business Integration
. This standard is problematical in
two respects:

1.

It is directed at the Java world

2.

IBM and BEA declined to sign the spec.



Still, JBI is the closest

thing there is to a standard and it it supported by both ServiceMix and
OpenESB. This lack of standards suggests that if Kuali Student is deployed on an ESB, the
ESB must be loosely coupled from the rest of the infrastructure.

This strategy will be spel
led
out in detail in Phase 2.


2.4.3

Rules engine: J
SR

94

The invocation of an abstract rules engine is covered by JSR 94. However, the abstract rules
engine will be deployed sparingly throughout Kuali Student (in about half a dozen Decision
Services: Academic
Decision Service, Authorization Decision Service etc). Because of this,
unplugging the rules engine will not be a serious issue.
(Note:
Drools is JSR 94 compliant
).


2.4.4

Portlets
: JSR 2
86

The applicability of this standard falls within the scope of the
P
hase

2

User Interface project.


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


9

3

The Portal


Selection:
uPortal


Contenders

o

uPortal


Primary reasons for selection

o

Widespread adoption of uPortal in the higher education community

o

An obvious community of interest between uPortal and Kuali Student

o

Standards comp
liance



3.1

Comments on Selection

Kauli Student is committed to delivering the user interface through a portal
.
The exact manner
in which this is achieved is part of the
P
hase 2
U
ser
I
nterface project. In
P
hase 1 the technical
team did not do a comparative
study of open source portal projects. Rather, we started on the
assumption that uPortal would meet our needs (and investigations in
P
hase 2 will reveal
whether this assumption is justified)
.
There are three compelling reasons for this initial choice:

wid
espread

adoption of uPortal in the higher education communit
y
;

a
n obvious community of
interest between uPortal and Kuali Student
; and

s
tandards compliance
.


3.2

Selection Criteria and Evaluation

3.2.1

Widespread adoption

uPortal has seen wide acceptance and deploym
ent in higher education.
Some examples:

1.

The uPortal site references 95 production implementations (see
http://www.uportal.org/who
-
prod.html
)

2.

In addition to the 95 implementations referred to above, uP
ortal is used throughout
France as a standard portal for institutions of higher education (see
http://www.esup
-
portail.org/communaute/
). This is also evidence that uPortal successfully supports
inte
rnationalization.

3.

It has been re
-
packaged in the SunGuard SCT Luminis product.



3.2.2

Community of interest

There are common interests between the uPortal community and the Kuali Student community

1.

uPortal is a target product for the Fluid project. KS may be a
ble to meet some
accessibility and usability requirements, simply by employing uPortal.

2.

The Kuali Student project is in a position to influence uPortal directions.

3.

Deficiencies in uPortal can be addressed through contributions

from Kuali Student
develope
rs

4.

The uPortal community has an active set of contributors addressing internationalization
issues, in both Europe and Asia



Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


10


3.2.3

Standards compliance

uPortal supports the JSR
-
168 portlet specification, and will soon support JSR
-
286 (
and may be
the first to do
so).
.


3.3

Issues

As mentioned above, Phase 2 will reveal the pros and cons of using uPortal. One issue of
interest is determining how easy it will be to swap portals.



Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


11

4

The database


Selection:
Apache Derby


Contenders

o

Derby

o

MySQL


Primary reasons for selec
tion

o

Pure Java

o

Embeddable

o

Performance

containers

4.1

Comment
s

on

Selection

D
atabase selection focused on both development phase and deployment phase concerns
.
While Kuali Student cannot require a specific database for deployment, we do need to provide
one w
ith our "Test Drive" version
.
F
ollowing is a list of requirements

and
how
Derby and
MySQL each fit with the requirement
s.


4.2

Selection Criteria and Evaluation


Development phase

Easy setup, teardown, cloning, etc of development databases. This is important

for unit testing
as well as ease of change management.

o

Derby

o

No installation required. Derby is included by default with Java 6, or can be
bundled within the Kuali Student application itself.

o

Databases can be dynamically created or recreated even at run
time if necessary

o

Databases can be started and stopped by the program itself

o

MySQL

o

Requires installation

o

Cloning can be done via MySQL, but is far more complicated than with Derby

o

Starting and stopping MySQL requires calls outside of Java


Deployment phas
e

A key requirement is b
undled redistribution

o

Derby

o

Can be easily bundled either within the Java application itself, or bundled with the
distribution package and launched via the same startup scripts as the "Test
Drive" bundle.

o

License allows for redist
ribution

o

MySQL

o

Requires installation

o

License allows for redistribution



Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


12

Database performance should not present an issue due to limited data set sizes and minimal
load during development, nor in a "Test Drive" phase. Both Derby and MySQL should scale well

for small to medium installations, though, given the performance metrics shown in Appendix B.

4.3

Issues

The usability of Derby in a highly intensive production environment is not known. To address
this issue,
we intend

to deliver Kuali Student Test Drive as

“certified” in Oracle, MySQL, and
Derby.

The Development Team will address this in Phase 2.


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


13

5

Servlet engines


Selection: Tomcat


Contenders

o

Tomcat

o

Glassfish

o

Jetty


Primary reasons for selection

o

Popularity

o

Standards compliance

o

Tomcat is the reference im
plementation for servlet containers

o

Ease of configuration

o

Tomcat is simply an "unzip" installation, although more configuration options are
available such as a windows service, etc.


5.1

Comment
s

on Selection

Kuali Student aims for a standardized deployment
without any dependencies on a specific
application server or servlet container. As such we are recommending the use of Tomcat, which
is the reference implementation for the servlet and JSP specifications. Tomcat is easily
redistributed, and as the performa
nce metrics indicate, fast.


Tomcat is not a complete J2EE application server like Glassfish
. However, m
any of the J2EE
features that Glassfish provides, such as a web service engine (Metro) and a JMS queue, can
be added onto Tomcat.




Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


14

6

XML
-
Java binding


S
election: JAXB
(
Sun
’s

reference implementation
)


Contenders

o

Sun’s JAXB Reference Implementation

o

JiBX

o

Castor

o

XMLBeans


Primary reasons for selection

o

JAXB is a JSR specification (JSR 222)

o

Based on XML schema

o

Multiple implementations available

o

Backwards com
patible from current (2.1) to original 1.0

o

Excellent tool support as well as Eclipse
plug
-
ins

o

Included in Java 6

o

Reference implementation outperformed other contenders


6.1

Commen
t
s on
Selection

XML binding simply refers to converting Java data structures to X
ML, and XML to Java data
structures. JAXB is a specification that uses Java annotations and XML schema to define types
and type conversions. JAXB goes hand
-
in
-
hand with JAX
-
WS

(s
ee the
Web Service Engine

summary fo
r more informatio
n on the choice of JAX
-
WS as one of the core technology
standards chosen by Kuali Student).


6.2

Selection Criteria and Evaluation

JAXB supports round
-
trip generation of XML schema from Java code, and Java code from XML
schema


By adopting the

JAXB/Java
-
annotations
(JAX
-
WS)
standard, Kuali student effectively eliminated
two other contenders: Castor and JiBX. Both these products rely on a different binding
mechanism: namely an external binding file.
JiBX raises a further concern
in

that it pos
t
-
process byte code. This can cause complications in the build and deployment environments.


XMLbeans was slower than the Sun JAXB reference implementation and it did not produce
clean stubs. Also it does not appear to support JSR222.

6.3

Issues

6.3.1

Performance
concerns

If there

are still lingering concerns
that marshalling

and un marshalling XML is a performance
issue

nearly all
of the investigations of
P
hase 1 of Kuali Student indicate that this is

not
the
case
:


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


15

1.

The
perfor
mance metrics

of various framewor
ks for

XML binding show that
performance
in this area
is a trivial concern.

2.

Kuali Student will be delivered as a set of about 50 services.
These
services
will be

coarsely
-
grained th
ereby

minimizing the
amount of latency due to traffic




Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


16

7

Web
-
service engines


Sel
ection: CXF, Metro


Contenders

o

Axis 2

o

CXF

o

Metro


Primary reasons for selection

o

A
t this point, the selection of either CXF or Metro is relegated to Phase 2
.


7.1

Reasons for the Selection

Standards compliance became the primary focus of the web service engine

evaluation. The
core standard required is JAX
-
WS. The JAX
-
WS specification is a JSR standard that defines a
set of annotations used to “mark up” Java code with metadata relating to XML and Web
Services. Using these annotations
,

Java code
can
be reliabl
y

translated to XML and
XML
reliably translated

to Java code. Web Service
-
specific information can also be annotated, such
as service endpoints, etc. Taking advantage of "round trip" generation of either Java code from
WSDL, or WSDL from Java code will a
llow developers to use a wide range of XML and Java
development tools. In addition, as previously mentioned in section 1.4, JAX
-
WS and JAXB
(which are closely related) have become de facto standards in the Java community. Axis2 is
not a viable option due

to lack of support for JAX
-
WS.


Other important standards are the WS
-
* specifications, such as WS
-
Security and WS
-
Transaction. The technical teams determined that WS
-
AtomicTransaction will be required as an
integral piece of the Kuali Student stack
.
Unfo
rtunately, the only functioning implementation of
WS
-
AtomicTransaction that has a license compatible with the Kuali Student project requires use
of the full Glassfish J2EE application server. The Apache CXF team is currently working to
implement core WS
-
*
standards, and there is also a chance that WS
-
AtomicTransaction will be
supported by Metro on Tomcat in the future. Due to this issue, the decision was made to
postpone the final decision until later in the project.


7.2

Issues

The postponed decision does not
present as large of a problem as it may seem. Replacing one
JAX
-
WS compliant service engine with another one does not require any significant changes to
the underlying Java code, nor should it require any changes to the service consumer, provided
the syste
m is properly implemented
.
In addition, it will not be until later phases of the project
that we will have any significant number of services requiring conversion, if we do decide to
select a different JAX
-
WS compliant service engine.


For now we will def
er the decision until later in Phase 2 and will make a more educated
selection once other factors (such as a final service bus and architecture) have been settled.



Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


17

8

Rules engines


Selection: Drools (J
B
oss/Redhat)


Contenders

o

Drools

o

SweetRules

o

OpenRules


P
rimary reasons for selection

o

Licensing

o

IDE integration


o

XML support

o

do
main
-
specific language support

o

repository support.


8.1

Comments on Selection

Rule engine triage

was basically driven by licensing considerations. Most of the open
-
source
offerings are enc
umbered by GPL/LGPL restrictions. One fairly promising offering
, OpenRules

stated that its licensing was based on a "modified Mozilla license." A cursory reading of this
modified license revealed that it was
even more restrictive than GPL,

with specific
restrictions as
to RDBMS platforms and the like. Outreach to another offering
was also

unproductive.


8.2

Selection Criteria and
Evaluation


Rule engine evaluation was of course driven by more detailed technical considerations including
but not
limited to IDE

integration, XML support,

domain
-
specific language support, repository
sup
port,

as well as "mindshare" and "half
-
life" considerations.


Happily and serendipitously, triage and evaluation efforts arrived at the same
conclusion/selection for "declarative ru
le engine"
--

drools from
JB
oss/
R
edhat. Major positive
features include:

o

Robust
plug
-
in

for the eclipse IDE

o

Multiple authoring modes.

o

J
ava
-
friendly

o

xml

o

decision
-
table in excel

o

graphical rule
-
flow editor

o

guided wizard
-
style

o

Rudimentary repository sup
port based on java content management standard
(implemented via apache JackRabbit).



The team was able to make contact with the drools project lead at the RuleML conference in
Orlando in October, and is active on the project mailing list. Also
a

test
-
driven development
environment and methodology base on FitNesse is under
development
.


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


18



Subsequent research and discussions at the November FSU workshop has led to thinking about
"Enterprise Decision Management"
--

a rules engine is one (albeit major) piec
e of plumbing in
decision management.

8.3

Issues

Drools is an abstract rules engine. By itself it does not supply the full set of capabilities
described in the Kuali vision. For this we need a set of capabilities built on top of the abstract
rules engine. W
e call these capabilities the Business Rules Management System

(BRMS)
. The
core of the BRMS is a database that:

1.

C
ontains all the rules and

2.

Indexes and classifies all the facts and actions of all the rules.

The capabilities of the BRMS support:

1.

A set of

user interfaces that allow end
-
users to define academic regulations and other
business

rules;

2.

Enterprise reporting on the rules base
;

3.

A set of decision services that implement rules engine capabilities in the different
functional domains (such as an Acade
mic Decision Service that could support different
applications such as Enrolment,

Degree Audit and Admissions);

4.

Running what
-
if scenarios


Building the BRMS is scheduled for January
-
May 2008. The user interfaces should be built as
part of the Configurati
on Application in the June


October 2008 timeframe.



The illustration below (Figure 1


KS BRMS) is a schematic representation of the BRMS as an
application that sits between the abstract rules engine (Drools) and the various KS functional
applications


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


19


8.4

Figure 1


KS BRMS






Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


20

9

BPEL


Selection: Sun OpenESB BPEL


Contenders

o

Apache ODE

o

Sun OpenESB BPEL

o

J
Boss


Primary reasons for selection

Open Source BPEL technology is not ready for a highly reliable and scalable enterprise
system. However, we will revis
it the question of BPEL and workflow in the KEW POC
project (see
Section 12.3
).



9.1

Selection Criteria and Evaluation


The two engines evaluated were Apache ODE and Sun OpenESB BPEL, with the Sun engine
sel
ected as our choice
.
We also looked at J
Boss
, but did not perform a full evaluation because
it was labeled experimental at the time and the samples bundled with the product would not
work.


In our tests BPEL was portable between the two engines (with the
exception of one test case
and as long as the engine supported the tags), requiring only modifications to deployment
descriptors external to the BPEL itself. We intentionally avoided the use of any extensions or
custom tags.


The Sun engine supports most B
PEL tags and features a fully functional graphical editor and
test environment bundled with Net
B
eans
.
It is only available as a service engine deployable on
a JBI bus. We were able to deploy onto the Apache ServiceMix JBI bus, though there are
unresolved
issues using the newest release of each.


The Apache engine is deployable in a servlet container or on a JBI bus. It supported similar tags
to the Sun engine with the exception of forEach
.
The issue has been fixed in the ODE code
repository, but it has no
t been released for us to test.


Neither engine supported parallel forEach, which limits
us to
serially processing a list of similar
elements and
to
hard coding the number of threads. Another feature both engines lacked was
support for compensating transa
ctions, which would be essential for long running processes.


The main difference in functionality is that the Apache engine requires initialization of all
variables not received from a service call with a hard coded XML message skeleton. This
makes it im
possible to create a dynamic sized list of elements or add to an existing message
.
We feel this does not follow our interpretation of the BPEL 2.0 specification, and will limit the
possible applications of BPEL using the Apache Engine.

See
Appendix G

for an example of the
variable initialization problem in Apache ODE.


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


21


While both engines have similar support for the BPEL specification, we feel the variable
initialization issue with Apache ODE outweighs the limited dep
loyment options of the Sun
engine. The Sun engine seems to be more actively developed than Apache, and looks like it is
the cornerstone component of OpenESB as most of the ESB samples and tutorials use it.
These factors and the integrated graphical enviro
nment are the reasons why we chose the Sun
engine.


9.1.1

Potential Uses


Persistent, stateful processes led us to believe that workflow might be one such use

for BPEL
.
We found that BPEL did not contain any high level constructs targeted towards workflow and
w
hile a workflow system could be built using BPEL, the bulk of the work is left to be
implemented. We did not find any BPEL based workflow products, but noted some extensions
and helper components were under development (BPEL4People, WLMSE
-

http://wiki.ope
n
-
esb.java.net/Wiki.jsp?page=WLMSE). It is also useful to note that BPEL is not very well suited
to represent a specific workflow instance, but rather a workflow pattern
.
For example, routing a
document would not show the list of people in BPEL, but rathe
r a loop calling a “getNextPerson”
service.


BPEL seems best suited for service integration and can quickly be configured to provide content
based routing, message transformation/splitting/aggregation, and content enrichment (similar
features are also pro
vided by some ESBs)
.
This would allow institutions to customize Kuali
Student without modifying code. Use cases from the function teams should be individually
evaluated to determine if it is best to use BPEL instead of code.


Although BPEL was considered

for use by the functional users, it is still too much of a low level
language for general functional user consumption
.
Sun’s Netbeans editor is the most complete
graphical BPEL designer, including the ability to fluidly switch between graphical and XML e
ntry,
but even with the graphical interface it still requires knowledge of WSDL, XML Schema, and
debugging. The graphical display would make an excellent way for technical developers to
demonstrate and develop processes with the functional users.


9.2

Issues

Open Source BPEL technology is not ready for a highly reliable and scalable enterprise system.
However, we will revisit the question of BPEL and workflow in the KEW POC project (see
Section 12.3
).




Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


22

10

ESB


Selection: Apache ServiceMix


Contenders

o

Apache ServiceMix

o

Sun OpenESB

o

Apache Synaps
e


o

Mule

o

Kuali Service Bus


Primary reasons for selection

Kuali Student will need an ESB infrastructure to provide real time location of its services in
order to avoid h
ard coded service URLs or complex configuration files requiring
customization for each institution. We are hoping to leverage the capabilities to allow
institutions to replace or modify standard Kuali Student components without having to
modify the code ba
se. Legacy integration is often associated with ESBs, but we did not
evaluate any features intended for that sole purpose (although many features useful to
Kuali Student will also aid with legacy integration).


10.1

Selection Criteria and Evaluation

10.1.1

Criteria

O
ur evaluation focused on the following key areas: service registry, routing and transformation,
configuration (clustering, federation, deployment options), and WS
-
* compatibility. In our testing
we intentionally avoided functionality that would introduce
dependencies in our service code.
Benchmarking was performed to test performance and scalability.


10.1.2

Product Space

Evaluations were performed on Apache ServiceMix, Sun OpenESB, and Apache Synapse.
Mule and Kuali Service Bus were looked at, but full evaluat
ions were not performed.

10.1.2.1

ServiceMix

The registry is internal and automatically updated when services are deployed; this eliminates
the need for custom configuration files. ServiceMix offers the most routing and transformation
options of all the buses eval
uated. Clustering, with load balancing of services, is supported, but
services must be manually deployed to each instance
.
Federation is also supported, enabling
an environment where services hot deployed on any bus are instantly recognized by each bus.

ServiceMix leverages the Apache CXF web service engine, adding to it the capability to hot
deploy individual services and providing a lightweight service packaging option. Fewer
configurations are required to get a web service running on ServiceMix than
CXF running on
Tomcat.


The documentation does not contain complete examples and often test cases from the code
repository must be referenced. This is not surprising since ServiceMix offers a vast amount of

Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


23

configuration options and features. The benchma
rk tests revealed ServiceMix to have the most
latency of all the buses, but this is most likely due to the SEDA flow which allows it to have more
constant response time as load increases.

10.1.2.2

OpenESB

The registry is internal and automatically updated when serv
ices are deployed (similar to
ServiceMix). An XSLT engine is provided to perform message transformation. OpenESB
supports clustering and deployment of services will propagate to all clustered servers.
OpenESB performed the best in our benchmark testing.


OpenESB relies on BPEL to provide routing capabilities, this requires a larger amount of
configuration than the options provided by the other buses. Federation is not supported which
requires services on other buses to be manually added to the registry.

The documentation
contains complete examples, but these all require the use of the Netbeans IDE. Some of the
capabilities we tested could not be configured in Netbeans and this greatly hindered our
progress. We were unable to deploy some services built

outside of the IDE and found
inconsistent results when trying to deploy JAX
-
WS services to the bus.

10.1.2.3

Synapse

Synapse is more an HTTP/Soap router than an ESB. It provides all but one of the routing
capabilities we were looking for as well as message transf
ormation. Synapse supports
federation with the capability to share registry information across multiple instances.
Configuration was straight forward and numerous examples were provided in the
documentation.


Deployment of services is not supported by Sy
napse so all registry information must be
manually entered. Synapse is the only bus evaluated that does not support load balancing of
services. Performance degraded as load increased during benchmark testing until it began to
produce errors.

10.1.2.4

Other Produc
ts

We investigated Mule, but found it necessary to write code in order to proxy a service and
decided that this was undesirable. The Kuali Service Bus came close to meeting our needs, but
it did not include support for JAX
-
WS, was tightly coupled with the

other RICE products, and
some code dependencies were introduced when using the bus to call other services. The KSB
was the only bus to provide an HTTP display of its complete service registry. If these issues are
addressed in a future release of the KSB

then it would be a viable solution.


10.1.3

WS
-
* Compatibility

The purpose of this evaluation was to determine how SOAP headers were processed by the
bus. We found very little documentation in this area and resorted to working with the web
service engines that
each bus was based on and then trying to port those settings to the ESB.


We concentrated on WS
-
Security as WS
-
Reliable Messaging only applies to messages external
to the bus and WS
-
Atomic Transaction is only implemented on one
W
eb service engine when
depl
oyed to one specific J2EE container.



Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


24

All three ESBs supported the username, certificate signing, and encrypting security
mechanisms. The standard for each bus was to remove the header before sending the
message to the destination service. In ServiceMix
the security context is not provided to the
W
eb service and according to IONA developers this is intentional (they did suggest a
workaround). According to the documentation for OpenESB security context should be
available to the service, but we did not fi
nd this to be the case. Synapse can be configured so
the security header is passed through without being processed (this is not standard protocol for
SOAP nodes).


At this time we do not know if this will be an issue or not. It will depend on the directi
on taken by
the Identity
T
eam in
P
hase 2.


10.2

Comments on Selection

Apache ServiceMix is the ESB that best meets the needs for Kuali Student. It can run on a
servlet container or standalone, provides the most functionality, and is highly configurable
without

depending on an IDE. We found the ServiceMix forums to be responsive to our
inquiries and the product is commercially supported by IONA.


It’s very much worth noting that
T
he Mellon Foundation
-
sponsored ESB exploratory committee
also selected Apache Serv
iceMix as their top
-
rated open source ESB. Their findings can be
found at:


http://tid.ithaka.org/enterprise
-
service
-
bus/mellon
-
esb
-
final
-
pres
-
v17.pdf

http://tid.ithaka.org/enterprise
-
service
-
bus/
esb
-
narrative
-
rc
-
4.pdf


10.3

Issues

The Kuali Service Bus was currently unable to meet the needs of Kuali Student in three areas:

1.

Lack of support

for JAX
-
WS;

2.

Its tight coupling with other RICE products;

3.

Code dependencies introduced when using the bus to call other services.


Kuali Student looks forward to continued partnership with the RICE team to address these
issues.


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


25

11

Transactions


Selection: NO
NE AT THIS TIME


Contenders

o

None


11.1

Comments on Selection

Primary reasons for
lack of
selection

o

Unable to find solution that implemented WS
-
Transaction

o

Could not find an Open Source Solution in this product space


The ability to define transactions that sp
an multiple web service
s is a fundamental requirement
of an enterprise system. Kuali Student has to have a solution before we deliver product.


Unfortunately, we were unable to find a solution that:

o

Implemented WS
-
Transaction

and

o

M
et

our general selecti
on criteria for an open source solution


There is a commercial implementation by a company by the name of Atomikos. While they
have open
-
sourced their implementation of JTA, their implementation of WS
-
AT remains
proprietary. Sun has an implementation but
it appears to be tightly bundled with the Glassfish
suit
e and the KS technical team was

unable to get it to work with Tomcat.


11.2

Issues

11.2.1

Mitigation

W
e did define a strategy and

a set of options to e
nsure that we

arrive at a s
olution. These are
the choices:


1.

Write our own “bare
-
bones” implementation of WS
-
AT. We need to determine the effort
required.

2.

Modify the Sun implementation (fork the code). We need to determine the effort
required.

3.

Collaborate with Sun to modify their implementation.

4.

Persuade Atomikos

to open
-
source their implementation (their JTA implementation is
already open source)

5.

Hope that an existing open source

community implements a solution.
There was a
soluti
on for Axis 1.0, but the WS
-
AT project for Axis 2 does not
seem
to be moving
forw
ard. For some

reason the CXF community do not appear to have WS
-
AT on their
road
map
. However, the community is continually changing, and what is true t
oday
(December 2007) may not be

true in six months time.



Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


26

11.2.2

Next Steps

1.

We
will
designate one

tech
nical te
am lead to
research possible developments

once a

month between January 2008 and May 2008.

2.

We ask the Kuali Student Board to see if we can leverage strategic relationships to get
movement on options 4 and 5.

3.

If there is not a solution

by May 2008,

then we c
hoose between options

1, 2 and 3. The
i
mplementation becomes part of

the Phase 3 Technical Architecture project.


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


27

12

Workflow


The Kuali Student technical team is recommending that Kuali Enterprise Workflow be used as
the workflow engine for Kuali Student. K
EW already meets some of the SOA WS* features
including WS
-
Security and is committed to furthering their support for the WS* specifications as
open source libraries continue to evolve to support these specifications more fully
.
Furthermore, KEW is a matur
e product that has been used in production for several years.


However, there are some possible outstanding issues and we need to consider:

1.

An integration strategy

2.

Possible enhancements to KEW beyond a “bare
-
bones” integration



12.1

Possible integration issues


The only way to answer these questions in a detailed manner is to create a POC.


There are still some unanswered questions regarding the integration of KS and KEW. KS
needs to be able to consume and deliver services as web
-
services. There are three dim
ensions
to this:

1.

Endpoints need to be exposed as SOAP/WSDL endpoints

2.

Consumers and providers must implement core WS* standards:

a.

WS
-
Atomic Transaction

b.

WS
-
S
ecurity

3.

Interface definitions must be optimized for remote access.


There are a range of possible o
utcomes:

1.

The integration may turn out to be trivial because:

a.

The interface definitions that KS needs are already available as SOAP/WSDL
endpoints

b.

The WS* standards are easy to implement (for example, a simple JTA
-
WS/AT
bridge)

2.

The integration may turn out
to be problematical due to some unforeseen technology
mismatch.


12.2

Integration approach

The integration project should be scheduled for the May timeframe. By that time we will have:

1.

An strategy for WS Atomic Transaction

2.

A set of working services (from ident
ity and rules management) that we can use in a
workflow scenario


The integration project would be considered part of the Kuali Student Configuration application
project and would span the first three weeks of May:

1.

Design a POC around a trivial use case (
first week of May)


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


28

2.

A KS
-
KEW team (1 developer from each) can work on the POC for 2 weeks. They may
need to be geographically co
-
located).


The outcome of this project would either be:

1.

A completed integration

2.

A recommendation on the amount of work needed t
o complete the integration


12.3

Possible further enhancements

Once we have answered basic questions about integration (amount of work and resources), we
can consider a number
of possible

further enhancements to Kew:

1.

Integration of the rules engine for routing
decisions

2.

A graphical user interface for routing (this could come for free as part of the rules engine
technology)

3.

The workflow engine calling out to a BPEL engine to execute a set of activities
.


Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


29

13

Swappable Infrastructure


A core part of the vision of Kuali

Student is to provide a clear separation between the application
layer and the infrastructure layer

and to keep components in the infrastructure layer as
independent as possible via standards
.
The following discussion attempts to put some clearer
focus a
round what we do understand and to suggest where we will get a better understanding
later in the project.


The following questions will be addressed:

1.

What do we mean by “swappable infrastructure”?

2.

What are the main drivers behind the concept of swappable i
nfrastructure?

3.

What are the constraints around swapping out different layers of the infrastructure?

4.

Where does responsibility lie for testing assumptions about swappable
infrastructure?


This document, and this section in particular, will change as we prog
ress through the Kuali
Student project: as we better understand the open source technologies we’ve chosen; as
standards are more widely adopted and adhered to; and as the open source landscape itself
changes. In other words, this is a living document that

will continually reflect our current
understanding of the technology used in Kuali Student.

13.1

What do we mean by “swappable infrastructure”?


During the technology investigation phase (Technical Architecture Phase I), we have been using
the term “swappable
infrastructure” in two different senses:


1.

The ability to swap out the entire infrastructure suite (i.e., SOA/Web Services stack)
without worrying about the details of what makes up the stack.


2.

The ability to swap out individual infrastructure components of

the Kuali Student
reference implementation infrastructure. The Proof
-
of
-
Concept (POC) illustrates this in a
limited way:

a.

Two different service engines are used:

i.

Apache CXF

ii.

Sun Metro

In the context of swappability, it is worth noting that the same service

implementation was deployable on both CXF and Metro unchanged. The service
implementations were not complex, and the ability to use the same service
implementation for both engines may change as complexity increases.

b.

Some services are run on the bus, oth
ers are run off the bus (so the entire bus
can be swapped out of the architecture).


We are looking to Sun and IBM will test the first point. The experiment should give us a clear
definition of what constitutes the “application.” At present we think it c
onsists of a set of
schemas, WSDLs, BPEL scripts and Java code. Figure 1 shows a general view of Kuali
Student running on the Sun Web service stack and the IBM Web service stack.




Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


30

Figure 1

-

Kuali Student running on two different vendor stacks


a) the S
un
W
eb service stack

b) the IBM
W
eb service stack




Figure 2 shows how t
he
stack selected during Phase 1 of the technology project should allow us
to swap out infrastructure components at a more finely grained level. In this
illustration:


1.

Componen
ts in yellow have been “
certified


2.

Components in blue are
expected

to work because of standards compliance


Figure 2

A Kuali Student reference implementation




Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


31

13.2

What are the main drivers behind the concept of swappable infrastructure?


The drivers can be c
ategorized as:


1.

Obvious leapfrog

-

when it's clear that one product is significantly better and should
replace the one currently in the
reference implementation
stack
. It provides needed or
desired functionality.

2.

Stakeholder interest

-

a founder

or
partne
r wants to replace a component
for whatever
reason.

3.

Continuous research

-

investigation

to stay on top of open source solutions in order to be
aware of products that could/should be replaced in the stack
.


The
se

drivers will vary for different layers of th
e infrastructure
. For example:


1.

At the service engine level, the key driver may be the volatility of current offerings as
different open source implementations leapfrog each other. Even within the short
timeframe between the creation of Kuali Student and

the completion of Phase 1, there
were significant changes in the relative standings of Axis, Metro, and CXF.


2.

At the machine/OS level the drivers will
probably be institution specific:

a.

Price/performance

b.

Existing institutional infrastructure

c.

Existing exper
tise and support structures


3.

At the database level, the key drivers are expected to be institution specific:

a.

Existing institutional infrastructure

b.

Existing expertise and support structures

Note that many of the founders will likely continue to run Oracle s
o there should be
strong support for an Oracle implementation.


13.3

What are the constraints around swapping out different layers of the
infrastructure?

13.3.1

Operating system

Kuali Student should work on any OS for which there is a Java Virtual Machine
implementat
ion. This should include:

1.

Solaris

2.

Linux

3.

Windows server


Two operating systems will be continuously tested by the Kuali Student development team as
most developer sandboxes will be running a Windows OS and Kuali Servers will run Linux.
Kuali Student will
also be certified on VMware.



Kuali Student Servi
ce System

Technical Architecture Phase 1 Recommendations



Technical Architecture
Phase 1 deliverables

3/15/2013


32

13.3.2

Portal

Kuali Student portlets should be deployable on any JSR 168 compliant Portal. This is
currently part of the Team 1 UI investigation.

13.3.3

Database

In Kuali Student a database product can be used (swapped) if it is supported
by the JPA
compliant ORM tool Kuali Student selects. We are talking about standards built on standards.
The compliance stack for the Kuali Student database is:


1.

JPA


Java Persistence API. This Java toolkit allows data to be represented
equivalently in
both Java code and in XML.

2.

JDBC


These are the low
-
level database
-
specific drivers that allow Java to talk to the
database.

3.

ANSI SQL


This is the standard that acts as the lowest common denominator in data
access languages. All large databases support A
NSI SQL.


However, there are non
-
swappable aspects of a database to be considered as well. While
there are several databases that meet the above three standards, there is much more to a
database than simply binding to an application. The physical/logical

deployment of a
database on file systems is not covered by standards. Nor is the administration of the
database environment: backup/recovery procedures, optimization etc. Each implementation
team will have to take on this work. Space requirements and p
hysical file structures will vary
from one institution to another and so each database deployment will, to some extent, be
unique.

13.3.4

Service engine layer

Web service technologies that are compliant with JAXB (Sun’s XML binding reference
implementation) and J
AX
-
WS (Java language support for Web services) should work with
Kuali Student. The POC uses two Web service engines:

o

Metro

o

CXF


Testing out different service engines could be part of the on
-
going responsibilities of the
architecture team. Or, it could be

the responsibility of the implementation teams. The extent
to which swapping Web service engines can be automated will depend on:

o

Whether we specify interfaces using WSDL
-
First or Java
-
First

o

The extent to which we modify generated artifacts such as WSDL
and Java interfaces.

The answer to these questions will become clearer in Phase 2 of the project.


By choosing a JAXB
-
compliant binding framework, we will not have to re
-
write binding files (as
we would have done had we chosen Castor or JiBX).

13.3.5

ESB

At this
time, there are only two implementations of the JBI
-
specification, Sun Open ESB, and
Apache ServiceMix. These two implementations were not, in their current state, easily