SOA Built on Open Source Web Service Technologies

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

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 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 Unit Test JUnit Build Maven Code Management Subversion Mapping Frameworks JPA Hibernate Java-XML binding JAXB Java-WSDL binding JAX-WS Technology Stack ESB: KSB Database: Derby Service Engine: CXF Servlet Container: Tomcat 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 ProofsCont’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 http://kuali.berkeley.edu:8080/ks-poc-0.0.1-SNAPSHOT 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 • 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. 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 ChallengesCont’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” • 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: • http://www.kuali.org/assets/pdf/KS+Phase+I+Recommendations+v2.0.pdf • Deployment lab

24. Questions? Andrew Bucior Services architect, Kuali Student abucior@admin.fsu.edu Wil Johnson Technical lead, Kuali Student wilj@fsu.edu Website http://www.student.kuali.org Student.info@kuali.org 24