1. SOA Built on Open Source Web Service Technologies
EDUCAUSE 2008:: Orlando, FL
October 30, 2008

2. Objective
Describe our approach to creating an open source infrastructure for SOA
Discuss the investigation of web standards and open source implementations

3. Why SOA? Closer alignment of IT and business needs and understandings
Faster turnaround time on change
Re-orchestration of higher level services allows adaptability
Allows best of breed approach
Defined points of integration/interoperability in contracts
Loosely coupled services representing areas of business concern
Standards based interoperability (WS-*, JBI, etc)

4. Implications of SOA New way of thinking about IT
Heavy analysis required
What do we have? What do we want? What is going to change in the future?
May lead to different governance processes due to changes from silo approaches
Design constraints due to opaque interfaces, no “peeking under the hood”
Variety of standards, not all complete or widely adopted
Lack of complete Open Source solutions

5. How We Did It Clear separation of responsibilities
Business (“Functional”)
What do we want?
What are the “silos”?
Technical
What tools are available?
How do they work together?

6. Phased Modular Approach
Functional Stream
Technical Stream
Aug 2007
Nov 2007
Dec 2007
Oct 2008
Nov 2008
May 2009
July 2009
Aug 2009
Application Architecture
Technical Architecture
Service Modeling &
Contract Design
Release 1
Development Infrastructure
Develop Configuration
Application
Program Management & Communications
Service Modeling &
Contract Design
Release 2
Software Design &
Development
Release 1
Adjust plans and repeat for
Releases 2/3/4
(Sep 2009 to Jun 2012)
Implement & Test R1
Re-plan / Re-Architect / Implement & Transition to Support 6

7. Application Architecture Phase
Objective:
Taking functionality requirements and bundling them into services
Steps:
Document High Level Functionality
Identify Service Candidates
Domain Partitioning
Define Scope for KS Release 1
This phase was completed by February Set us up for the next set of repeatable phases. 7 7

8. Technology Stack Evaluation Process
Two-phase evaluation of available products
Phase I – Quick Assessment
Licensing
Standards
Adopters
Supporting Organization
Implementation Language and Environment
Last Stable Version
Internationalization / Localization
3rd-party Reviews
Books Published About Software
Followed by Industry Analysts

9. Technology Stack Evaluation Process
Phase II – In-Depth Assessment
Externals
Functionality
Usability
Internals
Quality
Security
Architecture
Standards and Interoperability
Scalability
Performance
Tools Integration and Plug-Ins

10. Technology Stack Evaluation Process
Phase II – In-Depth Assessment (Continued)
Support
Community
Adoption
Organization
Longevity and Ongoing
Reputation and Professionalism
Note: There was a bias towards other Kuali-based components in the evaluation of products.

11. Kuali Student SOA Stack
Google Web Toolkit
uPortal 3.0 UI
Identity Management
KIM
Workflow
KEW
Organization
KOM KS
Business Rules KS
Dictionary/Search
Middleware
Eclipse
Workbench
Code Management
Subversion
Build
Maven
Unit Test
JUnit
Mapping
Frameworks
JPA
Hibernate
Java-XML binding
JAXB
Java-WSDL binding
JAX-WS
Technology
Stack
Database:
Derby
Service Engine:
CXF
Servlet Container:
Tomcat
ESB:
KSB
Rules Engine:
Drools

12. Development Infrastructure
Development Environment & Technologies
Maven & Subversion
Continuous Integration
Deployment Process
JPA (Persistence)
JUnit Testing
Logging/Auditing
Change Management
Error Propagation (UI/Services/Database)

13. Development Infrastructure cont’d
User Interface
Google Web Toolkit (GWT)
Validation framework
Portal strategy
Internationalization strategy
Rules
Business Rule Management System (BRMS)
Searchable database of rules
User interface for defining rules
Run-time
Will produce readable translations for errors and successfully executed business rules 13

14. Development Infrastructure cont’d
Identity Management, AuthN, AuthZ
Work with Kuali Identity Management (KIM) team 14

15. Architecture, Infrastructure, Methodology Proofs
Integrating the Technology Stack, Development Infrastructure, and SOA Methodology through Proof-of- Concepts
PoC 1: Jan 2, 2008
Prove that the selected technologies integrate (uPortal, Metro & CXF, ServiceMix, ODE, Drools, Derby)

16. Architecture, Infrastructure, Methodology Proofs Cont’d
PoC 2: August, 2008
Initial end-to-end methodology proof (functional and technical)
An implementation of Person and of Leaning Unit and Learning Unit Relation
Flow: Sign In  Display List of Courses  Register for a Course
Middleware components November 2008:
Identity: KIM
Business Rules Management Service: BRMS
Search /Dictionary 16

17. Technologies General Concerns Buy or “build”?
Vendor provided solutions
Generally more complete, but you are tied to their direction
Modifications to the platform require involving the vendor
Community supported solutions
Generally less complete, but you can have greater input and control over their direction
Worst case scenario: you can fork the project

18. Technologies cont’d Orchestration Competing standards
Who should be able to consume the functionality?
Advantages and disadvantages of mash-ups, applications outside of enterprise governance
Similar to Business Intelligence issues
Tech has progressed to make things easy
Introduce security and policy issues
What technologies are available to support orchestration?
Competing standards
Industry standards lacking wide adoption
WS-Transaction (WS-AT, WS-BA,), etc

19. Synchronous vs. Asynchronous design issues
Technologies cont’d
Performance issues
Marshalling overhead
Round-trip cost
Caching
Synchronous vs. Asynchronous design issues
Integration with non-SOA technologies

20. Technology Challenges
WS-Transactions
No open source product implements WS-Transaction in a fully open source Web services environment
Tested WS-AT on Glassfish and on JBoss
Current thinking: compensation where necessary
BPEL
Selection made (Sun OpenESB), but there are issues with command line deployment options, lack of parallel forEach, and lack of support for compensating transactions that kept BPEL from being considered currently viable.
Not using

21. Technology Challenges Cont’d
Workflow
No WS-* open source implementation of workflow that fits ECL
Kuali Student and Kuali Enterprise Workflow (KEW) will look to integrate KEW by
Closing possible gaps in KEW’s Web Service API 21

22. Leading Edge We are Open to Change Stack selections are not static
Selections are based in great part on the standards they implement
If an obvious better choice comes along, or one technology leapfrogs one we’re using, we’ll replace 22

23. Leading Edge cont’d “Swappability” Deployment lab
We aim for stack components that are plug-and-play
Kuali Student documentation will always enumerate the level of swappability of each component
See Section 13 “Swappable Infrastructure” of the Phase I Recommendations document found at:
+v2.0.pdf
Deployment lab

24. Questions? Andrew Bucior Wil Johnson Website
Services architect, Kuali Student
Wil Johnson
Technical lead, Kuali Student
Website 24