SOA Built on Open Source Web Service Technologies

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

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

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) 3

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 4

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?

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

Application Architecture Phase § Objective: § § Taking functionality requirements and bundling them into services Steps: 1. Document High Level Functionality 2. Identify Service Candidates 3. Domain Partitioning 4. Define Scope for KS Release 1 7

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 § 3 rd-party Reviews § Books Published About Software § Followed by Industry Analysts 8

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 9

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

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

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

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

Development Infrastructure cont’d § Identity Management, Auth. N, Auth. Z § Work with Kuali Identity Management (KIM) team 14

Architecture, Infrastructure, Methodology Proofs § Integrating the Technology Stack, Development Infrastructure, and SOA Methodology through Proof-of. Concepts § Po. C 1: Jan 2, 2008 § Prove that the selected technologies integrate (u. Portal, Metro & CXF, Service. Mix, ODE, Drools, Derby) 15

Architecture, Infrastructure, Methodology Proofs Cont’d § Po. C 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

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

Technologies cont’d § Orchestration § § Who should be able to consume the functionality? § Similar to Business Intelligence issues Advantages and disadvantages of mash-ups, applications outside of enterprise governance § 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 18

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

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 Open. ESB), but there are issues with command line deployment options, lack of parallel for. Each, and lack of support for compensating transactions that kept BPEL from being considered currently viable. § Not using 20

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

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

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 +v 2. 0. pdf § Deployment lab 23

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