Jason E. Shao

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.

This entry was posted Monday, December 4th, 2006 at 3:00 pm and is filed under Commentary. You can leave a response, or trackback from your own site.