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.
Cornell Notification System (KEN)
Tags: age · ANT · business · cas · email · integration · it · portal · project · rutgers · service · sim · Spring · ui · web · Work · XML
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.
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.