Kuali Rice: Enterprise Middleware Solutions

1. Kuali Rice: Enterprise Middleware Solutions Geoff McGregor Terry Durkin

2. Quick Review • Kuali Rice – middleware suite of integrated products • Kuali Nervous System (KNS) – application development framework • Kuali Enterprise Workflow (KEW) – document routing engine • Kuali Identity Management (KIM) – identity and access management services • Kuali Service Bus (KSB) – common registry of remote services • Kuali Enterprise Notifications (KEN) – broker for university-related communications

3. Bundled Rice • Bundled Mode • When you download KC, you are downloading Rice • By default, Rice is Bundled with KC • Behaves as one monolithic application • All services in local Spring context • Web content in the same war • Single DB schema

4. Standalone Rice • Rice can be downloaded separately and run as an independent service • Standalone client integration options • Embedded • Remote • Hybrid – different modes by module

5. Changing Integration Modes • KC was designed to make switching deployment modes relatively simple • kc-config.xml: • Modify <module>.runmode parameters • If using embedded, specify the Rice datasource info • Ensure dev.modeparam = false • If using KSB security, fill in keystoreparams • Modify rice.app.url to point to the Rice webappurl

6. Embedded Mode • Rice services run in the client application and access the Rice DB directly • Independent Rice web app and database

7. Embedded Mode • Fast – embedded client talks directly to the database • Scalable – processing load is distributed • No need for application plugins on the Rice server to handle application-specific logic

8. Remote Mode • Client applications interact with Rice standalone via KSB service calls or straight web service calls

9. Remote Mode • Loosest coupling • Easy to connect • May require multiple deployment artifacts (app + plug-in) • Reduced performance due to transport overhead

10. Modular Design • Each module composed of a set of service interfaces and API components • Each module also has a reference implementation of those services • Each module publishes services on the service bus that are available externally • Services are located and invoked – they may be deployed locally or remotely and the caller does not need to know • Client applications code to the module APIs – don’t care about the underlying deployment mode DocumentServicedocumentService = ServiceLocator.getDocumentService(); documentService.routeDocument(myDocument);

11. Resource Loaders • Modularity powered by the resource loader stack • A component in Rice which locates and loads references to service endpoints • All services identified by a qualified name • Can also load objects from classloaders

12. Resource Loader Stack

13. Kuali Service Bus • Sits at the bottom of the Resource Loader Stack • Simple service bus • Exporters • Connectors • Synchronous service invocation • Asynchronous reliable messaging • Service registry

14. Kuali Service Bus

15. KSB Service Registry

16. Kuali Service Bus • Provides the ability to scale applications horizontally • Can publish more than one service with the same name from multiple instances • KSB will round-robin requests, as well as fail over if an instance is down • KSB can identify which application cluster a service belongs to based on app’s Service Namespace

17. eDocLite • Part of KEW • Build simple forms quickly • Ideal for quickly turning paper-based forms into electronic forms back by workflow and its features: • Document search • Action list • Email notifications • Route log • Routing rules

18. eDocLite • Created with XML and optionally javascript • No java, no relational tables – data stored in a table by key-value • Data can be transformed and inserted into relational tables via postprocessor hooks, if necessary • Even ‘lighter’ (but more limited) than KNS Maintenance Documents

19. eDocLite

20. Putting It All Together

21. Putting It All Together • As an enterprise middleware solution, Rice provides: • Common development framework for programmers and experience for users • Generic workflow engine can be leveraged by any application • Consolidated action list, doc search for all KEW-enabled eDocs • eDocLite for quickly building lightweight routable eDocs • Centralized, comprehensive identity management solution • KEW and KIM synergy for group and role-based routing • Communication broker for system-to-system integrations (e.g., KC-KFS)

22. Enterprise Rice – IU Case Study • Why? • How long? • How many applications? • How many documents? • How many users? • How does it work? • Which Modules? • How many developers?

23. Rice at IU – Why? • Core infrastructure • Supporting Enterprise Apps • Supporting a shared development methodology for the institution • Supporting our Service Deployment and Deployment Strategy through KSB • Supporting our evolving IDM process through KIM • Supporting departmental processes through eDocLite

24. Rice at IU – Enterprise Applications

25. Rice at IU – eDoc Lite

26. Rice at IU – Document Metrics

27. Rice at IU - Users

28. Rice at IU - Architecture • Load balancer with four clustered Kuali Rice standalone server instances • Use Tomcat as the servlet container • Shared file system mount for attachments • Oracle database • Many client applications use an embedded workflow engine • This is our recommended integration model • There are a few “thin client” applications remaining which utilize plug-ins

29. IU Kuali Rice Architecture

30. Scalability • Designed for horizontal scalability • Load balancer helps to distribute requests • Could add additional application servers to suit needs • Over the years have moved from two application servers to four to handle increased usage • Using embedded workflow engines also helps to distribute the load

31. KIM Integration • Identity management at IU is handled by a separate team • Use a tool from Microsoft called “Identity Lifecycle Manager” • Provisions identity data into KIM database tables • Does so in as near real-time as possible • Implemented a custom SOAP service and published on the KSB to receive CRUD operations • Also integrates with Active Directory for groups

32. KIM Architecture

33. Enterprise Portal • Our Enterprise Portal is currently using a “closed-loop” version of the service bus to handle communication between different instances in their application cluster • Action List portlet • Notifications Channel • Future projects: • Bringing portal onto the enterprise bus • Loading student calendars via web services • KIM Integration

34. Enterprise Portal

35. Problem Solved! • Created a multi-page form to collect all disclosures • Faculty with nothing to disclose can simply submit the form after filling in some info • For those with disclosures, cut the processing time from up to two months, to within a week • No more data entry costs – staff can work on other things • Reporting: • Send reports to departments • Run reports to determine who still needs to disclose • Metrics

36. Research Administration – Conflict of Interests

37. Research Administration – Conflict of Interests • For those faculty with no disclosures, they can select all “No” and they are finished • If “Yes” is answered to any question, it takes them to a screen where they can enter disclosures

38. Rice - Future • Top level Kuali Project • Investors, Project Board • Application Roadmap Committee – Features/Functionality • Technical Roadmap Committee – Tools, Libraries • Rice 2.0 • Summer 2011 • Workflow GUI/Rules processing • Version Compatibility (upgrade server/clients separately) • KRAD – Next-gen KNS, AJAX, updated tools