Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
December 31 2007
Kuali Student Technical Team
Technical Architecture Phase 1 deliverables
3/7/2016
1
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Table of Contents
1
OVERVIEW ........................................................................................................................ 4
1.1
1.2
1.3
1.4
1.5
2
REASON FOR THE INVESTIGATION ................................................................................... 4
SCOPE OF THE INVESTIGATION ....................................................................................... 4
METHODOLOGY OF THE INVESTIGATION .......................................................................... 4
CONCLUSIONS ............................................................................................................... 5
DECISIONS THAT HAVE BEEN DELAYED ............................................................................ 6
STANDARDS ..................................................................................................................... 7
2.1
INTRODUCTION .............................................................................................................. 7
2.2
W3C STANDARDS .......................................................................................................... 7
2.3
OASIS STANDARDS ....................................................................................................... 7
2.4
JAVA COMMUNITY STANDARDS ........................................................................................ 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
COMMENTS ON SELECTION ............................................................................................ 9
3.2
SELECTION CRITERIA AND EVALUATION .......................................................................... 9
3.2.1
Widespread adoption ............................................................................................ 9
3.2.2
Community of interest ........................................................................................... 9
3.2.3
Standards compliance .........................................................................................10
3.3
ISSUES.........................................................................................................................10
4
THE DATABASE ...............................................................................................................11
4.1
4.2
4.3
5
SERVLET ENGINES .........................................................................................................13
5.1
6
COMMENTS ON SELECTION ...........................................................................................11
SELECTION CRITERIA AND EVALUATION .........................................................................11
ISSUES.........................................................................................................................12
COMMENTS ON SELECTION ...........................................................................................13
XML-JAVA BINDING.........................................................................................................14
6.1
COMMENTS ON SELECTION ...........................................................................................14
6.2
SELECTION CRITERIA AND EVALUATION .........................................................................14
6.3
ISSUES.........................................................................................................................14
6.3.1
Performance concerns .........................................................................................14
7
WEB-SERVICE ENGINES .................................................................................................16
7.1
7.2
8
REASONS FOR THE SELECTION ......................................................................................16
ISSUES.........................................................................................................................16
RULES ENGINES..............................................................................................................17
8.1
COMMENTS ON SELECTION ...........................................................................................17
Technical Architecture Phase 1 deliverables
3/7/2016
1
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
8.2
8.3
8.4
9
SELECTION CRITERIA AND EVALUATION .........................................................................17
ISSUES.........................................................................................................................18
FIGURE 1 – KS BRMS ..................................................................................................19
BPEL .................................................................................................................................20
9.1
SELECTION CRITERIA AND EVALUATION .........................................................................20
9.1.1
Potential Uses......................................................................................................21
9.2
ISSUES.........................................................................................................................21
10
ESB................................................................................................................................22
10.1
SELECTION CRITERIA AND EVALUATION ......................................................................22
10.1.1 Criteria .................................................................................................................22
10.1.2 Product Space .....................................................................................................22
10.1.3 WS-* Compatibility ...............................................................................................23
10.2
COMMENTS ON SELECTION ........................................................................................24
10.3
ISSUES .....................................................................................................................24
11
TRANSACTIONS ...........................................................................................................25
11.1
COMMENTS ON SELECTION ........................................................................................25
11.2
ISSUES .....................................................................................................................25
11.2.1 Mitigation .............................................................................................................25
11.2.2 Next Steps ...........................................................................................................26
12
12.1
12.2
12.3
13
WORKFLOW .................................................................................................................27
POSSIBLE INTEGRATION ISSUES .................................................................................27
INTEGRATION APPROACH ...........................................................................................27
POSSIBLE FURTHER ENHANCEMENTS..........................................................................28
SWAPPABLE INFRASTRUCTURE ...............................................................................29
WHAT DO WE MEAN BY “SWAPPABLE INFRASTRUCTURE”? ............................................29
WHAT ARE THE MAIN DRIVERS BEHIND THE CONCEPT OF SWAPPABLE INFRASTRUCTURE?
31
13.3
WHAT ARE THE CONSTRAINTS 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
WHERE DOES RESPONSIBILITY LIE FOR TESTING ASSUMPTIONS ABOUT SWAPPABLE
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
13.1
13.2
14
APPENDIX A STANDARDS ..........................................................................................35
Technical Architecture Phase 1 deliverables
3/7/2016
2
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
15
APPENDIX B DATABASES .........................................................................................36
15.1
15.2
15.3
15.4
15.5
16
DATABASE PERFORMANCE STATISTICS .......................................................................36
PRODUCT COMPARISON MATRIX ................................................................................37
APPENDIX C SERVLET ENGINES .................................................................................38
SERVLET ENGINES PERFORMANCE ............................................................................38
PRODUCT DATA MATRIX ............................................................................................39
APPENDIX D XML BINDING FRAMEWORK ...............................................................40
16.1
16.2
17
XML BINDING PERFORMANCE ....................................................................................40
PRODUCT DATA MATRIX ............................................................................................41
APPENDIX E WEB SERVICE ENGINES .......................................................................43
17.1
17.2
18
ENGINE PERFORMANCE .............................................................................................43
PRODUCT COMPARISON MATRIX .................................................................................45
APPENDIX F RULES ENGINES ....................................................................................47
18.1
PRODUCT COMPARISON MATRIX .................................................................................47
18.2
RULES ENGINE PERFORMANCE ..................................................................................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 ENGINES ......................................................................................60
19.1
19.2
20
BPEL TESTS ............................................................................................................60
APACHE ODE INITIALIZATION PROBLEM......................................................................64
APPENDIX H ESB .........................................................................................................65
Technical Architecture Phase 1 deliverables
3/7/2016
3
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
1 Overview
1.1
Reason for the Investigation
As the Kuali Student Technical Guiding Principles states, 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
implementation 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 change 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 Student
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, Java, CFM etc.).
1.2
Scope of the Investigation
The purpose of the investigation was to choose core Web service technologies. The key piece
here is a Web service engine and an XML-Java binding framework. Orchestration is also
considered a core part of the SOA built on web-services, and so BPEL engines and Enterprise
Service Buses (ESBs) were also investigated. Other technologies that are not strictly speaking
“Web Services” but are critical to the technical vision of Kuali Student, were investigated:
1. Rules engines
2. Relational database engines
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 development frameworks (UI MVC framework, ORM
framework, build framework, etc.) will take place in Phase 2.
1.3
Methodology of the Investigation
Each product was examined from a number of perspectives:
1) Global criteria such as product adoption and size of the product’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
Technical Architecture Phase 1 deliverables
3/7/2016
4
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
However, this was not a paper based exercise. All technologies were downloaded and tested,
and these 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-Concept 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 investigations 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 original
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 interest and partly
because it is the most successful portal 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 basic 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. The closest thing to a standard is
JBI and that limits 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 fully 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 Kuali
Workflow.
To summarize current choices:
1. Portal:
uPortal (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.0FCS)
5. Web Container:
Tomcat (v6.x)
6. BPEL engine:
Open BPEL (from Sun)
7. ESB:
Apache ServiceMix (v3.2.1)
8. Workflow:
Kuali Enterprise Workflow
Technical Architecture Phase 1 deliverables
3/7/2016
5
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
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 decision-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 interoperable set of
Web 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, implementations 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.
Technical Architecture Phase 1 deliverables
3/7/2016
6
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
2
2.1
Standards
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 underneath doesn’t incorporate any proprietary functionality.
As stated in the Kuali Student guiding principles, we want this ability to ‘plug in’ and ‘plug out’
infrastructure pieces (component abstraction) for all infrastructure components. Kuali Student 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 Phase 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 estimate 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. They are all mature
standards developed and supported by W3C. Kuali Student’s Web Services 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 WSTransaction (WS-TX).
In J2EE, transactional contexts and security contexts are managed by the container. In Web
services the transactional context and the security context can span across multiple services
deployed on different machines and the contexts are themselves managed by Web 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 Webservices a viable platform for SOA (SOAP 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 does not support WS-Transaction. Metro appears to support both (and
Technical Architecture Phase 1 deliverables
3/7/2016
7
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
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, the implementation of security across Web services will be one of the projects of
Phase II of the Kuali Student Technical Architecture project. Kuali Student recognizes that
the lack of a working implementation of WS-Transaction is a serious problem and our strategy
for dealing with it is outlined in Section 11.
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 Student
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 standards 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 Services
engine field to Sun Metro and CXF and the the XML-Java Binding Framework to Sun’s JAXB
reference implementation. Axis 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 ESB’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 spelled
out in detail in Phase 2.
2.4.3 Rules engine: JSR 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 286
The applicability of this standard falls within the scope of the Phase 2 User Interface project.
Technical Architecture Phase 1 deliverables
3/7/2016
8
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
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 compliance
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 Phase 2 User Interface project. In Phase 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 Phase 2 will reveal
whether this assumption is justified). There are three compelling reasons for this initial choice:
widespread adoption of uPortal in the higher education community; an obvious community of
interest between uPortal and Kuali Student; and standards compliance.
3.2
Selection Criteria and Evaluation
3.2.1 Widespread adoption
uPortal has seen wide acceptance and deployment 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, uPortal is used throughout
France as a standard portal for institutions of higher education (see http://www.esupportail.org/communaute/). This is also evidence that uPortal successfully supports
internationalization.
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 able 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
developers
4. The uPortal community has an active set of contributors addressing internationalization
issues, in both Europe and Asia
Technical Architecture Phase 1 deliverables
3/7/2016
9
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
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.
Technical Architecture Phase 1 deliverables
3/7/2016
10
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
4 The database
Selection: Apache Derby
Contenders
o Derby
o MySQL
Primary reasons for selection
o Pure Java
o Embeddable
o Performance containers
4.1
Comments on Selection
Database 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 with our "Test Drive" version. Following is a list of requirements and how Derby and
MySQL each fit with the requirements.
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 runtime 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 phase
A key requirement is bundled 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 redistribution
o MySQL
o Requires installation
o License allows for redistribution
Technical Architecture Phase 1 deliverables
3/7/2016
11
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
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.
Technical Architecture Phase 1 deliverables
3/7/2016
12
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
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 implementation 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
Comments 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 performance metrics indicate, fast.
Tomcat is not a complete J2EE application server like Glassfish. However, many of the J2EE
features that Glassfish provides, such as a web service engine (Metro) and a JMS queue, can
be added onto Tomcat.
Technical Architecture Phase 1 deliverables
3/7/2016
13
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
6 XML-Java binding
Selection: 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 compatible 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
Comments on Selection
XML binding simply refers to converting Java data structures to XML, 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 (see the Web Service Engine
summary for more information 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 postprocess 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 Phase 1 of Kuali Student indicate that this is not the
case:
Technical Architecture Phase 1 deliverables
3/7/2016
14
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
1. The performance metrics of various frameworks 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 thereby minimizing the amount of latency due to traffic
Technical Architecture Phase 1 deliverables
3/7/2016
15
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
7 Web-service engines
Selection: CXF, Metro
Contenders
o Axis 2
o CXF
o Metro
Primary reasons for selection
o At 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 reliably 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 allow 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 WSTransaction. The technical teams determined that WS-AtomicTransaction will be required as an
integral piece of the Kuali Student stack. Unfortunately, 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 system 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 defer 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.
Technical Architecture Phase 1 deliverables
3/7/2016
16
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
8 Rules engines
Selection: Drools (JBoss/Redhat)
Contenders
o Drools
o SweetRules
o OpenRules
Primary reasons for selection
o Licensing
o IDE integration
o XML support
o domain-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 encumbered 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
support, as well as "mindshare" and "half-life" considerations.
Happily and serendipitously, triage and evaluation efforts arrived at the same
conclusion/selection for "declarative rule engine" -- drools from JBoss/Redhat. Major positive
features include:
o Robust plug-in for the eclipse IDE
o Multiple authoring modes.
o Java-friendly
o xml
o decision-table in excel
o graphical rule-flow editor
o guided wizard-style
o Rudimentary repository support 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.
Technical Architecture Phase 1 deliverables
3/7/2016
17
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Subsequent research and discussions at the November FSU workshop has led to thinking about
"Enterprise Decision Management" -- a rules engine is one (albeit major) piece 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. We call these capabilities the Business Rules Management System (BRMS). The
core of the BRMS is a database that:
1. Contains 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 Academic 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 Configuration 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
Technical Architecture Phase 1 deliverables
3/7/2016
18
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
8.4
Figure 1 – KS BRMS
Technical Architecture Phase 1 deliverables
3/7/2016
19
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
9 BPEL
Selection: Sun OpenESB BPEL
Contenders
o Apache ODE
o Sun OpenESB BPEL
o JBoss
Primary reasons for selection
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).
9.1
Selection Criteria and Evaluation
The two engines evaluated were Apache ODE and Sun OpenESB BPEL, with the Sun engine
selected as our choice. We also looked at JBoss, 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 BPEL tags and features a fully functional graphical editor and
test environment bundled with NetBeans. 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 not 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 transactions, 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 impossible 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.
Technical Architecture Phase 1 deliverables
3/7/2016
20
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
While both engines have similar support for the BPEL specification, we feel the variable
initialization issue with Apache ODE outweighs the limited deployment 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 environment 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
while 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.openesb.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 rather 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 provided 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 entry,
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).
Technical Architecture Phase 1 deliverables
3/7/2016
21
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
10 ESB
Selection: Apache ServiceMix
Contenders
o Apache ServiceMix
o Sun OpenESB
o Apache Synapse
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 hard 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 base. 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
Our 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 evaluations 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 evaluated. 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
Technical Architecture Phase 1 deliverables
3/7/2016
22
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
configuration options and features. The benchmark 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 services 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 transformation. 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 Synapse 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 Products
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 Web service engine when
deployed to one specific J2EE container.
Technical Architecture Phase 1 deliverables
3/7/2016
23
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
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
Web 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 find 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 direction taken by
the Identity Team in Phase 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 The Mellon Foundation-sponsored ESB exploratory committee
also selected Apache ServiceMix 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.
Technical Architecture Phase 1 deliverables
3/7/2016
24
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
11 Transactions
Selection: NONE 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 span multiple web services 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 Met our general selection 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
suite and the KS technical team was unable to get it to work with Tomcat.
11.2 Issues
11.2.1 Mitigation
We did define a strategy and a set of options to ensure that we arrive at a solution. 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
solution for Axis 1.0, but the WS-AT project for Axis 2 does not seem to be moving
forward. For some reason the CXF community do not appear to have WS-AT on their
roadmap. However, the community is continually changing, and what is true today
(December 2007) may not be true in six months time.
Technical Architecture Phase 1 deliverables
3/7/2016
25
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
11.2.2 Next Steps
1. We will designate one technical team 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 choose between options 1, 2 and 3. The
implementation becomes part of the Phase 3 Technical Architecture project.
Technical Architecture Phase 1 deliverables
3/7/2016
26
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
12 Workflow
The Kuali Student technical team is recommending that Kuali Enterprise Workflow be used as
the workflow engine for Kuali Student. KEW 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 mature 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 dimensions
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-Security
3. Interface definitions must be optimized for remote access.
There are a range of possible outcomes:
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 identity 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)
Technical Architecture Phase 1 deliverables
3/7/2016
27
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
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 to 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.
Technical Architecture Phase 1 deliverables
3/7/2016
28
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
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 around 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 infrastructure?
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 progress 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, others 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 consists 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.
Technical Architecture Phase 1 deliverables
3/7/2016
29
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Figure 1 - Kuali Student running on two different vendor stacks
a) the Sun Web service stack
b) the IBM Web service stack
Figure 2 shows how the 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. Components in yellow have been “certified”
2. Components in blue are expected to work because of standards compliance
Figure 2
A Kuali Student reference implementation
Technical Architecture Phase 1 deliverables
3/7/2016
30
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
13.2 What are the main drivers behind the concept of swappable infrastructure?
The drivers can be categorized 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 partner 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.
These drivers will vary for different layers of the 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 expertise 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 so 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
implementation. 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.
Technical Architecture Phase 1 deliverables
3/7/2016
31
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
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 ANSI 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 physical 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 JAX-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
swappable because, for example, Sun’s Integrated Development Environment (IDE) is
required to port projects from Apache ServiceMix. That said, if Sun’s OpenESB can be
configured outside the IDE, swappability will be achievable.
Technical Architecture Phase 1 deliverables
3/7/2016
32
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
There are two categories of ESB configuration that directly affect swappability:
1. Simple Message Registry/Relay – Messages are sent to the ESB over HTTP and then
resent to the destination (and back).
a. Pros – Should be completely swappable
b. Cons – More traffic and less features; need to configure services to know the
URL of the ESB; must configure ESB with URLs of the services.
2. Embedded Web Service Engine – This allows in-JVM (Java Virtual Machine) transport.
a. Pros - Obviates the need to configure URLs between services and the ESB.
b. Cons – Not completely swappable, but can easily be removed.
Ramifications of using a bus
1. Using an ESB requires configuration of the ESB’s URL and loses in-JVM capability.
2. The ESB must be configured to know where the off-bus services are located.
3. Packaging and distribution of the system has a few more steps with the introduction
of an ESB.
4. Adding an ESB after the system is built possibly will require ripping out hard-coded
URLs in services (or changing configuration).
The decisions on whether to use an ESB, and if so, whether to configure it using Simple
Message Registry/Relay (highly swappable) or Embedded Web Service Engine (less
swappable) will be determined in Phase 2. The extent to which the ESB is fully swappable
will be understood at the end of Phase2.
13.3.6 Workflow
The lack of clear and widely adopted standards around workflow means that the workflow
component is not swappable. If an implementer wanted to use a different workflow engine,
they would have to re-write all the calls to the workflow engine (assuming they could be
mapped) and they would have to re-write all the routing rules.
13.3.7 Rules engine
In order to swap rules engine technology, an implementer would need to:
1. Choose one that is JSR-94 compliant (or write a wrapper to make it compliant – a
relatively trivial task). JSR-94 defines only the interface for starting and running a rules
engine, not the syntax of the rules.
2. Convert the rules from one syntax to another – a very serious task
3. Adapt the BRMS (Business Rules Management System) to the new rules engine – a
moderate task
The complexity of these tasks will be known by the end of phase 2.
UBC will need to try the first and second task when its existing rules base is converted from
QuickRules to Drools. These conversion routines will then become a community asset
allowing customers to switch between QuickRules/SAP and KS-Drools.
Technical Architecture Phase 1 deliverables
3/7/2016
33
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
13.4 Where does responsibility lie for testing assumptions about swappable
infrastructure?
13.4.1 Database
The Kuali Student development team will be responsible for ensuring:
o Derby compliance through daily builds
o Oracle compliance through weekly builds.
o MySQL compliance through monthly builds.
Note that the timeframes for Oracle and MySQL compliance testing may change as
experience with Kuali Student is gained.
Institutional implementation teams will be able to contribute their scripts and documentation
for implementations on Oracle, MySQL and any other compliant database platform. These
contributions then become community assets.
13.4.2 Operating system
Configuring and testing an OS/hardware stack other than Linux on VMware (the Kuali
Foundation configuration) is the responsibility of implementation teams at the different
institutions. Again, any solutions can be contributed as community assets. Commercial
affiliates may also play a role in configuring and testing OS/hardware stacks (e.g. Sun
Solaris).
13.4.3 Portal
The responsibility for testing different Portal deployments lies with implementation teams at
institutions that are not using uPortal.
13.4.4 Service engine layer
We are looking to commercial affiliates such as IBM and Sun to take on the work of certifying
the Kuali Application on their respective WS* stacks.
Technical Architecture Phase 1 deliverables
3/7/2016
34
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
14 Appendix A Standards
These summary tables express our findings regarding standards. The numbers are are
intended as a rough guide with the following meanings:
Score
1
2
3
Relevance
Irrelevant
Nice to have
Mandatory
Standard
WS-Policy
Adoption
None
Some
Universal
Relevance
3
Adoption
2
WS-Coordination
WS-Atomic
Transactions
WS-Business
Activity
3
3
2
1
2
1
WS-Security
WS-Reliable
Messaging
3
3
2
3
3
3
WS- Notification
WS-Addressing
Standard
JSR-94
Relevance
1
Adoption
2
JSR-222
JSR-224
3
3
2
2
JSR-286
2
2
JSR-208
1
2
JSR-220
3
2
Technical Architecture Phase 1 deliverables
Comments
WS-Policy is a building block of WS-Transaction
and WS-Security. Policy assertions are used to
indicate that a service belongs to a transactional
or security context.
A basic building block of WS-Transaction.
This is fundamental to SOA built on WS*. Only
Sun Glassfish currently has an implementation.
Not implemented anywhere. Most likely, KSS will
have to implement some kind of compensation
strategies not governed by a standard.
A lot of asynchronous notification likely in KS.
This is even truer if an institution is trying to get
rid of batch processing. Well supported by the
web service engines out there.
Needed if not using JMS, e.g., re: interoperability
at that level with .NET app.
Fundamental
Comments
Defines the interface for starting and running a rules
engine. This is not a huge issue as it is rules syntax that
really matters.
Defines the standard for Java-XML binding. Core to KSS.
Defines handlers and interceptors: critical to interoperability
of KSS services.
Nothing of considerable size is written as a portlet . On the
other hand, failure to deliver UI in portlets becomes an
issue for institutions integrating KSS with their own
systems. This a Phase II discussion.
This is a Sun-led spec. IBM and BEA haven’t signed-on.
Bottom line: there is no universally accepted specification
for what a bus is.
JTA (to discuss in Phase II)
3/7/2016
35
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
15 Appendix B Databases
15.1 Database performance statistics
The following images are excerpted from the Sun benchmarks document for Apache Derby
available at: http://wiki.apache.org/apachecon-data/attachments/Us2005OnlineSessionSlides/
attachments/ApacheCon05usDerbyPerformance.pdf .
Technical Architecture Phase 1 deliverables
3/7/2016
36
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
15.2 Product Comparison Matrix
Product site
Product Version
License
Derby
http://db.apache.org/derby/
10.3.1.4
Apache
Is it "Pure Java"
Required Java
Version(s)
Number of
Releases
Backwards
compatibility
Industry support
Yes
1.4.2
Enterprise
Production
examples
Standards
http://wiki.apache.org/dbderby/UsesOfDerby
Version of
Standard
Significant amount of ANSI:1999 and
ANSI:2003 mandatory features are
supported http://wiki.apache.org/dbderby/SQLvsDerbyFeatures
Good
Community
Support
Availability of
build scripts
Dependencies
Eclipse plug-in
available
Documentation
Books available
Ease of
installation
5 official releases in the 10.x series
Good
Development supported by Sun, IBM, and
Apache OSS group
ANSI SQL, DRDA protocol for drivers
Yes
MySQL
http://www.mysql.com/
5
GPL with FLOSS exception
allowing use with Apache
licensed products
No
n/a
5
Some backwards compatibility
issues
While OSS, the MySQL core
is owned and primarily
maintained by MySQL AB
Many large sites such as
http://www.digg.com/ and
http://slashdot.org/
ANSI SQL mode can be
enabled, disabled by default
Level of ANSI support
depends on which engine is
used
Excellent
Yes
Bundled with Java 6
Yes (both generic DB plugins as well as
derby specific)
Good
Yes (mostly covering using Derby with
other products and servers)
Easy (unzip)
Yes (generic DB plugins)
Good
Yes, many
Easy
In addition to our own evaluation, an excellent comparison of open source databases is available
at:
http://www.encorewiki.org/display/encore/Open+Source+Databases+Comparison
Technical Architecture Phase 1 deliverables
3/7/2016
37
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
15.3 Appendix C Servlet engines
Performance results are based on 10,000 requests against servlet containers running on a dual
processor Xeon 2.8 GHz with 2gb of memory. Client was a 2.16 GHz Core Duo with 2gb of
memory, connected via 100mbps Ethernet. The Apache benchmark tool (“ab”) was used to
perform the benchmark. Neither client processor nor network connection capacity were reached
during the tests, while server processor load was near capacity. Results are in transactions per
second, rounded down to the nearest whole number. Higher numbers represent better
performance.
Benchmark scripts are available at:
https://test.kuali.org/confluence/download/attachments/58456/ServletContainerBenchmark.zip
15.4 Servlet Engines Performance
Resource Type
Client
Threads
Tomcat
Jetty
Glassfish
File
File
File
1
10
50
1029
5339
6439
639
569
2654
783
2495
2820
File
100
6142
2784
2805
File
200
5988
2394
2810
Servlet
Servlet
Servlet
Servlet
Servlet
JSP
JSP
1
10
50
100
200
1
10
1102
5211
6978
6925
6944
957
4526
43
513
2796
2906
2796
44
464
804
2783
2871
2938
2418
662
1987
JSP
50
4393
2329
1967
JSP
100
4595
2491
1727
JSP
200
4670
2394
2097
Technical Architecture Phase 1 deliverables
3/7/2016
38
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
15.5 Product Data Matrix
Tomcat
http://tomcat.apache.org
6
Apache
Yes
J2SE 5
Glassfish
https://glassfish.dev.java.net/
2
CDDL and GPL
Yes
J2SE 5
Number of Releases
4 major release(6.X, 5.5.X,
4.1.x, 3.3.x)
4 major release
Backwards
compatibility
Each version is for different
version of JSP and Servlet,
the configuration path has
some changes as well.
JSP, Servlet
for different version of standard
Very good
Yes
Good
servlet 2.5, JSP 2.1
Not as active as Tomcat
Yes
Yes
https://glassfishplugins.dev.
java.net/
High
Yes
http://eclipse-plugins.2y.net/
eclipse/plugin_details.jsp?id=312
High
Fair
Yes
Moderately complicated
(installer must be run, accounts
set up, etc.)
less than 1 minute
Good
Covered in some books
Easy (unzip and run)
Product site
Product Version
License
Is it "Pure Java"
Required Java
Version(s)
Standards
Version of Standard
Community Support
Availability of build
scripts
Eclipse plug-in
available
Eclipse plug-in
maturity/quality
Documentation
Books available
Ease of installation
High
Startup time
around 2 seconds
Good
Yes
Easy (unzip and run)
Technical Architecture Phase 1 deliverables
3/7/2016
JSP, Servlet, JAXB, J2EE
related
Jetty
http://www.mortbay.org/
6.1
Apache
Yes
Java 1.4, 1.5
(http://docs.codehaus.org/ display/
JETTY/Downloading+and+Installing)
11
(http://docs.codehaus.org/display/JETTY
/Downloading+and+Installing)
For different servlet and JSP version
JSP, Servlet
39
less than 2 seconds
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
16 Appendix D XML binding framework
16.1 XML Binding Performance
As the following performance metrics show, Sun’s JAXB reference implementation performs
well in comparison to the other options. This, in addition to its status as a JSR standard, leads
us to opt for JAXB.
Shorter times indicate better performance.
PC used for this benchmark: Microsoft Windows XP Professional Version 2002 Service Pack 2,
Intel Core 2 CPU, 6420 @ 2.13 GHz, 2 G memory, java version "1.6.0_02".
Benchmark scripts are available at:
https://test.kuali.org/confluence/pages/viewpageattachments.action?pageId=58474
Marshall and
Unmarshall
Simple Binding
1,000,000 loops
Marshall and
Unmarshall
Data Structure
1,000,000 loops
Sun’s JAXB reference
implementation
5 Minutes 22 seconds
5 Minutes 38 Seconds
Technical Architecture Phase 1 deliverables
JiBX
6 minutes
1 seconds
7 minutes
27
seconds
3/7/2016
XML
Beans
6 minutes
36 seconds
7 Minutes
15 seconds
Castor
8 Minutes 58 seconds
9 Minutes 4 second
40
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
16.2 Product Data Matrix
Product site
Product Version
License
Is it "Pure Java"
Required Java
Version(s)
Number of Releases
Backwards
compatibility
Number of
developers
Enterprise
Production
examples
Standards
Version of Standard
Community Support
Availability of build
scripts
Dependencies
Sun’s JAXB reference
implementation
https://jaxb.dev.java.net/
2.1.5
CDDL
Yes
1.3 or better, included in
1.6
Good (The current code
base supports JAXB 1.0,
2.0, and 2.1 but the project
will track future versions of
the JAXB specifications.)
Unknown (Sun
supported)
JiBX
Castor
XMLBeans
http://jibx.sourceforge.net/
1.1.5
BSD
Yes
1.3 or better
http://www.castor.org/
1.1.2.1
Apache
Yes
http://xmlbeans.apache.org
2.3.0
Apache
Yes
1.4 or better
4
Good
4
Has been broken in
recent releases
1
4
http://jibx.sourceforge.net/
sponsors.html
Apache Cocoon
Defined as JSR, JAXB
specification
JSR 222
n/a
supports XML
schema, but uses
Castor specific
mapping file
Active
Yes
Active
Yes
Active
Yes
Active
Yes
No
BCEL.jar, stax-api.jar,
wstx-asl.jar, xmlpull.jar,
xpp3.jar
common-log.jar,
xerces-J_1.4.0.jar
xmlpublic.jar, resolver.jar,
jsr173_1.0_api.jar
Technical Architecture Phase 1 deliverables
3/7/2016
13
41
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Eclipse plug-in
available
Eclipse plug-in
maturity/quality
Documentation
Books available
Ease of installation
Is the binding a
standard, or vendor
specific
Data type binding
support
Supports user
defined types
Quality of the stub
Supported by web
service engines
Generates Java
object model from
XML Schema
Generates clean
Java code
Requires bytecode
modification
Generated Java
objects are easy to
manage
Overall ease of use
JAXB
Yes, multiple. (Example:
https://jaxb-workshop.
dev.java.net/plugins/eclip
se/xjc-plugin.html)
Mature, good.
Castor
Yes, but only certified
to work with Eclipse
3.1.x
XMLBeans
Under development
N/A
Mature
Alpha
Good
Covered in Java/XML
books
Easy. If using JDK6, it is
bundled in.
JSR standard
Good
No
Good
Covered in Java/XML
books
Easy
Good
Covered in Java/XML
books
Vendor specific
Vendor specific, but
using XML schema
W3C standard
Full W3C XML Schema
support
Yes
Java types
Java types
XML schema type
Yes
Yes
Yes
High (Marked with
annotation)
JAS-WS
No stub generated, uses
byte code manipulation
Axis2, XFire
High
Low
Yes
No
Yes
Yes
Yes
n/a (no code generated)
Yes
No
No
Yes
No
No
Yes
N/A (no code generated)
Yes
Easy
Easy
Easy
Somewhat (the generated
source files are stored in a
jar file)
Easy
Technical Architecture Phase 1 deliverables
3/7/2016
JiBX
No
Easy
Axis2
42
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
17 Appendix E Web service engines
17.1 Engine Performance
These benchmarks represent different usages of CXF and Metro with Tomcat and the ServiceMix bus. Apache Axis2 benchmarks
are published in the wiki, but are excluded due to lack of JAX-WS support as previously mentioned.
Performance results are based on 10,000 requests against servlet containers running on a dual processor Xeon 2.8ghz with 2gb of
memory. Benchmark was performed using Apache JMeter.
.
Tomcat/CXF
ServiceMix>Tomcat/CXF
Synapse>Tomcat/CXF
OpenESB>Tomcat/CXF
Tomcat/KSB
ServiceMix>Smix/CXF
Tomcat/Metro
Tomcat/CXF>Tomcat/CXF
2ms av.
( 237/ sec)
1ms av.
(333/ sec)
1ms av.
( 335 / sec )
1ms av.
( 338 / sec )
40ms av.
(24/sec)
41ms av.
( 23 / sec )
41ms av.
( 23 / sec )
41ms av
. ( 23 / sec )
4ms av.
( 158 / sec )
4ms av.
( 174 / sec )
4ms av.
( 166 / sec )
12ms av.
( 71 / sec )
3ms av.
( 188 / sec )
2ms av.
( 238 / sec )
2ms av.
( 240 / sec )
2ms av.
( 239 / sec )
4ms av.
(152/ sec)
3ms av.
(199/ sec)
4ms av.
(188/ sec)
11ms av.
(75/ sec)
3ms av.
( 170 / sec)
20ms av.
( 47 / sec)
20ms av.
( 47 / sec)
20ms av.
( 46 / sec)
3ms av.
(202/ sec)
1ms av.
(321/ sec)
1ms av.
(327/ sec)
1ms av.
(333/ sec)
3ms av.
( 178 / sec )
2ms av.
( 253 / sec )
2ms av.
( 251 / sec )
2ms av.
( 257 / sec )
4ms av.
( 511 / sec )
3ms av.
( 535 / sec )
3ms av.
( 540 / sec )
3ms av.
( 538 / sec )
38ms av.
( 212 / sec )
37ms av.
( 222 / sec )
38ms av.
( 219 / sec )
42ms av.
( 205 / sec )
14ms av.
( 207 / sec )
13ms av.
( 127 / sec )
14ms av.
( 194 / sec )
54ms av.
( 109 / sec )
12ms av.
( 399 / sec )
12ms av.
( 409 / sec )
15ms av.
( 372 / sec )
12ms av.
( 410 / sec )
11ms av.
(357/ sec)
12ms av.
(350/ sec)
14ms av.
(327/ sec)
60ms av.
(139/ sec)
20ms av.
(373 /sec)
17ms av.
(407/ sec)
18ms av.
(404/ sec)
18ms av.
(398/ sec)
5ms av.
(475/ sec)
4ms av.
(522/ sec)
4ms av.
(522/ sec)
4ms av.
(524/ sec)
8ms av.
( 397 / sec )
8ms av.
( 422 / sec )
8ms av.
( 422 / sec )
8ms av.
( 421 / sec )
6ms av.
( 514 / sec )
3ms av.
( 521 / sec )
3ms av.
( 522 / sec )
48ms av.
( 316 / sec )
46ms av.
( 319 / sec )
48ms av.
( 313 / sec )
25ms av.
( 222 / sec )
32ms av.
( 179/ sec )
43ms av.
( 171 / sec )
13ms av.
( 410 / sec )
16ms av.
( 405 / sec )
17ms av.
( 406 / sec )
10ms av.
(375/ sec)
16ms av.
(339 /sec)
15ms av.
(324/ sec)
28ms av.
(419/ sec)
25ms av.
(426/ sec)
28ms av.
(421/ sec)
4ms av.
(511/ sec)
4ms av.
(508/ sec)
4ms av.
(510/ sec)
3ms av.
( 520 / sec )
82ms av.
( 222 / sec )
294ms av.
( 104 / sec )
16ms av.
( 406 / sec )
298ms av.
(125/ sec)
25ms av.
(414/ sec)
4ms av.
(510/ sec)
10ms av.
( 413 / sec )
8ms av.
( 418 / sec )
9ms av.
( 417 / sec )
8ms av.
( 418 / sec )
1 Thread
getCount
getPerson
getPeople 10
getPeople 100
10 Threads
getCount
getPerson
getPeople 10
getPeople 100
50 Threads
getCount
getPerson
getPeople 10
getPeople 100
Technical Architecture Phase 1 deliverables
3/7/2016
43
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Tomcat/CXF
ServiceMix>Tomcat/CXF
Synapse>Tomcat/CXF
OpenESB>Tomcat/CXF
Tomcat/KSB
ServiceMix>Smix/CXF
Tomcat/Metro
Tomcat/CXF>Tomcat/CXF
4ms av.
( 506 / sec )
4ms av.
( 507 / sec )
4ms av.
( 503 / sec )
5ms av.
( 505 / sec )
45ms av.
( 324 / sec )
47ms av.
( 317 / sec )
57ms av.
( 304 / sec )
84ms av.
( 216 / sec )
39ms av.
( 168 / sec )
48ms av.
( 176 / sec )
47ms av.
( 172 / sec )
536ms av.
( 99 / sec )
15ms av.
( 403 / sec )
15ms av.
( 400 / sec )
16ms av.
( 399 / sec )
16ms av.
( 398 / sec )
10ms av.
(373/ sec)
13ms av.
(341/ sec)
15ms av.
(320/ sec)
600ms av.
(120/ sec)
28ms av.
(425/ sec)
40ms av.
(411/ sec)
25ms av.
(424/ sec)
25ms av.
(412/ sec)
7ms av.
(500/ sec)
4ms av.
(502/ sec)
4ms av.
(501/ sec)
4ms av.
(494/ sec)
19ms av.
( 402 / sec )
13ms av.
( 407 / sec )
11ms av.
( 413 / sec )
10ms av.
( 412 / sec )
4ms av.
( 475 / sec )
24ms av.
( 466 / sec )
7ms av.
( 470 / sec )
8ms av.
( 474 / sec )
46ms av.
( 318 / sec )
48ms av.
( 302 / sec )
50ms av.
( 297 / sec )
85ms av.
( 214 / sec )
58ms av.
( 188 / sec )
73ms av.
( 156 / sec )
91ms av.
( 158 / sec )
(incomplete)
66ms av.
( 378 / sec )
15ms av.
( 387 / sec )
16ms av.
( 381 / sec )
15ms av.
( 378 / sec )
10ms av.
(362/ sec)
13ms av.
(331/ sec)
15ms av.
(311/ sec)
728ms av.
(125/ sec)
25ms av.
(411/ sec)
27ms av.
(401/ sec)
58ms av.
(398/ sec)
25ms av.
(405/ sec)
4ms av.
(227/ sec)
4ms av.
(485/ sec)
4ms av.
(475/ sec)
23ms av.
(471/sec)
30ms av.
( 397 / sec )
11ms av.
( 403 / sec )
11ms av.
( 392 / sec )
10ms av.
( 398 / sec )
100 Threads
getCount
getPerson
getPeople 10
getPeople 100
200 Threads
getCount
getPerson
getPeople 10
getPeople 100
Technical Architecture Phase 1 deliverables
3/7/2016
44
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
17.2 Product comparison matrix
Axis 2
CXF
Product site
Product Version
License
http://ws.apache.org/axis2/
1.3
Apache License, Version 2.0
http://incubator.apache.org/cxf/
2.0.3
Apache License
Is it "Pure Java"
Required Java Version(s)
Yes
1.4 or later
Yes
1.5 or later
Number of Releases
8 (Version
1.3/1.2/1.1.1/1.1/1.0/0.95/0.94/0.93
)
Not compatible with Axis 1.x
3 releases in the 2.0.x series
Backwards compatibility
Enterprise Production
examples
Community Support
Availability of build scripts
Eclipse plug-in available
Eclipse plug-in
maturity/quality
Documentation
Books available
Ease of installation
Standards
Data Bindings
Metro
https://metro.dev.java.net/
1.0
Dual license of CDDL and GPLv2
with classpath exception.
Yes
1.5 or later
2 releases in the 1.x series, 2
upcoming releases
Not compatible with XFire
Active
Yes
Active
Yes
GlassFish V2 and Sun Java
System Application Server 9.1
Active
Yes
Yes
(http://ws.apache.org/axis2/tools/in
dex.html), also Eclipse WST
support
Good
Eclipse WST support
Eclipse WST support
Fair
Fair
Inadequate
No
Easy
JSR 181, SOAP 1.1, 1.2, WSDL
1.1, 2.0
ADB, XMLBeans, Jibx, JAXB 1.0
Inadequate
No
Easy
JAX-WS, JSR-181, SOAP 1.2,
WSDL 2.0
JAXB currently, version 2.1 will
support XMLBeans, Castor, and
JiBX as well
Inadequate
No
Easy
JAX-WS 2.0, 2.1RI, JSR 181,
SOAP 1.1, 1.2, WSDL 1.1
JAXB
Technical Architecture Phase 1 deliverables
3/7/2016
45
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Axis 2
CXF
Spring Support
WS-Addressing
Yes
Yes
Yes
Yes
WS-Atomic Transaction
No (The Kandula 2 project which is
meant to support WS-Transaction
on Axis2 has stalled)
No
No
No
No
WS-Business Activity
WS-Coordination
WS-Eventing
WS-Metadata Exchange
WS-Notification
WS-ReliableMessaging
No
Yes
Yes
Yes, seen in SOAP message,
routing not tested
Yes
No
No
No
No
Yes (via ServiceMix)
Yes
WS-Policy
WS-Secure Conversation
WS-Security Policy
WS-Security
Yes
Yes
Yes
Yes
Yes
To be released in 2.1
WS-Trust
Overall ease of use
Yes
Easy
To be released in 2.1
Easy
Technical Architecture Phase 1 deliverables
Partial, based on WSS4J
3/7/2016
Metro
46
No
Yes
No
Yes, Not tested
No
Yes, Partially - killing TCP
connection does not deliver
message
Yes, seen in WSDL
Yes, Not tested
Yes, seen in WSDL and tested
Yes, Tested Encryption and
Signature, not Security Tokens
Yes, Not tested
Easy
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
18 Appendix F Rules engines
18.1 Product comparison matrix
Product
Drools 4.0 (JBoss Rules)
SweetRules 2.1
OpenRules 3.0
Rule Engine
JBoss
4
30-Aug-07
Rule Engine
Rule Engine
OpenRules, Inc.
3
September 18,2006
Product Space
Company
Product Version:
Release Date
URL
http://labs.jboss.com/drools/ License
Apache License, Version 2.0
Supported JVM
Number of Release:
Backwards compatibility:
Number of developers:
Number of Downloads:
2.1 Alpha release
25-Apr-05
http://sweetrules.projects.semwebc
entral.org SweetRules=LGPL, IBM
CommonRules has it's own license
which does not allow it in production
systems
JDK 1.4 and up
4
No
13
13,000 downloads for the month of
August, 2007
2
Product
JSR-94
Strong community support via IRC
or mailing lists
No
Yes
drools-core.jar, drools-compiler.jar,
drools-jsr94.jar, droolsdecisiontables.jar
Drools 4.0 (JBoss Rules)
Eclipse plug-in available:
Technical Architecture Phase 1 deliverables
JDK 1.4 and up
4
Yes
Big Faceless Organizations (BFO)
Availability of build scripts:
Dependencies:
GPL
5
Hundreds of downloads in total
Enterprise Production
examples:
Standards:
Version of Standard:
Community Support:
http://openrules.com IBM CommonRules 3.3, JWSDP
1.5, DOM4J 1.5, Log4j 1.2.8, Xalan
2.6.0, Junit 3.8.1
SweetRules 2.1
Yes
3/7/2016
Yes
OpenRules 3.0
Yes
47
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Documentation:
Books available:
Ease of installation:
Tomcat 6/Axis2 1.3 Integration
Pretty good documentation of all
features
Easy (configuration of a production
system is more involved)
Available, but very minimal
Difficult - Must download and install
third party software during the
installation
Difficult - Drools doesn't work with
Tomcat/Axis2 due to class loader
issues. Can somehow be fixed by
creating a new class loader for the
Drools compiler.
No
Very Easy
Tomcat 5.5/Axis2 (should work for
Tomcat 6)
Jetty/Axis2 1.3 Integration
Can be configured for Axis2
Supports linear rule
stereotype?
Yes
Yes, have to write Java functions
in Excel for this
Supports decision table rule
stereotype?
Yes
Yes
Yes, through its rule flow
Yes, but no editor of any kind and
is tricky
Supports flowchart stereotype
(optional)?
Procedural or Rete? If Rete,
does the product support
backward as well as forward
chaining?
Support for natural language
rule composition?
Ability to translate rules into
natural language?
Rete - Forward Chaining only
(backward chaining expected in the
next release)
Supports backward and forward
chaining
Yes
Limited and only in version 4.0
No
No
Yes
Yes
Rules repository
(file/database)?
File system and database (through
JDBC)
Excel files (in 4.0 they can be
stored as clob in DB)
User interface for rule
definition
Eclipse 3.2 - JBoss Rules
Workbench and rules management
(BRMS) web application
Excel files
Supports JSR-94
Product
Technical Architecture Phase 1 deliverables
Drools 4.0 (JBoss Rules)
3/7/2016
SweetRules 2.1
48
OpenRules 3.0
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
IDE support for technical staff
Eclipse 3.2 - JBoss Rules
Workbench, WYSIWYG support for
rules, rule-flows and debugging
Yes, powerful IDE debugger
Rule Debugger
Rule Management System
No. Has a rule tester that non
techies can also use
Yes, web based rule management
(BRMS)
Are rules compiled or
interpreted?
RuleML support
(conversion/translation)
Eclipse plugin but rules are edited
using Excel
Rules are compiled into Java
classes
Interpreted
No but there is a JBoss project in
the works to import/export to ruleML
Yes
No - Maybe in a future release
Rules can directly trigger WSDL
Web Services as actions.
External dependencies?
Web Service Support?
Multi threaded rule execution?
No
None
Yes
Thread safe
No
Demos
http://labs.jboss.com/drools/livetrails
/index.html Open Rules 3.0 HOWTO Setup Other
Notes
Hibernate integration
Business Rules Management
System (BRMS) uses Apache
Jackrabbit which supports JSR-170
Content Repository API
Technical Architecture Phase 1 deliverables
3/7/2016
SweetRules is a pluggable set of
rules tools for RuleML and SWRL
featuring: interoperability between
Prolog, production rules, OWL,
CommonRules, Jena-2, and several
other languages; and inferencing
with negation, priorities, and
procedural attachments.
49
Pros and Cons Kuali Student Service System
Technical Architecture Phase 1 Recommendations
18.2 Rules Engine Performance
18.2.1 Setup
All performance tests below use the following unless otherwise specified:
1) Java 1.6.0_02
2) JVM Arguments: -Xmx1024m -Xms1024m -XX:PermSize=64m XX:MaxPermSize=256m (Haven't tried -XX:+UseParallelGC or any other optimizations)
3) Hardware: P4 3.0GHz - 2GB RAM
4) Microsoft Windows XP Professional, Version 2002, Service Pack 2
5) Drools 4.0.1
6) Eclipse 3.2
All unit tests use a simple Address object as fact.
All rules are of the form:
Address Rule
package org.kuali.student.address
import java.util.List;
import org.kuali.student.address.schema.address.Address;
rule "AddressToCheck"
salience 50
no-loop true
when
address : Address()
eval( address.getAddressTo() == null ||
address.getAddressTo().trim().length() == 0 )
then
address.addError( "AddressTo is empty" );
end
18.2.2 Test Searching Through an ArrayList
This test searches through an ArrayList of Address Objects and records the time.
JVM Settings: -Xmx1256m -Xms1256m -XX:PermSize=64m -XX:MaxPermSize=256m
Rules:
1.
2.
3.
4.
5.
Get all Address objects where city = 'Seattle' and set region to 'USA West'
Get an ArrayList of Address objects where Address object's city = 'Seattle'
Find maximum id in the collection of Address objects where city = 'Seattle'
Calculate hash code of all Address objects in the collection
Function to calculate hash code
Technical Architecture Phase 1 deliverables
3/7/2016
50
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
18.2.3 Stateless vs. Stateful Session
Objects
10
100
1000
5000
10000
50000
100000
200000
300000
400000
500000
1000000
Objects
10
100
1000
10000
50000
100000
200000
300000
400000
500000
1000000
Stateless
Time
0.070 sec
0.020 sec
0.080 sec
0.150 sec
0.221 sec
1.192 sec
2.434 sec
5.179 sec
8.355 sec
10.93 sec
13.836 sec
28.963 sec
Stateful
Time
0.010 sec
0.010 sec
0.050 sec
0.942 sec
28.635 sec
2 min 39 sec
9 min 12 sec
18 min 44 sec
32 min 43 sec
51 min 33 sec
Incomplete
Errors
Errors
Out of
memory
Technical Architecture Phase 1 deliverables
3/7/2016
51
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
18.2.4 Test Number of Session Invocations
New Stateless Session per Iteration: This load test creates a new stateless session for each
iteration. No threads are involved here.
New Stateful Session per Iteration: This load test creates a new stateful session for each
iteration. No threads are involved here.
New Stateless Session per Iteration
Sessions
Execution
Invoked
Time
10
0.111 sec
100
0.901 sec
1000
8.8 sec
2500
23.2 sec
5000
49.1 sec
7500
1 min 10 sec
10000
1 min 37 sec
Stateful vs. Stateless Session per Iteration
New Stateful Session per Iteration
Sessions
Execution Time
Invoked
10
0.231 sec
100
0.100 sec
1000
801 sec
2500
2.1 sec
5000
10.6 sec
7500
33.3 sec
10000
1 min 13 sec
Technical Architecture Phase 1 deliverables
3/7/2016
52
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
18.2.5 Test Number of Rule Package Invocations for One Session
One Stateless Session for All Iterations: This test creates one stateless session and
executes up to 10000 rules sequentially on the session.
Rule Packages Invoked
10
100
1000
2500
5000
7500
10000
Execution Time
0.100 sec
0.881 sec
8.8 sec
23.6 sec
49.5 sec
1 min 13 sec
1 min 36 sec
One Stateful Session for All Iterations: This test creates one stateful session and executes
up to 100000 rules sequentially on the session.
Rule Packages Invoked
10
100
1000
5000
10000
20000
30000
40000
50000
60000
70000
80000
90000
100000
Execution Time
0.020 sec
0.010 sec
0.110 sec
0.341 sec
0.761 sec
1.2 sec
1.7 sec
2.3 sec
2.8 sec
3.4 sec
4.0 sec
4.5 sec
5.0 sec
5.7 sec
Technical Architecture Phase 1 deliverables
3/7/2016
53
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Stateful vs. Stateless Session for All Iterations
Technical Architecture Phase 1 deliverables
3/7/2016
54
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
18.2.6 Test Stateful Sessions in Parallel Threads
One Stateful Session per Thread: This test creates one stateful session for each thread to
execute rules on.
Threads
10
100
1000
5000
10000
50000
Execution Time
0.110 sec
0.200 sec
1 sec
8 sec
42 sec
11 min 51 sec
One Stateful Session for all Threads: This test creates one stateful session for all threads to
use and each thread then executes rules on that session. This test also checks concurrency
and that stateful sessions are thread-safe.
Threads
10
100
1000
5000
10000
50000
100000
200000
300000
400000
500000
Execution Time
0.060 sec
0.060 sec
0.281 sec
1 sec
2 sec
13 sec
28 sec
56 sec
1 min 35 sec
2 min 8 sec
2 min 52 sec
Technical Architecture Phase 1 deliverables
3/7/2016
55
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
18.2.7 Test Stateless Session in Parallel Threads
One Stateless Session per Thread: This test creates one stateless session for each thread to
execute rules on.
Threads
10
100
1000
5000
10000
50000
100000
Execution Time
0.120 sec
0.140 sec
1 sec
6 sec
21 sec
4 min 14 sec
9 min 41 sec
One Stateless Session for All Thread: This test creates one stateless session for all threads
to use and each thread then executes rules on that session. This test also checks concurrency
and that Stateless sessions are thread-safe.
Threads
10
100
1000
5000
10000
50000
100000
Execution Time
0.130 sec
0.180 sec
1 sec
6 sec
23 sec
4 min 23 sec
9 min 50 sec
Technical Architecture Phase 1 deliverables
3/7/2016
56
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
18.2.8 Test Rule Package Execution Time
Test the time it takes to execute 10, 100, 1000, etc. number of rules in a package.
Stateless Session
Rules
10
100
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
15000
20000
30000
40000
50000
Execution Time
0.10 sec
0.20 sec
0.141 sec
0.261 sec
0.401 sec
0.542 sec
0.692 sec
0.864 sec
1.1 sec
1.2 sec
1.6 sec
1.5 sec
2.6 sec
3.4 sec
5.6 sec
10.1 sec
13.3 sec
Errors
Stateful Session
Rules
10
100
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
15000
20000
30000
40000
50000
Execution Time
0.091 sec
0.0030 sec
0.201 sec
0.341 sec
0.431 sec
0.532 sec
0.683 sec
0.823 sec
1.0 sec
1.2 sec
1.6 sec
1.5 sec
2.3 sec
3.2 sec
6.9 sec
10.1 sec
13.9 sec
Technical Architecture Phase 1 deliverables
Errors
3/7/2016
57
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
18.2.9 Test Rule Package Compilation Time
Test how long it takes to compile 10, 100, 1000... number of rules.
Rules
10
100
500
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
15000
20000
30000
40000
50000
Time
0.321 sec
1 sec
3 sec
7 sec
11 sec
17 sec
24 sec
32 sec
47 sec
58 sec
1 min 15 sec
1 min 36 sec
1 min 54 sec
2 min 36 sec
3 min 48 sec
7 min 3 sec
12 min 33 sec
17 min 30 sec
Errors
18.2.10
Test Rule Package Memory Usage
Test approximately how much memory a org.drools.RuleBase uses for 10, 100, 1000...
number of rules.
Rules
Memory
Errors
10
91 KB
100
573 KB
1000
8.8 MB
2000
16.6 MB
3000
22.0 MB
4000
20.2 MB
5000
27.3 MB
6000
37.7 MB
7000
43.0 MB
8000
38.9 MB
9000
47.3 MB
10000
52.5 MB
15000
84.9 MB
20000
107.4 MB
30000
154.2 MB
40000
204.4 MB
50000
268.6 MB
Note: Total memory on Windows for the Javaw.exe process compiling 50000 rules was about
1.2 GB.
Technical Architecture Phase 1 deliverables
3/7/2016
58
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
18.2.11
Test Rule Package Serialization and Deserialization
Java Arguments: -Xmx1024m-Xms1024m-Xss2048k-XX:PermSize=64m-XX:MaxPermSize=256m
Note: Must set the JVM arguments -Xss2048k to avoid java.lang.StackOverflowError errors early on.
Apparently, on Linux you don't get java.lang.StackOverflowError errors or you may get them very late in
the test (over 10000 or 20000 rules).
Serializing Rules (Java Serialization): Test serialization of a org.drools.RuleBase
Rules
Time
Errors
10
0.131 sec
100
0.150 sec
1000
0.993 sec
2000
2.6 sec
3000
5.7 sec
4000
14.0 sec
5000
25.9 sec
6000
StackOverflowError
Deserializing Rule (Java Deserialization); Test deserialization of a org.drools.RuleBase
Rules
10
100
1000
2000
3000
4000
5000
Time
0.161 sec
0.853 sec
9.2 sec
19.3 sec
30.5 sec
48.4 sec
Errors
StackOverflowError
Technical Architecture Phase 1 deliverables
3/7/2016
59
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
19 Appendix G BPEL engines
19.1 BPEL Tests
Tags Tested
Service
EchoService2
CallEchoService2
CorrelationService2
Polymorph
ArrayBPEL
<receive>
<assign>
<reply>
<invoke>
<correlationSets>
<correlationSet>
<correlations>
<correlation>
<if>
<else>
<condition>
<forEach>
<startCounterValue>
<finalCounterValue>
<scope>
<copy>
Technical Architecture Phase 1 deliverables
3/7/2016
Description
Compatibility Issues
Simple BPEL that accepts a message
containing a string and returns a
message containing the input string
prefixed with the BPEL engine name.
ODE does not initialize the XML
skeleton of messages or variables.
This appears to not follow the BPEL
spec.
This BPEL demonstrates invoking
another service (the EchoService2
example).
There were no issues with regards to
invoking other services.
This tests creating and rejoining a
"long running" process. RPC/Lit that
accepts message with first name, uses There were no issues with regards to
a message part to correlate second
correlation.
message with last name and returns
first + last name from second call.
This tests schema with types that
inherit from a base type. Takes a
contact type, casts it to an email,
checks to see if it really is an email (by
testing for the email element), then
assigns the type element to "email" if
it's email, or "other" if not.
This did not work for either engine
when using <extension base="">.
The engines did not correctly
interpret the xsi:type="email" in the
xml messages.
This tests creating a message
containing a node list with a variable
number of elements. Takes a count n
and an email and returns a list of n
emails with unique ids.
ODE can not append nodes in a
standard way. forEach does not
work in ODE. Sun worked by using
the element[$n] xpath notation.
60
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Tags Tested
Service (Con’t)
ConcurrentActivity
AsynchronousExample
fault1
<forEach parallel="yes">
Compatibility Issues
This tests parallel processing using a
dynamic number of threads (this also
provides method-like functionality in
BPEL, without it the number of threads
will have to be hard coded and the
steps in each parallel activity must be
copy and pasted). Takes a list of
addresses and inserts them in 'parallel'
sequence into database.
NetBeans does not support 'parallel'
attribute set to 'yes'. ODE
documentation claims support for the
attribute but a bug prevents
<forEach> loop from running thus
preventing a test of the 'parallel'
attribute.
This tests asynchronous message
exchange patterns. Makes an
asynchronous call to a timed echo
Working in Sun and ODE. In ODE,
service. Pass in an ID for correlation
passing in 0 seconds to wait causes
and the number of seconds to wait
an exception.
before the echo service does a callback
to the main BPEL.
<wait>
<for>
<correlation*>
<invoke>
<receive>
<faultHandlers>
<catch>
<throw>
Technical Architecture Phase 1 deliverables
Description
3/7/2016
This example tests and demonstrates
the error handling features of BPEL. It
test the "throw" operation and Catch
Exception Block.
It is very similar to the echo example.
It takes a string as input. If the string
is less than 10 char long it behaves
like success and returns the length of
ODE needs the Fault variable to be
the string. If String is more than 10
an "element" and not a simple type
char long it behaves like failure.
and wants it initialized first.
Throws an Exception. Exception
Handlers catches the exception and
sets an error message and an error
code(length of string) and returns a
fault.
61
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Tags Tested
Service (Con’t)
SoapHeader
compens2
We found no tags to directly access
SOAP Headers, the WSDL must specify
that the input parameter will come in
the header. We did not test in ODE
because accessing headers not
specified in the operation input is what
we were after. BPEL that reads SOAP
Headers. It's not actually the BPEL so
much as the WSDL that defines them.
Please note: Testing the
SoapHeaderIn operation in NetBean's
internal tester generates a bad stub
with the header element both in the
header and in the body. soapUI
doesn't do this.
<pick>
<onmessage>
<faultHandlers>
<catchAll>
<compensate>
<compensationHandler>
Technical Architecture Phase 1 deliverables
Description
3/7/2016
A simple example to test
"compensation" and registering
compensation handlers. An out scope
"scope1" contains two inter scopes
(scope2 and scope3). In Scope2 we
assign the litteral "Status: Done!" to a
global variable. Scope2 has a
compensation handler that assigns the
string "Status: Undone!" to the same
variable. In scope3 which gets
executed after scope2 we might throw
an exception if the length of the
request is greater than 10. Scope1 has
a fault handler that would catch the
exception and runs a "compensate" on
scope2. then replys with the global
variable.
Compatibility Issues
Not tested in ODE. Sun seems to
require "Document Literal" SOAP
binding to work, not sure if that's
according to spec.
This example does not work in Sun
at all since compensation is not
supported yet. In ODE we can deploy
it but the "compensate" action does
not seem to do anything!!
62
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
Tags Tested
Service (Con’t)
DynamicPartnerlink
<to partnerlink="">
Allows dynamically assigned
partnerlink parameters within BPEL
process (override url parameters for
invoked services. For example: the
ReplyTo in a WS-Addressing header).
Compatibility Issues
Dynamic partnerlink is not yet
implemented in Sun. ODE has
implementation but since they do not
support WS-Addressing we cannot
easily test that. One would have to
create a web service that returns
partnerlink parameters to be
assigned dynamically within BPEL
process.
Receives an email address, sends a
Works in Sun but not ODE since it
verification request to that address and
needs SMTP binding components.
waits for a response. When a response
arrives, writes the message into a file.
SMTPVerifyEMail
Technical Architecture Phase 1 deliverables
Description
3/7/2016
63
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
19.2 Apache ODE Initialization Problem
In ODE you must first initialize a message/variable with <literal> xml skeleton. This must be written by
hand.
<assign name="InitUpdateEmailIn1">
<copy>
<from>
<literal>
<ns3:UpdateEmail>
<Email xmlns="">
<ns0:id>1</ns0:id>
<ns0:personID>1</ns0:personID>
<ns0:address>init_address</ns0:address>
<ns0:confirmed>false</ns0:confirmed>
<ns0:modDate>2007-12-20T12:00:00</ns0:modDate>
</Email>
</ns3:UpdateEmail>
</literal>
</from>
<to variable="UpdateEmailIn1" part="part1"></to>
</copy>
</assign>
After you have initialized the variable/message in ODE you can proceed to copy data into it. In Sun BPEL you
need only do this step.
<assign name="CopyEmailUnverified">
<copy>
<from>false()</from>
<to>$UpdateEmailIn1.part1/Email/ns0:confirmed</to>
</copy>
<copy>
<from>$OtherMessage.part1/Email/ns0:address</from>
<to>$UpdateEmailIn1.part1/Email/ns0:address</to>
</copy>
<copy>
<from>$OtherMessage.part1/Email/ns0:personID</from>
<to>$UpdateEmailIn1.part1/Email/ns0:personID</to>
</copy>
<copy>
<from>$OtherMessage.part1/Email/ns0:id</from>
<to>$UpdateEmailIn1.part1/Email/ns0:id</to>
</copy>
</assign>
The "variable initialization" in ODE contradicts our interpretation of the BPEL 2.0 specification (section 8.4,
http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html#_Toc164738498)
There were no similar "variable initializations" in the examples included in the specification (section 15,
http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html#_Toc164738537)
Technical Architecture Phase 1 deliverables
3/7/2016
64
Kuali Student Service System
Technical Architecture Phase 1 Recommendations
20 Appendix H ESB
See http://www.enterpriseintegrationpatterns.com/toc.html for routing pattern definitions.
Registry
Routing and
Transformation
Configuration
ServiceMix
OpenESB
Synapse
Runtime location
of services
Services are automatically
added to registry upon
deployment.
Services can be called by
service name, endpoint or
interface.
Services are automatically added to
registry upon deployment.
Registry is an xml file which must be
hand edited. Can map services
individually or use pattern matching.
human readable
directory
HTML page of WSDL links for
services exposed over http.
JMX access shows all
deployed endpoints, statistics
and provides startup/shutdown
capability.
JMX access shows all deployed
enpoints, statistics and provides
startup/shutdown capability.
HTML page showing services that are
individually mapped (can’t show
pattern matched services).
General
Deployment descriptor for a
service provides ability to
override services being
consumed (this occurs before
other bus routing).
Deployment descriptor for a service
provides ability to override services
being consumed (this occurs before
other bus routing).
Services are not deployed to Synapse.
Content Based
Available with EIP or
Camel Components.
No specific support, would have to use
a BPEL engine.
Wire-Tap
Available with EIP or
Camel Components.
No specific support, would have to use
a BPEL engine.
Content based routing can be
achieved by XPATH evaluation using
filter/switch mediators.
Messages can be sent to multiple
endpoints.
Routing Slip
Available with EIP or
Camel Components.
No specific support, would have to use
a BPEL engine.
Not Supported.
Transformation
Available with SAXON or
Camel Components.
An XSLT component is provided.
Messages can be transformed using
XSLT mediator.
Clustering and
Load Balancing
Supported. Services must be
manually deployed to each
clustered instance.
Supported through GlassFish
Application Server. Deployment of
service propagates to all machines in
cluster.
Not supported.
Federation
Supported. Registry
information is shared between
distinct instances.
Not Supported. Services must be
individually exposed to and consumed
by distinct instances.
Supported. Registry information is
merged from all instances.
Technical Architecture Phase 1 deliverables
3/7/2016
65