1. RAD, RULES, AND COMPATIBILITY: WHAT'S COMING IN KUALI RICE 2.0 Eric Westfall – Indiana University Travis Schneeberger – Dechen Consulting Group Peter Giles – University of Washington

2. KUALI RICE COMPONENTS Version 1.0.x KSB - Kuali Service Bus KIM - Kuali Identity Management KEW - Kuali Enterprise Workflow KEN - Kuali Enterprise Notification KNS - Kuali Nervous System Version 2.0.x – (Beta available now!) KRMS – Kuali Rule Management System KRAD – Kuali Rapid Application Development

3. KUALI RICE 2.0 DELIVERABLES Improved Modularity Version Compatibility Kuali Rule Management System (KRMS) Kuali Rapid Application Development (KRAD)

4. MODULARITY

5. MODULARITY – IN THE PAST High level of coupling Code base overly “monolithic” Client perspective Which apis and services should I use? Which ones are internal?

6. MODULARITY – MAKING IT BETTER Leverage Maven separate out different conceptual modules of Rice into multiple Maven modules Enforce internal and external dependencies Packaging Make it clear from package names which classes constitute “apis” and which are for internal use only

7. TYPICAL COMPONENT BREAKDOWN web app implementation framework api

8. THE VISION

9. WHY? Decrease complexity Isolate external dependencies Reduce coupling Allow modules of rice to be developed and tested in isolation Improve the quality of the Rice codebase

10. WHY? Make it explicit what code client apps can use Helps Rice make guarantees on releases Make client upgrades easier Provide more deployment and integration flexibility Version Compatibility

11. VERSION COMPATIBILITY Concerned primarily with client-server communication with Kuali Rice services We call this “middleware” compatibility Applications written against different versions of the Rice middleware services need to be able to interoperate Should be able to upgrade middleware services without requiring every client to upgrade at the same time

12. CURRENT SITUATION

13. DESIRED SITUATION Lifespan Summary: Patch Release – as needed Minor Release – every 6 months Major Release – every 2-3 years

14. EXISTING COMPATIBILITY CHALLENGES Service contracts not always well defined Difficult for clients to know which code constitutes apis that they should be using Use of Java Serialization over HTTP Direct connections from client applications into the Kuali Rice database Project moving quickly the last few years, lots of change Verifying and enforcing compatibility

15. PATH TO COMPATIBILITY Reduce client interaction with Rice database Move public services apis to “api” modules Create package structures that reflect modularity Use SOAP for service integration Design message formats to allow for evolution across versions Version information in KSB service registry

16. ENFORCING COMPATIBILITY Define a set of rules for service evolution Only add operations and data elements Deprecate, don’t remove Create new services for major changes Automated testing against different versions Operationalize a service governance process

17. DEPENDENCY UPGRADE 2.0: impacting release, time to update dependencies Each dep has been analyzed/upgraded/changed Removed unused/dead deps (oscache, bsf, concurrent backport, htmlunit, oro, standard…) Introduced deps (joda-time, groovy, selenium, jackson, tiles, guava…) Java 6+ and Servlet 2.4+ container

18. CACHING Spring 3.1’s Caching abstraction, ehcache, and the KSB OSCache is gone! alternatives can be used – no code dep on ehcache! jsr 107 with rice via Spring 3.1 Designed to be used by Rice Clients

19. DEPENDENCY UPGRADE OldNew spring 2.5spring 3.1 servlet 2.4servlet 2.5 jsp 2.1jsp 2.2 cxf 2.2cxf 2.3 oscache 3.2ehcache 2.4 xapool* 1.5 (kuali)bittronix 2.1 *xapool can still be used if desired

20. CACHING @Cacheable(value= Group.Cache.NAME, key="'id=' + #p0") Group getGroup(String id) throws RiceIllegalArgumentException; @Cacheable(value= Group.Cache.NAME, key="'principalId=' + #p0 + '|' + 'namespaceCode=' + #p1") List getGroupsByPrincipalIdAndNamespaceCode(String principalId, String namespaceCode) throws RiceIllegalArgumentException; @CacheEvict(value={Group.Cache.NAME, GroupMember.Cache.NAME}, allEntries = true) Group updateGroup(Group group) throws RiceIllegalArgumentException;

21. CRITERIA API Rich API for constructing queries Used for Services, Lookups, etc. Predicate apiAuthors = and( like("display", "*Eric*"), greaterThan("birthDate", gtBirthDate), lessThan("birthDate", ltBirthDate), or(equal("name.first", "Travis"), equal("name.last", "Schneeberger"))) QueryByCriteria.Builder.fromPredicates(apiAuthors);

22. K UALI R ULE M ANAGEMENT S YSTEM KRMS is a new module in Rice 2.0 Implements a Business Rule Management System (BRMS) BRMS - a system used to define, deploy, execute, monitor and maintain business rules Business Rules – decision logic that is used by operational systems within an organization or enterprise

23. MOTIVATIONS – KUALI COEUS Functional equivalence with MIT Coeus Workflow Rules Notification Rules Validation Rules Questionnaire Rules GUI for maintaining rules Integrates with data in Coeus database Supports custom KC “Functions”

24. MOTIVATIONS – KUALI STUDENT Kuali Student also has needs for a BRMS Course Prerequisites Student needs courses Student needs a minimum GPA of Student must have permission from advisor Etc. Workflow Routing Already implemented a repository for rules, but needed an execution engine

25. REQUIREMENTS General enough to be used in many different cases But must satisfy at least KC and KS requirements Rule Repository Execution Engine Must be able to track execution plan and provide information back to caller for decision support Maintenance GUI Extensible and Pluggable

26. TERMINOLOGY Proposition – a function that resolves to true or false amount > $1000 Compound Proposition – a kind of proposition that groups other propositions joined by AND or OR operator ((amount > $1000) AND (category = “other”) AND …) Action - Executed if a rule evaluates to “true” Notify unit coordinater Route an approval request Generate a validation error

27. TERMINOLOGY Rule – a proposition linked with a list of actions to execute if proposition evaluates to “true” Agenda – execution plan for a set of rules Controls the execution flow of rules in the agenda when it is executed Supports conditional branching Term – defines a piece of business data that can be used in the construction of propositions Fact – an value instance for a term Context – a domain in which rules run

28. KRMS UI: AGENDA EDITOR

29. KRMS UI: RULE EDITOR

30. KRMS UI: RULE EDITOR CONTD…

31. KRMS - ARCHITECTURE

32. INTEGRATION Kuali Student POC integrates with their pre-existing “Statement Service” Kuali Coeus will build custom integration with their questionnaire component Integrate KRMS with other Rice components via custom “actions” KEW PeopleFlow Approval Action PeopleFlow Notification Action (FYI) KRAD Validation Rule Type toggles action execution logic Requires client invocation from KRAD validation rule class currently

33. KUALI RAPID APPLICATION DEVELOPMENT (KRAD)

34. WHY KRAD? KNS is Struts 1.x based Very little built-in rich user interface support User experience is designed more for administrative users Only has built-in support for a small set of screen types Note however, most of the core concepts from KNS are still relevant in KRAD

35. WHY KRAD? Kuali Student has a wider variety of UX (user experience) requirements Need better support for “self-service” screens for which the KNS is not well suited A need for Web 2.0 and other Rich Internet Application features Support for more complex types of screens and layouts

36. KRAD – LAUNDRY LIST

37. KRAD TECHNOLOGY Spring MVC Spring Beans and Expression Language Apache Tiles as the templating engine Fluid Skinning System for CSS jQuery as the javascript library Including jQuery UI And other plugins providing functionality like AJAX

38. KRAD SCREENSHOTS KNS Look and Feel - http://bit.ly/tKDhKahttp://bit.ly/tKDhKa KS Look and Feel - http://bit.ly/rYCDQyhttp://bit.ly/rYCDQy See lots of other examples by going to the “Kitchen Sink” at http://demo.rice.kuali.orghttp://demo.rice.kuali.org Log in as “admin” user

39. KRAD IN ACTION! For more information on KRAD, an in-depth session will be held tomorrow from 2:30 – 4:45 Will include a demonstration on how to build KRAD applications

40. AFTER RICE 2.0 Kuali Rice has a roadmap committee which works with project investors to assemble and maintain the Kuali Rice Roadmap Kuali Rice 2.1 More KRAD!

41. AFTER RICE 2.1 Data Migration Tools Workflow engine escalation Graphical workflow process designer Additional RAD Tools for application development Much more! Attend the Kuali Rice Roadmap session tomorrow at 1:15 PM

42. QUESTIONS? Learn more at http://rice.kuali.orghttp://rice.kuali.org Take a test drive at http://demo.rice.kuali.orghttp://demo.rice.kuali.org Join the rice.collab@kuali.org mailing listrice.collab@kuali.org