Cornell Notification System (KEN)

Project looking to provide a super-inbox for important notifications. Using the Kuali Enterprise Notification service – again use cases look a lot like the myRutgers Alert system. Actually, sounds like the vision of our alerts combined with announcements combined with other things.

  • avoid the overloaded email box
  • integrated with workflow
  • user & group addressing
  • audit trail

I wonder – sounds like creating basically a Institution email type messaging box. Are users going to use a separate box? Staff probably, but students? The range of events sound like they could generate a high noise ratio.

Controlled delivery date/time is an interesting concept (institutional ecards? 😉 Also interesting that in every scenario, you still end up with a “manual entry” form. Also integrates with calendars, email, SMS… that’s a lot of integration. I’m guessing there’s some kind of filtering users can perform, so they don’t get blasted with notifications.

Architecture: lots of boxes, persistance, data, business, presentation layers, lots of Spring, Business tier derived from Kuali stack. ESB, webservices, XML messages.

2 message types – simple, event (looks like iCal). Delivery to email, portal, cell phone, etc. Asynchronous messaging provided by the bus. KEW integration – action items, users, and groups. Approval workflows for sending messages to groups is interesting. I wonder though – a lot of messaging products sound a lot like email, but not (not that we didn’t implement an alert service that meets those criteria…)

sendNotification() in a JAR is pretty hot. OpenEAI’s approach of bus-level rich domain objects is interesting though – it’s hard to balance rich objects vs. strings for exchanging data between systems. Seems like you’d still loose the richness of a domain model that can embed behavior.

Looking for developers to build up.