1. Kuali Rice: Cross Project Middleware May 21, 2007 Aaron Godert - Cornell University Nate Johnson - Indiana University

2. The Goals The board vision for Kuali is a plug and play module by module approach to software Kuali started as financials, but has evolved into a suite of administrative software (KFS, KRA, KS) Highly productive development environment –For Kuali projects –For non-Kuali projects

3. Goals cont. A common and consistent architecture –Allow developers to understand other rice enabled projects –Infrastructure would not need to be reinvented on each project - focus on functionality! –Rice team can focus on IT standards, like SOA, that will benefit the entire Kuali software suite – Adoption of other Kuali modules feasible

4. Rice is middleware Made up of several, possibly standalone and swappable, middleware components Applications can use a “Rice Client” to easily integrate with this middleware By using this client, interacting with other rice enabled applications comes for free –KRA using services deployed in other projects

5. How we got here Several separate applications needed to be connected and share services in a loosely coupled fashion Kuali products needed to be technically consistent under the hood –For end user support –For different development methodologies

6. How we got here cont. More reasons for technical consistency –Most administrative applications have a common need for middleware services –Avoid design and code duplication –Consolidate configuration

7. Rice Components KEWKuali Enterprise Workflow KNSKuali Nervous System KSBKuali Service Bus KENKuali Enterprise Notification We should take a look at the history of each of these products before talking in more detail how they apply to Rice

8. The History of KEW Kuali Enterprise Workflow existed at Indiana University as a stand alone integration project before Kuali began Provided common engine to drive business processes electronically Provided relatively simple API allowing choices on how to create workflows When Kuali came along, the IU workflow engine became Kuali Enterprise Workflow (KEW)

9. The history of KNS KFS spent a large amount of development time up front, using its best and brightest people, and came up with a great foundation on which to build KFS - the Kuali Nervous System!

10. This history of KNS cont. It focused on a unified approach –A standard way to use workflow –A standard way to maintain support tables using CRUD operations –A standard way of creating business transactions, which in the case of KFS was posting financial transactions

11. This history of KNS cont. The KNS abstracted a lot of the complexity of developing the functionality of a financial system By doing so it provided a large set of reusable code –Enforced consistency in the KFS codebase –Enhanced productivity for KFS developers But this only benefited the KFS

12. The history of the KSB Other Kuali projects came along: i.e. KRA They needed to be able to seamlessly “talk” to other Kuali services/applications in real time –Reducing the need for offline batch –Increasing business process agility The KSB was born –Currently used by KEW and hence KFS –Will be 0.9 version by July 1, 2007

13. The history of KEN Kuali applications wanted an advanced model for end user communication The concept of Kuali Enterprise Notification was born KEN unifies different communications for users

14. The history of KEN cont. It allows user preferences for notification –Users can choose how they are notified –Preferences are saved for future notifications Could be used for emergency communication in times of campus crises –Cell phones, instant messages, email, etc – Mass notification from user’s preference to better reach the campus community quickly

15. Why does a project need Rice? KNS and KEW enhance developer productivity and enforce standards KSB provides a SOA approach for cross project interoperability KEN enhances the user experience while fulfilling a general need for notification across all rice enabled applications Let’s take a closer look at these components

16. The Rice Interactive Diagram Available at http://rice.kuali.orghttp://rice.kuali.org Click anywhere on the diagram to begin Click on any component for details

17. Kuali Rice as it stands Today Version 0.9 will be released July 1, 2007 This is the version KRA will start with Well tested –Rice is being used in KFS –Both unit and functionally tested with JUnit/HtmlUnit –Set up in Continuous Integration environment Let's take a closer look at each of these pieces in more detail

18. KSB Overview - The Goals 1.Enable applications and services deployed on the bus to interact with other applications and services 2.Provide (a)synchronous communication 3.Provide flexible security 4.Provide Quality of Service (QoS)

19. Goal 1 - General Bus Mechanics A common registry of services –Lists all services on the bus and how they can be connected –Through simple configuration, most java based services can be “exported” from a rice enabled application, which is then ready to be consumed by another application

20. Goal 1 - General Bus Mechanics A common resource loading layer that provides access to services (bus or local) –Services can be local to the application, in which case the bus is short circuited and services are loaded directly and efficiently from inside the application –Services can be remote, in which case the service registry is queried for a service endpoint

21. Goal 1 - General Bus Mechanics Most java services inside a rice-enabled application can be exported to a variety of endpoints –Java serialization, SOAP, JMS, etc. A rice-enabled application can easily connect to any service on the bus Let’s take a closer look - http://ksb.kuali.org

23. Goal 2 - Communication Models Synchronous communication = point to point : a method call that waits for a response Asynchronous communication = usually messaging : fire and forget : possible callback –KSB has a proprietary messaging model out of the box that needs minimal configuration –JMS can be used : Good if you have IBM or Tibco –Could plug in open source JMS when one matures

24. Goal 2 - Communication Models Queue and Topic style messaging –Queues are a model where a single service is retrieved from a (possibly) redundant set of services and only that one is invoked –Topics are a model where all services with a given name are retrieved from a (possibly) redundant set of services and invoked

25. Goal 3 - Security Bus Security : Option to digitally sign internal bus communication Service level security : done with open source standard project, Acegi –Can be protected at the service level –Can be protected at the individual method level –Can be protected by many of the standard security models such as CAS or Kerberos –Can act as the user performing the activity

26. Goal 3 - Security cont. A “Security Context” is passed along with service invocations This context holds –The user logged in –The authentication token (from CAS or Kerberos) –The users roles (for Authorization) Services can then call an authentication authority to validate the user and optionally authorize the user with the roles An application gets all of this "for free" by using the KSB via standard Acegi configuration

27. Goal 4 - Quality of Service (QoS) Failover - the ability to automatically switch to another service w/o the calling service noticing Reliability - guaranteed delivery of messages Availability - services on the bus are available real time -- if service is down, reliability ensures messages are delivered when service is available again Time to live and retry counts - ensure that an institution can set their own QoS settings. If QoS is not met messages enter exception routing.

28. KNS Overview Provides reusable code, shared services and a development strategy Provides a common look and feel through screen drawing framework A document or transaction centric model with workflow as a core concept

29. KNS Overview cont. More Core Concepts / Features –Transactional documents –Maintenance documents –Inquires –Lookups –Rules –Questions –Data dictionary

30. Transactional Documents These are data-entry centric documents or “transactions” that model the business processes Examples include: Proposal Development and Protocol Built on a case by case basis using the Kuali tag libraries (soon to be a part of Rice) Integrated with workflow

31. Maintenance Documents They do not need to be build case by case - just one JSP that draws them all These are the CRUD documents - an easy way to maintain support tables in a Kuali database –C: Create new business objects –R: Read or query business objects –U: Update existing business objects –D: Delete existing business objects Examples include: budget rates and cost elements

32. Inquiries A way to drill down and get more read- only information about a business object

33. Inquiry Screenshot

34. Inquiry Example Configuration Travel Account Inquiry

35. Lookups A way to search for data by a set of criteria Results of lookups can be returned to other lookups or documents

36. Lookup Screenshot

37. Lookup Example Travel Account Lookup Main Look up Inst.

38. Lookup Example cont. <lookupField attributeName="foId" required="false" forceLookup="true" />

39. Rules These are programmatic events defined in Java Another way to think of them are as hooks in a document lifecycle They can return errors and stop the lifecycle until user input is corrected A lot have to do with the workflow lifecycle –processSaveDocument(…) –processRouteDocument(…)

40. Questions A configurable way to ask a question of the person using the Kuali application Example: “Are you sure you want to cancel this operation? Yes or No”

41. Questions Screenshot

42. Data Dictionary Configure all of the above concepts into a “usable document” XML based configuration Three types of dictionaries –Business Object –Maintenance Document –Transactional Document

43. Data Dictionary cont. Business Object Data Dictionary –Defines how to draw an inquiry (which fields to show the user) –Defines how do draw lookup and the result fields returned from a lookup as well as the default sort order of the lookup –Defines the business object’s attributes as well as how they are drawn and validated

44. Data Dictionary cont. Maintenance Document Data Dictionary –Defines the BO that is being maintained –Defines the business rules for the document –Defines the authorizations (initiator group) –Defines the maintainable sections (tabs) and layout of the attributes –And various metadata (descriptions, summaries, titles, etc.)

45. Data Dictionary cont. Transactional Document Data Dictionary –Defines the document Java bean –Defines the business rules for the document –Defines the document type –Defines the document’s attributes as well as how they are drawn and validated –And various metadata (descriptions, summaries, titles, etc.)

46. KEW Overview Facilitates routing and approval of business transactions (documents) throughout the university Provides re-usable rule creation which defines how transactions (documents) should be routed –Bind business data to users Provides hooks for client applications to handle workflow lifecycle events of transactions (documents)

47. KEW Overview cont. End users interact with workflow GUIs –Doc Search: Allows users to search for documents (transactions) –Action List: One place to go to find all documents that apply to you

48. Document Search Screenshot

49. Action List Screenshot

50. KEW Overview cont. Route log : document history, audit trail

51. KEW Overview cont. Stand-alone: a centralize hub and spoke approach –Good if you just want to support one workflow server –Centralize Action List and Doc Search –Possibly easier to connect non-Java client Embedded: a decentralized, almost P2P approach –Fast for developers because workflow is local –Distributes workflow across the university Provides distributed transactions so that workflow and client applications stay in synch with each other (easier in embedded) Services reachable via the KSB

52. KEN Overview Works with the action list to provide a single place for all university related communications –Workflow items come from KEW –Non-workflow items from KEN Non-workflow Examples –Overdue library book –A concert on campus –Graduation checklists for seniors –A crisis on campus

53. KEN Overview cont. Provides a secure and controlled environment for notifying the masses Eliminate sifting through email Communication broker which provides any combination of action list, text messages, email, etc... Audit trail just as in KEW

54. KEN Overview cont. User preferences for notification types End user interfaces –Viewing notification details –Maintaining the system (admin) –Sending messages (admin)

55. KEN: Sending Notifications A developer can send notifications by: –Calling the sendNotification() service on the KSB –Invoking the service via a SOAP WS (exposed by the KSB) –Future: integration with KNS’s document frameworks A user can send notifications using a provided workflow enabled form

56. KEN: Send Notification WS Input

57. KEN Screenshot: My Notifications

58. KEN Screenshot: Details

59. KEN Screenshot: Notification Approval

60. KEN Screenshot: Delivery Type

61. What’s next? Looking to the future Coming soon –Maven2 archetype for project template –Distributed user and group services –Out of the box web application for management of users, groups, and adding application specific user attributes

62. The Future… cont. Rice components will piggy back on each other –KEW and KEN will use KNS to draw screens, etc. Standards –JSR 186/286 portlets for user interfaces (portals) –BPEL for process orchestration in workflow –JPA for data –Lots of web service interoperability specifications Possibly easier configuration through DSL Possibly better data mapping through JPA –More easily move away from OJB to Hibernate, EJB or any J2EE container if that is more desirable

63. The main Rice Site –http://rice.kuali.org Rice has a sub-site for each component –Nervous Systemhttp://kns.kuali.org –Service Bushttp://ksb.kuali.org –Workflowhttp://kew.kuali.org –Notificationhttp://ken.kuali.org Still a work in progress –Documentation stable and finished by July 1, 2007 About the website

64. The Team Brian McGough - Indiana University Nate Johnson - Indiana University Ryan Kirkendall - Indiana University Eric Westfall - Indiana University Tom Clark - Indiana University Aaron Godert - Cornell University John Fereira - Cornell University Aaron Hamid - Cornell University Scott Battaglia - Rutgers University Dmitriy Kopylenko - Rutgers University

65. That’s it! Q & A