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 2/14/2008 1 Kuali Student Service System Technical Architecture Phase 1 Recommendations

Table of Contents

1 OVERVIEW ...... 4 1.1 REASON FOR THE INVESTIGATION ...... 4 1.2 SCOPE OF THE INVESTIGATION ...... 4 1.3 METHODOLOGY OF THE INVESTIGATION ...... 4 1.4 CONCLUSIONS ...... 5 1.5 DECISIONS THAT HAVE BEEN DELAYED ...... 6 2 STANDARDS ...... 7 2.1 INTRODUCTION ...... 7 2.2 W3C STANDARDS ...... 7 2.3 OASIS STANDARDS ...... 7 2.4 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 COMMENTS ON SELECTION ...... 11 4.2 SELECTION CRITERIA AND EVALUATION ...... 11 4.3 ISSUES ...... 12 5 SERVLET ENGINES ...... 13 5.1 COMMENTS ON SELECTION ...... 13 6 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 REASONS FOR THE SELECTION ...... 16 7.2 ISSUES ...... 16 8 RULES ENGINES...... 17 8.1 COMMENTS ON SELECTION ...... 17

Technical Architecture Phase 1 deliverables 2/14/2008 1 Kuali Student Service System Technical Architecture Phase 1 Recommendations

8.2 SELECTION CRITERIA AND EVALUATION ...... 17 8.3 ISSUES ...... 18 8.4 FIGURE 1 – KS BRMS...... 19 9 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 WORKFLOW ...... 27 12.1 POSSIBLE INTEGRATION ISSUES ...... 27 12.2 INTEGRATION APPROACH ...... 27 12.3 POSSIBLE FURTHER ENHANCEMENTS ...... 28 13 SWAPPABLE INFRASTRUCTURE...... 29 13.1 WHAT DO WE MEAN BY “SWAPPABLE INFRASTRUCTURE ”? ...... 29 13.2 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 14 APPENDIX A STANDARDS ...... 35

Technical Architecture Phase 1 deliverables 2/14/2008 2 Kuali Student Service System Technical Architecture Phase 1 Recommendations

15 APPENDIX B DATABASES ...... 36 15.1 DATABASE PERFORMANCE STATISTICS ...... 36 15.2 PRODUCT COMPARISON MATRIX ...... 37 15.3 APPENDIX C SERVLET ENGINES ...... 38 15.4 SERVLET ENGINES PERFORMANCE ...... 38 15.5 PRODUCT DATA MATRIX ...... 39 16 APPENDIX D XML BINDING FRAMEWORK ...... 40 16.1 XML BINDING PERFORMANCE ...... 40 16.2 PRODUCT DATA MATRIX ...... 41 17 APPENDIX E ENGINES...... 43 17.1 ENGINE PERFORMANCE ...... 43 17.2 PRODUCT COMPARISON MATRIX ...... 45 18 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 BPEL TESTS ...... 60 19.2 APACHE ODE INITIALIZATION PROBLEM ...... 64 20 APPENDIX H ESB ...... 65

Technical Architecture Phase 1 deliverables 2/14/2008 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 2/14/2008 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/assets/pdf/KSS-POC-draft.pdf 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 . Derby can be embedded, it is under the 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 2/14/2008 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 2/14/2008 6 Kuali Student Service System Technical Architecture Phase 1 Recommendations

2 Standards

2.1 Introduction In order to meet the both the Kuali Student technical guiding principles and SOA architecture guidelines such as component abstraction, reusability, loose coupling, and autonomy, widely accepted industry standards must be used to guide the choice of components and the development of the system. An example of how this benefits is abstraction of the database component. It is possible to swap databases if: 1. The database is ANSI SQL compliant; 2. There are JDBC compliant drivers for it; 3. The code 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 WS- Transaction (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 Web- services 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 2/14/2008 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 2/14/2008 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.esup- portail.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 2/14/2008 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 post- process byte code. This can cause complications in the build and deployment environments.

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

6.3 Issues

6.3.1 Performance concerns If there are still lingering concerns that marshalling and un marshalling XML is a performance issue nearly all of the investigations of Phase 1 of Kuali Student indicate that this is not the case:

Technical Architecture Phase 1 deliverables 2/14/2008 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 2/14/2008 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 WS- Transaction. 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 2/14/2008 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 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 ).

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 2/14/2008 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 2/14/2008 18 Kuali Student Service System Technical Architecture Phase 1 Recommendations

8.4 Figure 1 – KS BRMS

Technical Architecture Phase 1 deliverables 2/14/2008 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 2/14/2008 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.open- esb.java.net/Wiki.jsp?page=WLMSE). It is also useful to note that BPEL is not very well suited to represent a specific workflow instance, but rather a workflow pattern. For example, routing a document would not show the list of people in BPEL, but 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 2/14/2008 21 Kuali Student Service System Technical Architecture Phase 1 Recommendations

10 ESB

Selection: Apache ServiceMix

Contenders o Apache ServiceMix o Sun OpenESB o 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 implementation. This should include: 1. Solaris 2. 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 2/14/2008 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 Relevance Adoption 1 Irrelevant None 2 Nice to have Some 3 Mandatory Universal

Standard Relevance Adoption Comments WS-Policy 3 2 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. WS-Coordination 3 2 A basic building block of WS-Transaction. WS-Atomic 3 1 This is fundamental to SOA built on WS*. Only Transactions Sun Glassfish currently has an implementation. WS-Business 2 1 Not implemented anywhere. Most likely, KSS will Activity have to implement some kind of compensation strategies not governed by a standard. WS-Security 3 2 WS-Reliable 3 3 A lot of asynchronous notification likely in KS. Messaging This is even truer if an institution is trying to get rid of batch processing. Well supported by the web service engines out there. WS- Notification Needed if not using JMS, e.g., re: interoperability at that level with .NET app. WS-Addressing 3 3 Fundamental

Standard Relevance Adoption Comments JSR-94 1 2 Defines the interface for starting and running a rules engine. This is not a huge issue as it is rules syntax that really matters. JSR-222 3 2 Defines the standard for Java-XML binding. Core to KSS. JSR-224 3 2 Defines handlers and interceptors: critical to interoperability of KSS services. JSR-286 2 2 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. JSR-208 1 2 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. JSR-220 3 2 JTA (to discuss in Phase II)

Technical Architecture Phase 1 deliverables 2/14/2008 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 2/14/2008 36 Kuali Student Service System Technical Architecture Phase 1 Recommendations

15.2 Product Comparison Matrix Derby MySQL Product site http://db.apache.org/derby/ http://www.mysql.com/ Product Version 10.3.1.4 5 License Apache GPL with FLOSS exception allowing use with Apache licensed products Is it "Pure Java" Yes No Required Java 1.4.2 n/a Version(s) Number of 5 official releases in the 10.x series 5 Releases Backwards Good Some backwards compatibility compatibility issues Industry support Development supported by Sun, IBM, and While OSS, the MySQL core Apache OSS group is owned and primarily maintained by MySQL AB Enterprise http://wiki.apache.org/db- Many large sites such as Production derby/UsesOfDerby http://www.digg.com/ and examples http://slashdot.org/ Standards ANSI SQL, DRDA protocol for drivers ANSI SQL mode can be enabled, disabled by default Version of Significant amount of ANSI:1999 and Level of ANSI support Standard ANSI:2003 mandatory features are depends on which engine is supported http://wiki.apache.org/db- used derby/SQLvsDerbyFeatures Community Good Excellent Support Availability of Yes Yes build scripts Dependencies Bundled with Java 6 Eclipse plug-in Yes (both generic DB plugins as well as Yes (generic DB plugins) available derby specific) Documentation Good Good Books available Yes (mostly covering using Derby with Yes, many other products and servers) Ease of Easy (unzip) Easy installation

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 2/14/2008 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 Tomcat Jetty Glassfish Threads File 1 1029 639 783 File 10 5339 569 2495 File 50 6439 2654 2820

File 100 6142 2784 2805

File 200 5988 2394 2810

Servlet 1 1102 43 804 Servlet 10 5211 513 2783 Servlet 50 6978 2796 2871 Servlet 100 6925 2906 2938 Servlet 200 6944 2796 2418 JSP 1 957 44 662 JSP 10 4526 464 1987

JSP 50 4393 2329 1967

JSP 100 4595 2491 1727

JSP 200 4670 2394 2097

Technical Architecture Phase 1 deliverables 2/14/2008 38 Kuali Student Service System Technical Architecture Phase 1 Recommendations

15.5 Product Data Matrix Tomcat Glassfish Jetty Product site http://tomcat.apache.org https://glassfish.dev.java.net/ http://www.mortbay.org/ Product Version 6 2 6.1 License Apache CDDL and GPL Apache Is it "Pure Java" Yes Yes Yes Required Java J2SE 5 J2SE 5 Java 1.4, 1.5 Version(s) (http://docs.codehaus.org/ display/ JETTY/Downloading+and+Installing ) Number of Releases 4 major release(6.X, 5.5.X, 4 major release 11 4.1.x, 3.3.x) (http://docs.codehaus.org/display/JETTY /Downloading+and+Installing ) Backwards Each version is for different for different version of standard For different servlet and JSP version compatibility version of JSP and Servlet, the configuration path has some changes as well. Standards JSP, Servlet JSP, Servlet, JAXB, J2EE JSP, Servlet related Version of Standard servlet 2.5, JSP 2.1 Community Support Very good Good Not as active as Tomcat Availability of build Yes scripts Eclipse plug-in Yes Yes Yes available https://glassfishplugins.dev. http://eclipse-plugins.2y.net/ java.net/ eclipse/plugin_details.jsp?id=312 Eclipse plug-in High High High maturity/quality Documentation Good Fair Good Books available Yes Yes Covered in some books Ease of installation Easy (unzip and run) Moderately complicated Easy (unzip and run) (installer must be run, accounts set up, etc.) Startup time around 2 seconds less than 1 minute less than 2 seconds

Technical Architecture Phase 1 deliverables 2/14/2008 39 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: 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

Sun’s JAXB reference JiBX XML Castor implementation Beans Marshall and 5 Minutes 22 seconds 6 minutes 6 minutes 8 Minutes 58 seconds Unmarshall 1 seconds 36 seconds Simple Binding 1,000,000 loops

Marshall and 5 Minutes 38 Seconds 7 minutes 7 Minutes 9 Minutes 4 second Unmarshall 27 15 seconds Data Structure seconds 1,000,000 loops

Technical Architecture Phase 1 deliverables 2/14/2008 40 Kuali Student Service System Technical Architecture Phase 1 Recommendations

16.2 Product Data Matrix Sun’s JAXB reference JiBX Castor XMLBeans implementation Product site https://jaxb.dev.java.net/ http://jibx.sourceforge.net/ http://www.castor.org/ http://xmlbeans.apache.org Product Version 2.1.5 1.1.5 1.1.2.1 2.3.0 License CDDL BSD Apache Apache Is it "Pure Java" Yes Yes Yes Yes Required Java 1.3 or better, included in 1.3 or better 1.4 or better Version(s) 1.6 Number of Releases 4 4 Backwards Good (The current code Good Has been broken in compatibility base supports JAXB 1.0, recent releases 2.0, and 2.1 but the project will track future versions of the JAXB specifications.)

Number of Unknown (Sun 1 4 13 developers supported) Enterprise http://jibx.sourceforge.net/ Production sponsors.html examples Standards Defined as JSR, JAXB specification Version of Standard JSR 222 n/a supports XML schema, but uses Castor specific mapping file

Community Support Active Active Active Active Availability of build Yes Yes Yes Yes scripts Dependencies No BCEL.jar, stax-api.jar, common-log.jar, xmlpublic.jar, resolver.jar, wstx-asl.jar, xmlpull.jar, xerces-J_1.4.0.jar jsr173_1.0_api.jar xpp3.jar

Technical Architecture Phase 1 deliverables 2/14/2008 41 Kuali Student Service System Technical Architecture Phase 1 Recommendations

JAXB JiBX Castor XMLBeans Eclipse plug-in Yes, multiple. (Example: No Yes, but only certified Under development available https://jaxb-workshop. to work with Eclipse dev.java.net/plugins/eclip 3.1.x se/xjc-plugin.html) Eclipse plug-in Mature, good. N/A Mature Alpha maturity/quality Documentation Good Good Good Good Books available Covered in Java/XML No Covered in Java/XML Covered in Java/XML books books books Ease of installation Easy. If using JDK6, it is Easy Easy bundled in. Is the binding a JSR standard Vendor specific Vendor specific, but W3C standard standard, or vendor using XML schema specific Data type binding Full W3C XML Schema Java types Java types XML schema type support support Supports user Yes Yes Yes Yes defined types Quality of the stub High (Marked with No stub generated, uses High Low annotation) byte code manipulation Supported by web JAS-WS Axis2, XFire Axis2 service engines Generates Java Yes No Yes Yes object model from XML Schema Generates clean Yes n/a (no code generated) Yes No Java code Requires bytecode No Yes No No modification Generated Java Yes N/A (no code generated) Yes Somewhat (the generated objects are easy to source files are stored in a manage jar file) Overall ease of use Easy Easy Easy Easy

Technical Architecture Phase 1 deliverables 2/14/2008 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. 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.

ServiceMix- Synapse- OpenESB- ServiceMix- Tomcat/CXF- Tomcat/CXF Tomcat/Metro . >Tomcat/CXF >Tomcat/CXF >Tomcat/CXF Tomcat/KSB >Smix/CXF >Tomcat/CXF

1 Thread 2ms av. 40ms av. 4ms av. 3ms av. 4ms av. 3ms av. 3ms av. 3ms av. getCount ( 237/ sec) (24/sec) ( 158 / sec ) ( 188 / sec ) (152/ sec) ( 170 / sec) (202/ sec) ( 178 / sec ) 1ms av. 41ms av. 4ms av. 2ms av. 3ms av. 20ms av. 1ms av. 2ms av. getPerson (333/ sec) ( 23 / sec ) ( 174 / sec ) ( 238 / sec ) (199/ sec) ( 47 / sec) (321/ sec) ( 253 / sec ) 1ms av. 41ms av. 4ms av. 2ms av. 4ms av. 20ms av. 1ms av. 2ms av. getPeople 10 ( 335 / sec ) ( 23 / sec ) ( 166 / sec ) ( 240 / sec ) (188/ sec) ( 47 / sec) (327/ sec) ( 251 / sec ) 1ms av. 41ms av 12ms av. 2ms av. 11ms av. 20ms av. 1ms av. 2ms av. getPeople 100 ( 338 / sec ) . ( 23 / sec ) ( 71 / sec ) ( 239 / sec ) (75/ sec) ( 46 / sec) (333/ sec) ( 257 / sec ) 10 Threads 4ms av. 38ms av. 14ms av. 12ms av. 11ms av. 20ms av. 5ms av. 8ms av. getCount ( 511 / sec ) ( 212 / sec ) ( 207 / sec ) ( 399 / sec ) (357/ sec) (373 /sec) (475/ sec) ( 397 / sec ) 3ms av. 37ms av. 13ms av. 12ms av. 12ms av. 17ms av. 4ms av. 8ms av. getPerson ( 535 / sec ) ( 222 / sec ) ( 127 / sec ) ( 409 / sec ) (350/ sec) (407/ sec) (522/ sec) ( 422 / sec ) 3ms av. 38ms av. 14ms av. 15ms av. 14ms av. 18ms av. 4ms av. 8ms av. getPeople 10 ( 540 / sec ) ( 219 / sec ) ( 194 / sec ) ( 372 / sec ) (327/ sec) (404/ sec) (522/ sec) ( 422 / sec ) 3ms av. 42ms av. 54ms av. 12ms av. 60ms av. 18ms av. 4ms av. 8ms av. getPeople 100 ( 538 / sec ) ( 205 / sec ) ( 109 / sec ) ( 410 / sec ) (139/ sec) (398/ sec) (524/ sec) ( 421 / sec ) 50 Threads 6ms av. 48ms av. 25ms av. 13ms av. 10ms av. 28ms av. 4ms av. 10ms av. getCount ( 514 / sec ) ( 316 / sec ) ( 222 / sec ) ( 410 / sec ) (375/ sec) (419/ sec) (511/ sec) ( 413 / sec ) 3ms av. 46ms av. 32ms av. 16ms av. 16ms av. 25ms av. 4ms av. 8ms av. getPerson ( 521 / sec ) ( 319 / sec ) ( 179/ sec ) ( 405 / sec ) (339 /sec) (426/ sec) (508/ sec) ( 418 / sec ) 3ms av. 48ms av. 43ms av. 17ms av. 15ms av. 28ms av. 4ms av. 9ms av. getPeople 10 ( 522 / sec ) ( 313 / sec ) ( 171 / sec ) ( 406 / sec ) (324/ sec) (421/ sec) (510/ sec) ( 417 / sec ) 8ms av. getPeople 100 3ms av. 82ms av. 294ms av. 16ms av. 298ms av. 25ms av. 4ms av. ( 418 / sec ) ( 520 / sec ) ( 222 / sec ) ( 104 / sec ) ( 406 / sec ) (125/ sec) (414/ sec) (510/ sec)

Technical Architecture Phase 1 deliverables 2/14/2008 43 Kuali Student Service System Technical Architecture Phase 1 Recommendations

ServiceMix- Synapse- OpenESB- ServiceMix- Tomcat/CXF- Tomcat/CXF Tomcat/Metro >Tomcat/CXF >Tomcat/CXF >Tomcat/CXF Tomcat/KSB >Smix/CXF >Tomcat/CXF

100 Threads 4ms av. 45ms av. 39ms av. 15ms av. 10ms av. 28ms av. 7ms av. 19ms av. getCount ( 506 / sec ) ( 324 / sec ) ( 168 / sec ) ( 403 / sec ) (373/ sec) (425/ sec) (500/ sec) ( 402 / sec ) 4ms av. 47ms av. 48ms av. 15ms av. 13ms av. 40ms av. 4ms av. 13ms av. getPerson ( 507 / sec ) ( 317 / sec ) ( 176 / sec ) ( 400 / sec ) (341/ sec) (411/ sec) (502/ sec) ( 407 / sec ) getPeople 10 4ms av. 57ms av. 47ms av. 16ms av. 15ms av. 25ms av. 4ms av. 11ms av. ( 503 / sec ) ( 304 / sec ) ( 172 / sec ) ( 399 / sec ) (320/ sec) (424/ sec) (501/ sec) ( 413 / sec ) getPeople 100 5ms av. 84ms av. 536ms av. 16ms av. 600ms av. 25ms av. 4ms av. 10ms av. ( 505 / sec ) ( 216 / sec ) ( 99 / sec ) ( 398 / sec ) (120/ sec) (412/ sec) (494/ sec) ( 412 / sec ) 200 Threads 4ms av. 46ms av. 58ms av. 66ms av. 10ms av. 25ms av. 4ms av. 30ms av. getCount ( 475 / sec ) ( 318 / sec ) ( 188 / sec ) ( 378 / sec ) (362/ sec) (411/ sec) (227/ sec) ( 397 / sec ) 24ms av. 48ms av. 73ms av. 15ms av. 13ms av. 27ms av. 4ms av. 11ms av. getPerson ( 466 / sec ) ( 302 / sec ) ( 156 / sec ) ( 387 / sec ) (331/ sec) (401/ sec) (485/ sec) ( 403 / sec ) getPeople 10 7ms av. 50ms av. 91ms av. 16ms av. 15ms av. 58ms av. 4ms av. 11ms av. ( 470 / sec ) ( 297 / sec ) ( 158 / sec ) ( 381 / sec ) (311/ sec) (398/ sec) (475/ sec) ( 392 / sec ) getPeople 100 8ms av. 85ms av. (incomplete) 15ms av. 728ms av. 25ms av. 23ms av. 10ms av. ( 474 / sec ) ( 214 / sec ) ( 378 / sec ) (125/ sec) (405/ sec) (471/sec) ( 398 / sec )

Technical Architecture Phase 1 deliverables 2/14/2008 44 Kuali Student Service System Technical Architecture Phase 1 Recommendations

17.2 Product comparison matrix

Axis 2 CXF Metro

Product site http://ws.apache.org/axis2/ http://incubator.apache.org/cxf/ https://metro.dev.java.net/ Product Version 1.3 2.0.3 1.0 License Apache License, Version 2.0 Apache License Dual license of CDDL and GPLv2 with classpath exception. Is it "Pure Java" Yes Yes Yes Required Java Version(s) 1.4 or later 1.5 or later 1.5 or later

Number of Releases 8 (Version 3 releases in the 2.0.x series 2 releases in the 1.x series, 2 1.3/1.2/1.1.1/1.1/1.0/0.95/0.94/0.93 upcoming releases ) Backwards compatibility Not compatible with Axis 1.x Not compatible with XFire Enterprise Production GlassFish V2 and Sun Java examples System Application Server 9.1 Community Support Active Active Active Availability of build scripts Yes Yes Yes

Eclipse plug-in available Yes Eclipse WST support Eclipse WST support (http://ws.apache.org/axis2/tools/in dex.html ), also Eclipse WST support Eclipse plug-in Good Fair Fair maturity/quality Documentation Inadequate Inadequate Inadequate Books available No No No Ease of installation Easy Easy Easy Standards JSR 181, SOAP 1.1, 1.2, WSDL JAX-WS, JSR-181, SOAP 1.2, JAX-WS 2.0, 2.1RI, JSR 181, 1.1, 2.0 WSDL 2.0 SOAP 1.1, 1.2, WSDL 1.1 Data Bindings ADB, XMLBeans, Jibx, JAXB 1.0 JAXB currently, version 2.1 will JAXB support XMLBeans, Castor, and JiBX as well

Technical Architecture Phase 1 deliverables 2/14/2008 45 Kuali Student Service System Technical Architecture Phase 1 Recommendations

Axis 2 CXF Metro

Spring Support Yes Yes Yes WS-Addressing Yes Yes Yes, seen in SOAP message, routing not tested WS-Atomic Transaction No (The Kandula 2 project which is No Yes meant to support WS-Transaction on Axis2 has stalled) WS-Business Activity No No No WS-Coordination No No Yes WS-Eventing No No No WS-Metadata Exchange No Yes, Not tested WS-Notification No Yes (via ServiceMix) No WS-ReliableMessaging Yes Yes Yes, Partially - killing TCP connection does not deliver message WS-Policy Yes Yes Yes, seen in WSDL WS-Secure Conversation Yes To be released in 2.1 Yes, Not tested WS-Security Policy Yes Yes, seen in WSDL and tested WS-Security Yes Partial, based on WSS4J Yes, Tested Encryption and Signature, not Security Tokens WS-Trust Yes To be released in 2.1 Yes, Not tested Overall ease of use Easy Easy Easy

Technical Architecture Phase 1 deliverables 2/14/2008 46 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 Product Space Rule Engine Rule Engine Rule Engine Company JBoss OpenRules, Inc. Product Version: 4 2.1 Alpha release 3 Release Date 30-Aug-07 25-Apr-05 September 18,2006 URL http://labs.jboss.com/drools/  http://sweetrules.projects.semwebc http://openrules.com  entral.org  License Apache License, Version 2.0 SweetRules=LGPL, IBM GPL CommonRules has it's own license which does not allow it in production systems Supported JVM JDK 1.4 and up JDK 1.4 and up Number of Release: 4 2 4 Backwards compatibility: No Yes Number of developers: 13 5 Number of Downloads: 13,000 downloads for the month of Hundreds of downloads in total August, 2007 Enterprise Production Big Faceless Organizations (BFO) examples: Standards: JSR-94 Version of Standard: Community Support: Strong community support via IRC No or mailing lists Availability of build scripts: Yes Dependencies: drools-core.jar, drools-compiler.jar, IBM CommonRules 3.3, JWSDP Yes drools-jsr94.jar, drools- 1.5, DOM4J 1.5, 1.2.8, Xalan decisiontables.jar 2.6.0, Junit 3.8.1 Product Drools 4.0 (JBoss Rules) SweetRules 2.1 OpenRules 3.0 Eclipse plug-in available: Yes Yes

Technical Architecture Phase 1 deliverables 2/14/2008 47 Kuali Student Service System Technical Architecture Phase 1 Recommendations

Documentation: Pretty good documentation of all Available, but very minimal features Books available: No Ease of installation: Easy (configuration of a production Difficult - Must download and install Very Easy system is more involved) third party during the installation Tomcat 6/Axis2 1.3 Integration Difficult - Drools doesn't work with Tomcat 5.5/Axis2 (should work for Tomcat/Axis2 due to class loader Tomcat 6) issues. Can somehow be fixed by creating a new class loader for the Drools compiler. Jetty/Axis2 1.3 Integration Can be configured for Axis2 Supports linear rule Yes Yes, have to write Java functions stereotype? in Excel for this Supports decision table rule Yes Yes stereotype? Supports flowchart stereotype Yes, through its rule flow Yes, but no editor of any kind and (optional)? is tricky Procedural or Rete? If Rete, Rete - Forward Chaining only Supports backward and forward does the product support (backward chaining expected in the chaining backward as well as forward next release) chaining? Support for natural language Yes Limited and only in version 4.0 rule composition? Ability to translate rules into No No natural language? Supports JSR-94 Yes Yes Rules repository File system and database (through Excel files (in 4.0 they can be (file/database)? JDBC) stored as clob in DB) User interface for rule Eclipse 3.2 - JBoss Rules Excel files definition Workbench and rules management (BRMS)

Product Drools 4.0 (JBoss Rules) SweetRules 2.1 OpenRules 3.0

Technical Architecture Phase 1 deliverables 2/14/2008 48 Kuali Student Service System Technical Architecture Phase 1 Recommendations

IDE support for technical staff Eclipse 3.2 - JBoss Rules Eclipse plugin but rules are edited Workbench, WYSIWYG support for using Excel rules, rule-flows and debugging Rule Debugger Yes, powerful IDE debugger No. Has a rule tester that non techies can also use Rule Management System Yes, web based rule management (BRMS) Are rules compiled or Rules are compiled into Java Interpreted interpreted? classes RuleML support No but there is a JBoss project in Yes No (conversion/translation) the works to import/export to ruleML External dependencies? None Web Service Support? No - Maybe in a future release Rules can directly trigger WSDL Yes Web Services as actions. Multi threaded rule execution? Thread safe No Demos http://labs.jboss.com/drools/livetrails Open Rules 3.0 HOWTO Setup  /index.html  Other Hibernate integration Notes Business Rules Management SweetRules is a pluggable set of Pros and Cons  System (BRMS) uses Apache rules tools for RuleML and SWRL Jackrabbit which supports JSR-170 featuring: interoperability between Content Repository API Prolog, production rules, OWL, CommonRules, Jena-2, and several other languages; and inferencing with negation, priorities, and procedural attachments.

Technical Architecture Phase 1 deliverables 2/14/2008 49 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. Get all Address objects where city = 'Seattle' and set region to 'USA West' 2. Get an ArrayList of Address objects where Address object's city = 'Seattle' 3. Find maximum id in the collection of Address objects where city = 'Seattle' 4. Calculate hash code of all Address objects in the collection 5. Function to calculate hash code

Technical Architecture Phase 1 deliverables 2/14/2008 50 Kuali Student Service System Technical Architecture Phase 1 Recommendations

18.2.3 Stateless vs. Stateful Session

Stateless Objects Time Errors 10 0.070 sec 100 0.020 sec 1000 0.080 sec 5000 0.150 sec 10000 0.221 sec 50000 1.192 sec 100000 2.434 sec 200000 5.179 sec 300000 8.355 sec 400000 10.93 sec 500000 13.836 sec 1000000 28.963 sec Stateful Time Errors Objects 10 0.010 sec 100 0.010 sec 1000 0.050 sec 10000 0.942 sec 50000 28.635 sec 100000 2 min 39 sec 200000 9 min 12 sec 300000 18 min 44 sec 400000 32 min 43 sec 500000 51 min 33 sec 1000000 Incomplete Out of memory

Technical Architecture Phase 1 deliverables 2/14/2008 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 Stateful vs. 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

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 2/14/2008 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 Execution Time 10 0.100 sec 100 0.881 sec 1000 8.8 sec 2500 23.6 sec 5000 49.5 sec 7500 1 min 13 sec 10000 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 Execution Time 10 0.020 sec 100 0.010 sec 1000 0.110 sec 5000 0.341 sec 10000 0.761 sec 20000 1.2 sec 30000 1.7 sec 40000 2.3 sec 50000 2.8 sec 60000 3.4 sec 70000 4.0 sec 80000 4.5 sec 90000 5.0 sec 100000 5.7 sec

Technical Architecture Phase 1 deliverables 2/14/2008 53 Kuali Student Service System Technical Architecture Phase 1 Recommendations

Stateful vs. Stateless Session for All Iterations

Technical Architecture Phase 1 deliverables 2/14/2008 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 Execution Time 10 0.110 sec 100 0.200 sec 1000 1 sec 5000 8 sec 10000 42 sec 50000 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 Execution Time 10 0.060 sec 100 0.060 sec 1000 0.281 sec 5000 1 sec 10000 2 sec 50000 13 sec 100000 28 sec 200000 56 sec 300000 1 min 35 sec 400000 2 min 8 sec 500000 2 min 52 sec

Technical Architecture Phase 1 deliverables 2/14/2008 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 Execution Time 10 0.120 sec 100 0.140 sec 1000 1 sec 5000 6 sec 10000 21 sec 50000 4 min 14 sec 100000 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 Execution Time 10 0.130 sec 100 0.180 sec 1000 1 sec 5000 6 sec 10000 23 sec 50000 4 min 23 sec 100000 9 min 50 sec

Technical Architecture Phase 1 deliverables 2/14/2008 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 Execution Time Errors 10 0.10 sec 100 0.20 sec 1000 0.141 sec 2000 0.261 sec 3000 0.401 sec 4000 0.542 sec 5000 0.692 sec 6000 0.864 sec 7000 1.1 sec 8000 1.2 sec 9000 1.6 sec 10000 1.5 sec 15000 2.6 sec 20000 3.4 sec 30000 5.6 sec 40000 10.1 sec 50000 13.3 sec

Stateful Session

Rules Execution Time Errors 10 0.091 sec 100 0.0030 sec 1000 0.201 sec 2000 0.341 sec 3000 0.431 sec 4000 0.532 sec 5000 0.683 sec 6000 0.823 sec 7000 1.0 sec 8000 1.2 sec 9000 1.6 sec 10000 1.5 sec 15000 2.3 sec 20000 3.2 sec 30000 6.9 sec 40000 10.1 sec 50000 13.9 sec

Technical Architecture Phase 1 deliverables 2/14/2008 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 Time Errors 10 0.321 sec 100 1 sec 500 3 sec 1000 7 sec 2000 11 sec 3000 17 sec 4000 24 sec 5000 32 sec 6000 47 sec 7000 58 sec 8000 1 min 15 sec 9000 1 min 36 sec 10000 1 min 54 sec 15000 2 min 36 sec 20000 3 min 48 sec 30000 7 min 3 sec 40000 12 min 33 sec 50000 17 min 30 sec

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 2/14/2008 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 Time Errors 10 0.161 sec 100 0.853 sec 1000 9.2 sec 2000 19.3 sec 3000 30.5 sec 4000 48.4 sec 5000 StackOverflowError

Technical Architecture Phase 1 deliverables 2/14/2008 59 Kuali Student Service System Technical Architecture Phase 1 Recommendations

19 Appendix G BPEL engines

19.1 BPEL Tests Tags Tested Description Compatibility Issues Service

Simple BPEL that accepts a message ODE does not initialize the XML containing a string and returns a skeleton of messages or variables. EchoService2 message containing the input string This appears to not follow the BPEL prefixed with the BPEL engine name. spec.

This BPEL demonstrates invoking There were no issues with regards to CallEchoService2 another service (the EchoService2 invoking other services. example).

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 CorrelationService2 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 This did not work for either engine contact type, casts it to an email, when using . checks to see if it really is an email (by The engines did not correctly Polymorph testing for the email element), then interpret the xsi:type="email" in the assigns the type element to "email" if xml messages. it's email, or "other" if not.

This tests creating a message ODE can not append nodes in a containing a node list with a variable standard way. forEach does not ArrayBPEL number of elements. Takes a count n work in ODE. Sun worked by using and an email and returns a list of n the element[$n] xpath notation. emails with unique ids.

Technical Architecture Phase 1 deliverables 2/14/2008 60 Kuali Student Service System Technical Architecture Phase 1 Recommendations

Tags Tested Description Compatibility Issues Service (Con’t)

This tests parallel processing using a dynamic number of threads (this also NetBeans does not support 'parallel' provides method-like functionality in attribute set to 'yes'. ODE BPEL, without it the number of threads documentation claims support for the ConcurrentActivity will have to be hard coded and the attribute but a bug prevents steps in each parallel activity must be loop from running thus copy and pasted). Takes a list of preventing a test of the 'parallel' addresses and inserts them in 'parallel' attribute. sequence into database.

This tests asynchronous message exchange patterns. Makes an asynchronous call to a timed echo Working in Sun and ODE. In ODE, AsynchronousExample 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.

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

Technical Architecture Phase 1 deliverables 2/14/2008 61 Kuali Student Service System Technical Architecture Phase 1 Recommendations

Tags Tested Description Compatibility Issues Service (Con’t)

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 Not tested in ODE. Sun seems to we were after. BPEL that reads SOAP require "Document Literal" SOAP Headers. It's not actually the BPEL so SoapHeader binding to work, not sure if that's much as the WSDL that defines them. according to spec. 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.

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 This example does not work in Sun variable. In scope3 which gets at all since compensation is not compens2 executed after scope2 we might throw supported yet. In ODE we can deploy an exception if the length of the it but the "compensate" action does request is greater than 10. Scope1 has not seem to do anything!! a fault handler that would catch the exception and runs a "compensate" on scope2. then replys with the global variable.

Technical Architecture Phase 1 deliverables 2/14/2008 62 Kuali Student Service System Technical Architecture Phase 1 Recommendations

Tags Tested Description Compatibility Issues Service (Con’t)

Dynamic partnerlink is not yet implemented in Sun. ODE has Allows dynamically assigned implementation but since they do not partnerlink parameters within BPEL support WS-Addressing we cannot process (override url parameters for easily test that. One would have to DynamicPartnerlink invoked services. For example: the create a web service that returns ReplyTo in a WS-Addressing header). 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 SMTPVerifyEMail needs SMTP binding components. waits for a response. When a response

arrives, writes the message into a file.

Technical Architecture Phase 1 deliverables 2/14/2008 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 xml skeleton. This must be written by hand.

1 1 init_address false 2007-12-20T12:00:00

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.

false() $UpdateEmailIn1.part1/Email/ns0:confirmed $OtherMessage.part1/Email/ns0:address $UpdateEmailIn1.part1/Email/ns0:address $OtherMessage.part1/Email/ns0:personID $UpdateEmailIn1.part1/Email/ns0:personID $OtherMessage.part1/Email/ns0:id $UpdateEmailIn1.part1/Email/ns0:id

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 2/14/2008 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.

ServiceMix OpenESB Synapse Registry Runtime location Services are automatically Services are automatically added to Registry is an xml file which must be of services added to registry upon registry upon deployment. hand edited. Can map services deployment. individually or use pattern matching. Services can be called by service name, endpoint or interface.

human readable HTML page of WSDL links for JMX access shows all deployed HTML page showing services that are directory services exposed over http. enpoints, statistics and provides individually mapped (can’t show JMX access shows all startup/shutdown capability. pattern matched services). deployed endpoints, statistics and provides startup/shutdown capability. Routing and General Deployment descriptor for a Deployment descriptor for a service Services are not deployed to Synapse. Transformation service provides ability to provides ability to override services override services being being consumed (this occurs before consumed (this occurs before other bus routing). other bus routing). Content Based Available with EIP or No specific support, would have to use Content based routing can be Camel Components. a BPEL engine. achieved by XPATH evaluation using filter/switch mediators. Wire-Tap Available with EIP or No specific support, would have to use Messages can be sent to multiple Camel Components. a BPEL engine. endpoints.

Routing Slip Available with EIP or No specific support, would have to use Not Supported. Camel Components. a BPEL engine.

Transformation Available with SAXON or An XSLT component is provided. Messages can be transformed using Camel Components. XSLT mediator. Configuration Clustering and Supported. Services must be Supported through GlassFish Not supported. Load Balancing manually deployed to each Application Server. Deployment of clustered instance. service propagates to all machines in cluster. Federation Supported. Registry Not Supported. Services must be Supported. Registry information is information is shared between individually exposed to and consumed merged from all instances. distinct instances. by distinct instances. Technical Architecture Phase 1 deliverables 2/14/2008 65