Building components aimed at serving needs of Kuali (Finance, Research, Student?), but hopefully reusable in other contexts. Kuali Rice – middleware to facilitate workflow, ESB, notification “Nervous System”
“Rice Client” tied into ESB to pass around real-time messages and communication. One of the goals seems to be to limit the amount of Java code in a client through a service layer, supporting RAD against this framework. Then you plug into the bus which provides service registry, remoting, etc. Sounds a lot like the RMI use-case is a key consideration. Client should support a lot of the service wiring and other connection details. Pushing to looslye couple separate products, and provide technical consistency.
Workflow evolved from Indian system. KNS adds a foundation for patterns, builds on workflow to support reference tables, financial transactions, etc. Abstraction layer for KFS. KSB motivated by getting KFS & KRA to talk to each other. KEN (notification) is a notification engine, sounds a lot like our use cases for myRutgers Alerts. Allows user to set preferences for notification delivery.
Maturity: KFW and components are in production at Indiana. Other components evolving. Spring, Struts/SpringMVC, Apache OJB used.
KSB: Spring configuration for exposing services on the bus. SSL protected HttpRemoting or Web Services. Generic web service invoker? Lowest common denominator – passes strings in and out, not sure exactly why you would do that and put web services inbetween if you’re still manually marshalling data structure. Integration with PHP/Perl/Python/Ruby? Sync/async, topics.
KNS: Data dictionary, glue
KEW: Routing & approval rules across the University, hooks for lifecycle events “post-processor” to allow callback, document functions.
KEN: Notifications, group messaging, workflow items, alerts (e.g. book overdue), unified inbox. I wonder what users think about basically another email INBOX — of course the same goes for myRutgers Alerts.
Future: enhanements, standards (BPEL, JSR, Portals, etc.). RICE to set of reuseable components, business process agility, integration, support, workflow & messaging.
Kuali Infrastructure Suite
Tags: about · age · book · business · cas · ci · cle · communication · email · integration · it · java · jsr · portal · Portals · post · ruby · rutgers · service · Spring · ssl · sso · ui · web · Work
Building components aimed at serving needs of Kuali (Finance, Research, Student?), but hopefully reusable in other contexts. Kuali Rice – middleware to facilitate workflow, ESB, notification “Nervous System”
“Rice Client” tied into ESB to pass around real-time messages and communication. One of the goals seems to be to limit the amount of Java code in a client through a service layer, supporting RAD against this framework. Then you plug into the bus which provides service registry, remoting, etc. Sounds a lot like the RMI use-case is a key consideration. Client should support a lot of the service wiring and other connection details. Pushing to looslye couple separate products, and provide technical consistency.
Workflow evolved from Indian system. KNS adds a foundation for patterns, builds on workflow to support reference tables, financial transactions, etc. Abstraction layer for KFS. KSB motivated by getting KFS & KRA to talk to each other. KEN (notification) is a notification engine, sounds a lot like our use cases for myRutgers Alerts. Allows user to set preferences for notification delivery.
Maturity: KFW and components are in production at Indiana. Other components evolving. Spring, Struts/SpringMVC, Apache OJB used.
KSB: Spring configuration for exposing services on the bus. SSL protected HttpRemoting or Web Services. Generic web service invoker? Lowest common denominator – passes strings in and out, not sure exactly why you would do that and put web services inbetween if you’re still manually marshalling data structure. Integration with PHP/Perl/Python/Ruby? Sync/async, topics.
KNS: Data dictionary, glue
KEW: Routing & approval rules across the University, hooks for lifecycle events “post-processor” to allow callback, document functions.
KEN: Notifications, group messaging, workflow items, alerts (e.g. book overdue), unified inbox. I wonder what users think about basically another email INBOX — of course the same goes for myRutgers Alerts.
Future: enhanements, standards (BPEL, JSR, Portals, etc.). RICE to set of reuseable components, business process agility, integration, support, workflow & messaging.